¿Cuándo Wordpress ajusta los scripts en línea en CDATA?

Estoy depurando un problema con una secuencia de comandos de terceros que los usuarios de WordPress usan copiando / pegando un fragmento de secuencia de comandos y html en los cuerpos de sus publicaciones como (por ejemplo, un mundo no real):

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

Noté que algunas instalaciones de wordpress lo envolverán en CDATA, otras no (probablemente haciendo algún tipo de verificación DOCTYPE, aunque todos los temas en los que probé esto usaban un doctype HTML5).

Sin embargo, al envolver el script en CDATA, los usuarios serán mordidos por el siguiente error: https://core.trac.wordpress.org/ticket/3670 (el cierre >se reemplaza incorrectamente por >) que lleva al navegador a ignorar el contenido del script :

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

Yo mismo no poseo demasiado WP-Fu y buscar en Google solo me llevó a identificar el problema tal como está, así que mi pregunta sería: ¿cuándo exactamente WordPress ajusta los scripts en línea en las secciones CDATA? ¿Puede el usuario de alguna manera prevenir este comportamiento? ¿Puede el usuario solucionar el error anterior sin modificar el núcleo de WP?

themes javascript

— m90
fuente

Al pegar JS en línea en el editor, WP debe hacer este comportamiento. Sugiero poner en cola el JS usando wp_head o wp_enqueue_script ..

— Samuel Elh

¿Te refieres a "cuerpos de publicación" como en el editor WYSIWYG? Por lo que puedo ver, JS se envuelve en etiquetas CDATA cuando se imprimen los scripts (que se pueden invocar de varias maneras) pero no se pueden filtrar. Me imagino que, si no decir el WYSIWYG de un puesto, que podría ser algún tipo de filtrado en el contenido realizado por el tema.

— Doug Belchamber

No se recomienda publicar javascript en el editor WYSIWYG. El editor tiene una serie de filtros para limpiar su contenido que interactúan mal con js en línea. Hay complementos que ayudan en este tipo de escenario.

— MikeNGarrett

En realidad, no es WordPress el que inserta las CDATAetiquetas, sino el editor visual, TinyMCE. Aquí, los detalles de TinyMCE son extraños, pero puede leer una solución para esto en Stackoverflow .

Dicho esto, detener TinyMCE puede no ser la solución completa que desea. WordPress en sí también tiene una función para agregar CDATAetiquetas, wxr_cdataque se utiliza al generar un archivo xml válido, por ejemplo, si desea exportar el archivo o usar el contenido en una fuente rss. Los temas y / o complementos podrían decidir adjuntar este filtro al contenido si desean que el documento sea válido xhtml.

Aquí es donde te encuentras con el error , que se documentó por primera vez hace doce años y sigue sin resolverse. Se trata de estas tres líneas en the_content:

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

Como puede ver, str_replaceestá codificado, seguido inmediatamente por el eco. No hay forma de interceptar este reemplazo.

Lo que puede hacer, sin embargo, si controla su tema, es el almacenamiento intermedio the_content y revertir el reemplazo. Me gusta esto:

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

— cjbj
fuente