web-dev-qa-db-fra.com

Évitez de convertir ">" en & gt;

J'utilise un plugin Markdown et j'essaie d'écrire une citation

Comme ça

Mais Wordpress convertit ">" en une entité HTML, donc le résultat semble

> comme ça

Y a-t-il un moyen d'éviter cela?

editor
6
Donovan

Filtrage the_content

function wpse72941_content_filter( $content ) {
    $new_content = '';
    foreach( preg_split( '/((\r?\n)|(\r\n?))/', $content ) as $line ) {
        $new_content .= preg_replace( '/^>/', '>', $line ) . '\r\n';
    }
    return $new_content;
}
add_filter( 'the_content', 'wpse72941_content_filter', 1 );

Je ne connais pas votre plugin markdown - pour l’approche ci-dessus, j’ai supposé que le démarquage est interprété après la publication du post de la base de données et pas avant qu’il soit sauvegardé. C'est à dire. que le plugin markdown filtre également the_content.

La regex ^> correspond à > si et seulement si ce sont les quatre premiers caractères d'une chaîne. Dans ce qui précède, le contenu est itéré ligne par ligne. Par conséquent, toutes les entités > situées au début d'une ligne sont reconverties en caractères >.

Lorsque le filtre est ajouté, nous définissons la priorité haute (1), de sorte que notre conversion d'entité s'exécute avant l'interprétation de démarquage.

Ce qui précède fonctionnera une fois ajouté au thème functions.php de votre thème, mais serait probablement plus adapté à un plugin. En fait, le plugin markdown devrait s’occupe de lui-même.

Empêcher TinyMCE de convertir des entités

Si vous devez arrêter la conversion d'entité là où elle se produit, avant de l'écrire dans la base de données, vous devrez modifier TinyMCE (l'éditeur) configuration , la entities et/ou entity_encoding les options semblent prometteuses.
Le filtre tiny_mce_before_init peut transmettre des valeurs de configuration personnalisées à l'éditeur WP.

J'aurais aussi fourni un exemple de travail, si ce n'était:

Type de codage: raw | Tous les caractères seront stockés sous une forme non entité, à l'exception des entités XML par défaut: &<>"
de la documentation TinyMCE sur entity_encoding

Donc, pour l'entité en question, cela semble être plus impliqué.
C'est peut-être aussi la raison pour laquelle la désactivation de l'éditeur visuel pourrait ne pas suffire.
Peut-être une combinaison de 'named' comme valeur pour entity_encoding et une liste sans gt pour entities.
Sinon, l'événement onPostProcess serait un dernier moyen.

La vie serait plus simple cependant, si l'hypothèse ci-dessus était vraie et que filtrer la publication sur la récupération de la base de données suffirait.

2
Johannes Pille

Je le résous en utilisant:

function my_content_filter( $content ) {
    $new_content = str_replace('>','>',$content);
    return $new_content;
}
add_filter( 'the_content', 'my_content_filter', 1 );

Je pense que ce n'est pas glamour, mais ça marche ..

1
Tiago Gouvêa

Si vous utilisez Visual Editor, > sera automatiquement converti. Désactivez l'éditeur visuel et utilisez-le.

1
Ankur

J'avais un problème fondamentalement identique sous Wordpress 4.9.4, mais dans mon cas, le coupable était le filtre wp_filter_post_kses() ajouté aux filtres content_save_pre par wp-includes/kses.php. Ce filtre a divers effets, notamment la traduction de <, &,> en entités et la suppression de diverses balises HTML. Un diagnostic indiquant que KSES était impliqué est que la conversion de ces caractères en entités ne se produisait pas pour l'utilisateur super administrateur d'une installation multi-site, car KSES n'installe pas ses filtres pour le super administrateur.

A en juger par l'acronyme "KSES" qui signifie "KSES Strips Evil Scripts!" le module KSES est apparemment une mesure de sécurité. Si des agents potentiellement malveillants n'ont pas accès à la publication de contenu sur votre site, vous devrez peut-être désactiver KSES pour autoriser les caractères bruts ">", etc., dans le contenu de vos publications.

D'après le code, il semble que KSES soit censé être désactivé pour les utilisateurs dotés de la fonctionnalité unfiltered_html. Je ne pouvais pas faire fonctionner ça; Peu importe comment j'essayais d'accorder cette capacité à un utilisateur, KSES était toujours activé, à l'exception du super administrateur réseau. Peut-être que quelqu'un avec une connaissance plus approfondie des capacités de l'utilisateur pourrait faire fonctionner ce mécanisme. En fin de compte, pour autoriser "<" et autres dans mes messages, j'ai été obligé d'ajouter un filtre à pre_post_content (qui s'exécute avant le content_save_pre) qui a renvoyé la valeur d'entrée sans modification, mais qui a pour effet secondaire de vérifier que le L’utilisateur actuel était un administrateur et, le cas échéant, exécuté kses_remove_filters(), ce qui désactive KSES.

0
Glen Whitney