Когда Wordpress оборачивает встроенные скрипты в CDATA?

Я отлаживаю проблему с нашим сторонним скриптом, который используют пользователи WordPress, скопировав / вставив фрагмент скрипта и html в тела своего поста, например (пример не из реального мира):

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

Я заметил, что некоторые установки WordPress обернут это в CDATA, а некоторые - нет (возможно, с помощью какой-то проверки DOCTYPE - хотя все темы, на которых я проверял это, использовали тип документа HTML5).

Тем не менее, при переносе скрипта в CDATA пользователи будут укушены следующей ошибкой: https://core.trac.wordpress.org/ticket/3670 (закрытие >неправильно заменено на >), которая приводит к тому, что браузер игнорирует содержимое скрипта. :

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

Я сам не слишком много владею WP-Fu, и поиск в Google привел меня к выявлению проблемы как есть, поэтому мой вопрос был бы таков: когда именно WordPress переносит встроенные скрипты в разделы CDATA? Может ли пользователь как-то предотвратить это поведение? Может ли пользователь как-то обойти вышеуказанную ошибку, не модифицируя ядро WP?

themes javascript

— m90
источник

При вставке встроенного JS в редактор, WP должен делать это. Я предлагаю поставить JS в очередь с помощью wp_head или wp_enqueue_script ..

— Сэмюэль Эльх,

Вы имеете в виду "тела сообщения", как в редакторе WYSIWYG? Из того, что я вижу, JS упаковывается в теги CDATA, когда скрипты печатаются (которые могут быть вызваны несколькими способами), но не фильтруются. Я бы себе, если вы действительно имеете в виду WYSIWYG занимаемой должности, это может быть какой - то фильтрация контента делается темой.

— Даг Белчамбер

Не рекомендуется размещать JavaScript в редакторе WYSIWYG. В редакторе есть ряд фильтров для очистки вашего контента, которые плохо взаимодействуют со встроенными js. Есть плагины, которые помогают в этом типе сценария.

— MikeNGarrett

На самом деле, это не WordPress, который вставляет CDATAтеги, а визуальный редактор TinyMCE. Подробная информация о TinyMCE здесь оффтопна, но решение об этом вы можете прочитать в Stackoverflow .

Тем не менее, остановка TinyMCE не может быть полным решением, которое вы хотите. В самом WordPress также есть функция добавления CDATAтегов, wxr_cdataкоторая используется при выводе действительного xml-файла, например, если вы хотите экспортировать файл из содержимого в rss-ленту. Темы и / или плагины могут решить присоединить этот фильтр к контенту, если они хотят, чтобы документ был действительным xhtml.

Здесь вы можете столкнуться с ошибкой , которая была впервые задокументирована двенадцать лет назад и остается нерешенной. Это об этих трех строках the_content:

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

Как вы можете видеть, str_replaceон жестко закодирован, за ним сразу следует эхо. Нет способа перехватить эту замену.

Что вы можете сделать, однако, если вы контролируете свою тему, это буфер the_content и обратная замена. Как это:

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

— cjbj
источник