Quando Wordpress avvolge gli script incorporati in CDATA?

Sto eseguendo il debug di un problema con uno dei nostri script di terze parti che gli utenti di wordpress usano copiando / incollando uno snippet di script e html nei corpi dei loro post come (esempio del mondo non reale ovviamente):

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

Ho notato che alcune installazioni di wordpress lo avvolgeranno in CDATA, altre no (probabilmente facendo una sorta di controllo DOCTYPE - sebbene tutti i temi su cui ho testato usassero un doctype HTML5).

Tuttavia, quando si avvolge lo script in CDATA, gli utenti verranno morsi dal seguente bug: https://core.trac.wordpress.org/ticket/3670 (la chiusura >viene erroneamente sostituita da >) che porta al browser ignorando il contenuto dello script :

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

Non possiedo troppo WP-Fu da solo e googling mi ha portato a identificare il problema così com'è, quindi la mia domanda sarebbe: quando WordPress avvolge esattamente gli script incorporati nelle sezioni CDATA? L'utente può in qualche modo prevenire questo comportamento? L'utente può in qualche modo aggirare il bug sopra senza modificare il core WP?

themes javascript

— m90
fonte

Quando si incolla JS in linea nell'editor, WP dovrebbe eseguire questo comportamento. Suggerisco di accodare il JS usando wp_head o wp_enqueue_script ..

— Samuel Elh,

Intendi "corpi dei post" come nell'editor WYSIWYG? Da quello che posso vedere, JS viene racchiuso nei tag CDATA quando gli script vengono stampati (che potrebbero essere invocati in diversi modi) ma non sono filtrabili. Immagino, se non intendi la WYSIWYG di un post, potrebbe essere un po 'di filtraggio sui contenuti fatto da tema.

— Doug Belchamber,

Non è consigliabile pubblicare javascript nell'editor WYSIWYG. L'editor ha una serie di filtri per ripulire i tuoi contenuti che interagiscono male con js inline. Ci sono plugin che aiutano in questo tipo di scenario.

— MikeNGarrett,

In realtà, non è WordPress che sta inserendo i CDATAtag, ma l'editor visivo, TinyMCE. I dettagli di TinyMCE sono fuori tema qui, ma puoi leggere una soluzione su Stackoverflow .

Detto questo, interrompere TinyMCE potrebbe non essere la soluzione completa che desideri. WordPress stesso ha anche una funzione per l'aggiunta di CDATAtag, wxr_cdatache viene utilizzato quando si genera un file xml valido, ad esempio se si desidera esportare il file di utilizzo del contenuto in un feed rss. Temi e / o plugin potrebbero decidere di allegare questo filtro al contenuto se vogliono che il documento sia xhtml valido.

Qui è dove ti imbatti nel bug , che è stato documentato per la prima volta dodici anni fa e rimane irrisolto. Riguarda queste tre righe in the_content:

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

Come puoi vedere, str_replaceè hardcoded, seguito immediatamente dall'eco. Non c'è modo di intercettare questa sostituzione.

Ciò che puoi fare, tuttavia, se controlli il tema, è buffer the_content e invertire la sostituzione. Come questo:

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

— cjbj
fonte