Wordpress satır içi komut dosyalarını CDATA'da ne zaman sarar?

Wordpress kullanıcılarının, komut dosyası ve html snippet'ini kopyalayarak / postlarının gövdelerine (elbette gerçek olmayan dünya örneği) yapıştırarak kullandıkları bir üçüncü taraf komut dosyasıyla ilgili bir sorunu ayıklamaktayım:

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

Bazı wordpress kurulumlarının bunu CDATA'da saracağını fark ettim, bazıları olmayacak (muhtemelen bir çeşit DOCTYPE kontrolü yaparak - bunu test ettiğim tüm temalar bir HTML5 dokümanı kullanıyor olsa da).

Ancak, komut dosyasını CDATA'ya sararken kullanıcılar şu hata tarafından ısırılır: https://core.trac.wordpress.org/ticket/3670 (kapanış >yanlış değiştirildi >), bu da tarayıcının komut dosyası içeriğini yok saymasına neden oluyor :

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

Çok fazla WP-Fu'ya sahip değilim ve googling sadece sorunu olduğu gibi tanımlamama neden oldu, bu yüzden sorum şu olurdu: WordPress satır içi komut dosyalarını CDATA bölümlerine tam olarak ne zaman sarıyor? Kullanıcı bir şekilde bu davranışı önleyebilir mi? Kullanıcı WP çekirdeğini değiştirmeden bir şekilde yukarıdaki hata etrafında çalışabilir mi?

themes javascript

— m90
kaynak

Satır içi JS'yi düzenleyiciye yapıştırırken, WP bu davranışı gerçekleştirmelidir. Ben wp_head veya wp_enqueue_script kullanarak JS sıkma öneririz ..

— Samuel Elh

Şunu mu demek istediniz: WYSIWYG editöründe olduğu gibi "post's body"? Görebildiğim kadarıyla, komut dosyaları yazdırıldığında (çeşitli şekillerde çağrılabilir) JS CDATA etiketlerine sarılır, ancak filtrelenemez. Eğer ben, hayal ediyorum do bir yazının WYSIWYG Yani, tema tarafından yapılan içeriğine bazı filtreleme olabilir.

— Doug Belchamber

Javascript'i WYSIWYG editöründe yayınlamanız önerilmez. Düzenleyicide, satır içi j'lerle zayıf etkileşimde bulunan içeriğinizi temizlemek için bir dizi filtre vardır. Bu tür senaryoda yardımcı olan eklentiler vardır.

— MikeNGarrett

Aslında, CDATAetiketleri ekleyen WordPress değil, görsel düzenleyici TinyMCE. TinyMCE'nin detayları burada offtopiktir, ancak Stackoverflow'da buna bir çözüm okuyabilirsiniz .

Bununla birlikte, TinyMCE'yi durdurmak istediğiniz tam çözüm olmayabilir. WordPress'in kendisi de geçerli bir xml dosyası çıkarılırken kullanılan CDATAetiket ekleme işlevine sahiptir wxr_cdata; örneğin, kullanım dosyasını bir rss feed'indeki içeriği dışa aktarmak istiyorsanız. Temalar ve / veya eklentiler, belgenin geçerli xhtml olmasını isterse, bu filtreyi içeriğe eklemeye karar verebilir.

Sonra girmek burasıdır hata ilk oniki yıl önce belgelenmiş ve çözümsüz kalır edildi. Bu şu üç çizgi ile ilgilidir the_content:

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

Gördüğünüz gibi str_replace, kodlaması sabittir, hemen yankı izler. Bu değiştirme işlemini engellemenin bir yolu yoktur.

Ancak, temanızı kontrol ederseniz, arabellek the_content ve değiştirmeyi tersine çevirebilirsiniz. Bunun gibi:

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

— cjbj
kaynak