In the context of the XHTML-conform embedding of Google Maps, I encountered two problems (again): When I tried to insert the JavaScript with the CDATA section, WordPress got under my feet with its usually so comfortable automatic formatting functions. The end marker
/* ]]> */
suddenly became:
/* ]]> */
A line in the file wp-includes/post-template.php
is to blame for this, which reads:
$content = str_replace(']]>', ']]>', $content);
It’s a mystery to me what this line should ever be good for at all. It is also a mystery to me why the whole thing hasn’t been implemented as a filter that you could turn off when needed. For two years already, several people have been asking for this line to be removed or realized some other way. We can only wait and hope that one far day, this will be changed in a future WordPress release.
In the meantime, there is no other choice but to simpy comment the cited line – even though I don’t appreciate solutions that require messing about with the source code. After that, the CDATA sections work fine – or at least their definition does.
Now, CDATA sections are usually being inserted for only one reason, namely for being able to use characters like <
, >
etc. without having to convert them into HTML entities. This way, you can for example use HTML inside of a JavaScript without the browser getting irritated by it.
Wordpress however still converts all concerning characters inside the CDATA section in HTML entities. This is caused by the function wpautop()
which normally makes our life much easier by converting all the special characters in a post into HTML entities for us. In this special case however, we actually don’t want them to be converted! So we have to turn off the filter wpautop()
somehow.
But luckily, there is a plugin for almost everything – including this. It’s called “TextControl” and can be obtained here. By the way, it is even being recommended officially for the use of JavaScript in WordPress posts. With this plugin, you can disable automatic formatting for each post individually or blog-wide. To turn off the conversion of special characters you only have to select “No Character Encoding” instead of “Default (wptexturize)” from the second dropdown menu.
4 responses to “JavaScript and CDATA sections in WordPress posts”
Five years later and this still isn’t fixed!
Yeah. Still not fixed! Nice work!
Es gibt immer noch keinen Fix dafür – aber man kann auch ohne Änderung am Core-Code von WordPress das Problem lösen mit einer kleinen Funktion im eigenen Template (oder einem eigenen Plugin dafür).
Siehe hier:
https://core.trac.wordpress.org/ticket/3670#comment:72
Das nutze ich so bei mir und hatte damit bisher keine Probleme – und ich muss nicht bei jedem WordPress-Update daran denken, die Änderung im Core-Code nachzuziehen.
Du hast recht, heute würde ich es auch so lösen. Genauso wie ich heutzutage
wpautop()
immer perfunctions.php
deaktiviere. Aber als ich das damals geschrieben habe, war ich noch ein totaler WordPress-Neuling und hatte keine Ahnung, dass das geht. :)Ich sollte den Post also mal updaten. ;)