Kapan Wordpress membungkus skrip inline dalam CDATA?

Saya sedang men-debug masalah dengan skrip pihak ketiga milik kami yang digunakan pengguna wordpress dengan menyalin / menempelkan cuplikan skrip dan html ke tubuh postingan mereka seperti (contoh dunia non-nyata tentu saja):

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

Saya perhatikan bahwa beberapa instalasi wordpress akan membungkus ini dalam CDATA, beberapa tidak akan (mungkin dengan melakukan semacam pemeriksaan DOCTYPE - meskipun semua tema yang saya uji ini menggunakan doctype HTML5).

Namun, ketika membungkus skrip dalam CDATA, pengguna akan digigit oleh bug berikut: https://core.trac.wordpress.org/ticket/3670 (penutupan >tidak diganti dengan benar >) yang menyebabkan browser mengabaikan konten skrip :

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

Saya tidak memiliki terlalu banyak WP-Fu dan googling hanya membuat saya mengidentifikasi masalah apa adanya, jadi pertanyaan saya adalah: kapan tepatnya WordPress membungkus skrip inline ke dalam bagian CDATA? Dapatkah pengguna entah bagaimana mencegah perilaku ini? Dapatkah pengguna entah bagaimana mengatasi bug di atas tanpa mengubah WP core?

themes javascript

— m90
sumber

Saat menempelkan inline JS di editor, WP harus melakukan perilaku ini. Saya sarankan enqueuing JS menggunakan wp_head atau wp_enqueue_script ..

— Samuel Elh

Apakah yang Anda maksud "badan pos" seperti di editor WYSIWYG? Dari apa yang saya lihat, JS dibungkus dengan tag CDATA ketika skrip dicetak (yang dapat dipanggil dalam beberapa cara) tetapi tidak dapat disaring. Saya akan membayangkan, jika Anda tidak berarti WYSIWYG posting, mungkin ada beberapa penyaringan pada isi dilakukan oleh tema.

— Doug Belchamber

Anda tidak disarankan untuk memposting javascript di editor WYSIWYG. Editor memiliki sejumlah filter untuk membersihkan konten Anda yang berinteraksi buruk dengan inline js. Ada plugin yang membantu dalam skenario jenis ini.

— MikeNGarrett

Sebenarnya, bukan WordPress yang menyisipkan CDATAtag, tetapi editor visual, TinyMCE. Detail TinyMCE tidak tersedia di sini, tetapi Anda dapat membaca solusi untuk ini di Stackoverflow .

Yang mengatakan, menghentikan TinyMCE mungkin bukan solusi lengkap yang Anda inginkan. WordPress sendiri juga memiliki fungsi untuk menambahkan CDATAtag,, wxr_cdatayang digunakan saat mengeluarkan file xml yang valid, misalnya jika Anda ingin mengekspor file penggunaan konten dalam rss-feed. Tema dan / atau plugin dapat memutuskan untuk melampirkan filter ini ke konten jika mereka menginginkan dokumen tersebut valid xhtml.

Di sinilah Anda kemudian mengalami bug , yang pertama kali didokumentasikan dua belas tahun yang lalu dan tetap belum terpecahkan. Ini tentang tiga baris ini di the_content:

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

Seperti yang Anda lihat, str_replacehardcoded, segera diikuti oleh gema. Tidak ada cara untuk mencegat penggantian ini.

Apa yang dapat Anda lakukan, jika Anda mengontrol tema Anda, adalah buffer the_content dan membalikkan penggantinya. Seperti ini:

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

— cjbj
sumber