In Zusammenhang mit dem XHTML-konformen Einbau von Google-Maps stieß ich (mal wieder) auf zwei Probleme: Als ich das JavaScript mit dem CDATA-Block einfügen wollte, kam mir WordPress mit seinen sonst so angenehmen automatischen Formatierungen ins Gehege. Da wurde nämlich aus dem Endmarker
/* ]]> */
plötzlich folgendes:
/* ]]> */
Schuld daran ist eine Zeile in der Datei wp-includes/post-template.php
, die da lautet:
$content = str_replace(']]>', ']]>', $content);
Wozu diese Zeile überhaupt jemals gut sein soll, ist mir ein Rätsel. Warum das Ganze nicht als Filter umgesetzt wurde, den man bei Bedarf auch mal abschalten kann, ist mir ebenfalls ein Rätsel. Schon seit zwei Jahren bitten etliche Leute darum, diese Zeile abzuschaffen oder irgendwie anders zu realisieren. Da bleibt nur warten und hoffen, daß es eines fernen Tages in einer kommenden WordPress-Version geändert wird.
In der Zwischenzeit aber bleibt einem wohl nichts anderes übrig, als die oben zitierte Zeile einfach auszukommentieren – auch wenn ich solche Lösungen, die ein Rumpfuschen im Quellcode erfordern, nicht so gerne habe. Dann klappt’s auch mit den CDATA-Blöcken – oder zumindest schonmal mit deren Definition.
Nun fügt man so einen CDATA-Block ja eigentlich nur aus einem Grund ein, nämlich damit man auch Zeichen wie <
, >
usw. verwenden kann, ohne sie in HTML-Entities umwandeln zu müssen. So kann man dann beispielsweise auch innerhalb eines JavaScripts HTML notieren, ohne daß der Browser davon irritiert wird.
Wordpress aber wandelt alle betreffenden Zeichen innerhalb des CDATA-Blocks trotzdem in HTML-Entities um. Das liegt an der Funktion wpautop()
, die uns normalerweise das Leben sehr erleichtert, indem sie alle Sonderzeichen in Posts für uns in HTML-Entities umwandelt. In diesem speziellen Fall aber wollen wir ja gar nicht, daß sie umgewandelt werden! Wir müssen also den Filter wpautop()
irgendwie abschalten.
Aber zum Glück gibt es ja für fast alles ein Plugin – so auch hierfür. „TextControl“ heißt es und ist hier erhätlich. Übrigens wird es zur Verwendung von JavaScript in WordPress-Posts sogar von offizieller Seite empfohlen. Mit diesem Plugin kann man für jeden Post einzeln oder aber auch blogweit die automatische Formatierung deaktivieren. Um die Umwandlung von Sonderzeichen abzuschalten, genügt es, im zweiten Dropdown-Menü „No Character Encoding“ anstatt „Default (wptexturize)“ auszuwählen.
[:] [:en]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 Antworten zu “[:de]JavaScript und CDATA-Blöcke in WordPress-Posts[:en]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. ;)