Коли 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, і гуглінг лише призвів до того, щоб визначити проблему такою, якою є, тому моє питання було б: коли саме WordPress загортає вбудовані сценарії в розділи CDATA? Чи може користувач якось запобігти такій поведінці? Чи може користувач якось обходити вищезгадану помилку, не змінюючи ядро WP?

themes javascript

— m90
джерело

Під час вставки вбудованого JS в редактор, WP повинен виконувати цю поведінку. Я пропоную зайнятися JS, використовуючи wp_head або wp_enqueue_script ..

— Самуель Ель

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

— Doug Belchamber

Не рекомендується публікувати 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
джерело