Wordpress何时将内联脚本包装在CDATA中？

我正在调试我们的第三方脚本存在的问题，Wordpress用户通过将脚本和html的片段复制/粘贴到其帖子的正文中来使用它们（当然是非现实示例）：

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

我注意到有些wordpress安装会将其包装在CDATA中，有些则不会（可能通过进行某种DOCTYPE检查-尽管我测试过的所有主题都使用HTML5 doctype）。

但是，当将脚本包装在CDATA中时，用户将受到以下bug的叮咬：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
source

在编辑器中粘贴内联JS时，WP应该执行此行为。我建议使用的排队JS wp_head或wp_enqueue_script ..

— 塞缪尔ELH

您所指的是“所见即所得”编辑器中的“职位的尸体”吗？据我所知，当打印脚本时，JS被包裹在CDATA标记中（可以通过多种方式调用），但是它们是不可过滤的。我想，如果您确实希望发布帖子的所见即所得，可能是对主题所完成内容的过滤。

— Doug Belchamber

不建议您在WYSIWYG编辑器中发布javascript。编辑器具有许多过滤器，用于清理与内联js交互不良的内容。有一些插件可在这种情况下提供帮助。

— MikeNGarrett

实际上，插入CDATA标签的不是WordPress ，而是可视编辑器TinyMCE。TinyMCE的详细信息不在此处，但是您可以在Stackoverflow上阅读有关此问题的解决方案。

也就是说，停止TinyMCE可能不是您想要的完整解决方案。WordPress本身还具有添加CDATA标签的功能wxr_cdata，该功能在输出有效的xml文件时使用，例如，如果您要在rss提要中导出使用内容的文件。如果主题和/或插件希望文档为有效的xhtml，则可以决定将此过滤器附加到内容。

然后您会在这里遇到bug，该bug于12年前被首次记录，至今仍未解决。关于以下三行内容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;

— j
source