Quando o Wordpress quebra scripts embutidos no CDATA?

Estou depurando um problema com um script de terceiros que os usuários do wordpress usam copiando / colando um trecho de script e html nos corpos de seus posts, como (exemplo do mundo não real, é claro):

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

Notei que algumas instalações do wordpress envolvem isso no CDATA, outras não (provavelmente fazendo algum tipo de verificação DOCTYPE - embora todos os temas em que eu testei isso usassem um doctype HTML5).

No entanto, ao agrupar o script no CDATA, os usuários serão mordidos pelo seguinte bug: https://core.trac.wordpress.org/ticket/3670 (o fechamento >é substituído incorretamente por >), o que leva o navegador a ignorar o conteúdo do script :

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

Eu não possuo muito WP-Fu e o Google só me levou a identificar o problema como está, então minha pergunta seria: quando exatamente o WordPress agrupa scripts embutidos em seções CDATA? O usuário pode de alguma forma impedir esse comportamento? O usuário pode, de alguma forma, solucionar o bug acima sem modificar o núcleo do WP?

themes javascript

— m90
fonte

Ao colar JS embutido no editor, o WP deve fazer esse comportamento. Sugiro enqueuing a JS usando wp_head ou wp_enqueue_script ..

— Samuel ELH

Você quer dizer "corpos da postagem" como no editor WYSIWYG? Pelo que pude ver, o JS é envolvido em tags CDATA quando os scripts são impressos (que podem ser chamados de várias maneiras), mas não são filtráveis. Eu imagino que, se você não significa que o WYSIWYG de um post, pode haver alguma filtragem de conteúdo feito pelo tema.

— Doug Belchamber 17/03

Não é recomendável que você publique javascript no editor WYSIWYG. O editor possui vários filtros para limpar seu conteúdo que interage mal com os js inline. Existem plugins que ajudam nesse tipo de cenário.

— MikeNGarrett

Na verdade, não é o WordPress que está inserindo as CDATAtags, mas o editor visual, TinyMCE. Os detalhes do TinyMCE são offtopic aqui, mas você pode ler uma solução para isso no Stackoverflow .

Dito isto, interromper o TinyMCE pode não ser a solução completa que você deseja. O próprio WordPress também tem uma função para adicionar CDATAtags, wxr_cdataque é usada na saída de um arquivo xml válido, por exemplo, se você deseja exportar o arquivo de uso do conteúdo em um feed RSS. Os temas e / ou plug-ins podem decidir anexar esse filtro ao conteúdo se quiserem que o documento seja xhtml válido.

É aqui que você encontra o bug , que foi documentado pela primeira vez há doze anos e permanece sem solução. É sobre estas três linhas em the_content:

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

Como você pode ver, o str_replacecódigo é codificado, imediatamente seguido pelo eco. Não há como interceptar essa substituição.

O que você pode fazer, no entanto, se você controla seu tema, é buffer the_content e reverte a substituição. Como isso:

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

— cjbj
fonte