Quand Wordpress encapsule-t-il les scripts en ligne dans CDATA?

Je débogue un problème avec un script tiers que les utilisateurs de wordpress utilisent en copiant / collant un extrait de script et html dans le corps de leur message, comme (exemple non réel bien sûr):

<script>
window.foobar = window.foobar || { hello: function(){ console.log('Hello World'); } };
window.foobar.hello();
</script>

J'ai remarqué que certaines installations de wordpress envelopperont cela dans CDATA, d'autres non (probablement en faisant une sorte de vérification DOCTYPE - bien que tous les thèmes sur lesquels j'ai testé utilisent un doctype HTML5).

Pourtant, lors de l'encapsulation du script dans CDATA, les utilisateurs seront mordus par le bogue suivant: https://core.trac.wordpress.org/ticket/3670 (la fermeture >est incorrectement remplacée par >), ce qui conduit le navigateur à ignorer le contenu du script :

<script>// <![CDATA[  window.foobar = window.foobar || { hello: function(){ console.log('Hello World'); } }; window.foobar.hello();  // ]]&gt;</script>

Je ne possède pas trop de WP-Fu moi-même et la recherche sur Google m'a seulement conduit à identifier le problème tel quel, alors ma question serait: quand WordPress encapsule-t-il exactement les scripts en ligne dans les sections CDATA? L'utilisateur peut-il en quelque sorte empêcher ce comportement? L'utilisateur peut-il contourner le bogue ci-dessus sans modifier le noyau WP?

themes javascript

— m90
source

Lors du collage de JS en ligne dans l'éditeur, WP doit faire ce comportement. Je suggère de mettre le JS en file d' attente à l'aide de wp_head ou wp_enqueue_script ..

— Samuel Elh

Voulez-vous dire "les corps du poste" comme dans l'éditeur WYSIWYG? D'après ce que je peux voir, JS est enveloppé dans des balises CDATA lorsque les scripts sont imprimés (qui peuvent être invoqués de plusieurs façons) mais ne sont pas filtrables. J'imagine, si vous ne parlez WYSIWYG d'un poste, il est peut - être un certain filtrage sur le contenu fait par le thème.

— Doug Belchamber

Il n'est pas recommandé de publier du javascript dans l'éditeur WYSIWYG. L'éditeur dispose d'un certain nombre de filtres pour nettoyer votre contenu qui interagissent mal avec les js en ligne. Il existe des plugins qui aident dans ce type de scénario.

— MikeNGarrett

En fait, ce n'est pas WordPress qui insère les CDATAbalises, mais l'éditeur visuel, TinyMCE. Les détails de TinyMCE sont hors sujet ici, mais vous pouvez lire une solution à cela sur Stackoverflow .

Cela dit, l'arrêt de TinyMCE n'est peut-être pas la solution complète que vous souhaitez. WordPress lui-même a également une fonction pour ajouter des CDATAbalises, wxr_cdataqui est utilisée lors de la sortie d'un fichier xml valide, par exemple si vous souhaitez exporter le fichier ou utiliser le contenu dans un flux rss. Les thèmes et / ou plugins pourraient décider d'attacher ce filtre au contenu s'ils souhaitent que le document soit valide en xhtml.

C'est là que vous rencontrez ensuite le bogue , qui a été documenté pour la première fois il y a douze ans et qui n'est toujours pas résolu. Il s'agit de ces trois lignes dans the_content:

$content = apply_filters( 'the_content', $content );
$content = str_replace( ']]>', ']]&gt;', $content );
echo $content;

Comme vous pouvez le voir, le str_replaceest codé en dur, immédiatement suivi par l'écho. Il n'y a aucun moyen d'intercepter ce remplacement.

Cependant, ce que vous pouvez faire si vous contrôlez votre thème, c'est tamponner the_content et inverser le remplacement. Comme ça:

ob_start();
the_content();
$content = ob_get_clean();
$content = str_replace( ']]&gt', ']]>', $content ); 
echo $content;

— cjbj
source