Kiedy Wordpress pakuje wbudowane skrypty w CDATA?

Debuguję problem z naszym skryptem innej firmy, którego używają użytkownicy Wordpress, kopiując / wklejając fragment skryptu i html do treści swoich postów, jak (przykład z nierealnego świata):

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

Zauważyłem, że niektóre instalacje wordpress będą owijać to w CDATA, inne nie (prawdopodobnie wykonując pewnego rodzaju sprawdzenie DOCTYPE - chociaż wszystkie motywy, na których testowałem to używają doctype HTML5).

Jednak podczas owijania skryptu w CDATA użytkownicy zostaną ugryzieni przez następujący błąd: https://core.trac.wordpress.org/ticket/3670 (zamknięcie >jest niepoprawnie zastąpione przez >), co powoduje, że przeglądarka ignoruje treść skryptu :

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

Sam nie posiadam zbyt wiele WP-Fu, a googling doprowadził mnie do zidentyfikowania problemu w obecnej postaci, więc moje pytanie brzmiałoby: kiedy dokładnie WordPress pakuje wbudowane skrypty w sekcje CDATA? Czy użytkownik może jakoś temu zapobiec? Czy użytkownik może w jakiś sposób obejść powyższy błąd bez modyfikowania rdzenia WP?

themes javascript

— m90
źródło

Podczas wklejania wbudowanego JS w edytorze WP powinno to zrobić. Sugeruję kolejkowanie JS za pomocą wp_head lub wp_enqueue_script ..

— Samuel Elh

Masz na myśli „ciała postów” jak w edytorze WYSIWYG? Z tego, co widzę, JS jest pakowany w tagi CDATA, gdy skrypty są drukowane (które można wywoływać na wiele sposobów), ale nie można ich filtrować. Wyobrażam sobie, że jeśli masz na myśli WYSIWYG postu, może to być pewne filtrowanie treści wykonanych przez ten temat.

— Doug Belchamber

Nie zaleca się publikowania javascript w edytorze WYSIWYG. Edytor ma wiele filtrów do czyszczenia zawartości, która źle współdziała z wbudowanym js. Istnieją wtyczki, które pomagają w tego typu scenariuszu.

— MikeNGarrett

W rzeczywistości to nie WordPress wstawia CDATAtagi, ale edytor wizualny, TinyMCE. Szczegóły TinyMCE są tutaj nie na temat, ale możesz przeczytać rozwiązanie tego problemu na Stackoverflow .

To powiedziawszy, zatrzymanie TinyMCE może nie być pełnym rozwiązaniem, którego oczekujesz. Sam WordPress ma również funkcję dodawania CDATAznaczników, wxr_cdataktóra jest używana podczas wyprowadzania prawidłowego pliku xml, na przykład, jeśli chcesz wyeksportować plik użycia zawartości w kanale rss. Motywy i / lub wtyczki mogą zdecydować o dołączeniu tego filtru do treści, jeśli chcą, aby dokument był prawidłowy xhtml.

To tutaj natrafisz na błąd , który został po raz pierwszy udokumentowany 12 lat temu i pozostaje nierozwiązany. Chodzi o te trzy wiersze w the_content:

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

Jak widać, str_replacejest on zakodowany na stałe, a zaraz po nim następuje echo. Nie ma sposobu, aby przechwycić tę wymianę.

Jeśli jednak kontrolujesz swój motyw, możesz buforować the_content i cofać zamianę. Lubię to:

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

— cjbj
źródło