simon.schönbeck.dk

Tag: cdata

  • WordPress + CDATA nightmare

    Do you know what is worse than not knowing the solution or even the reason to a problem?

    Well, that must be, knowing that you have experienced the same problem in the past and resolved it, but no matter how much you try, you can not remember at all what the problem was due and what you did to fix it.

    So this evening several hours went by due to a silly and stupid WordPress issue I already fixed once in the past but lost during an upgrade. This time I wanted to make sure I got the solution written down as I would probably forget it again.

    On my Marbella news site I was working on embedding an external flash video inside an iframe, which itself was invoked via Javascript to avoid the W3 Validator complaining about XHTML 1.1 and iframes being taboo.

    Basically it was WordPress’ over-zealous filters that caught a greater-than sign (>) and converted it to the equivalent HTML entity (>). The most annoying thing is that I already have the Raw HTML plugin installed which disables WordPress’ text filtering. And it also worked fine for the rest of the Javascript and HTML tags in the page text. It was just on one single character, namely in the CDATA closing tag with // ]]> converted to // ]]>.

    After searching many different combinations I finally hit it on the nail. I was not alone either.

    The annoying culprit is this little line in /wp-includes/post-template.php, which I once more commented out:

    $content = str_replace(']]>', ']]>', $content);

    For some reason the WordPress developers have not yet fixed this issue after 3 years of it being reported.

    As a big fan of open source I appreciate the time and money spent by volunteers in many similar projects, however this is not the first time I see quick to fix issues hanging around for ages, simply due to people preferring to have an academic discussion on who can provide the most elegant solution, instead of simply fixing the issue first and talk later.

    Sometimes I wonder how projects ever become real projects.

    Anyhow there was a happy ending as you can see for yourself.

  • Google Analytics XHTML compliance

    I had to add the Google Analytics code snippet to this site and had some issues with it validating as XHTML 1.1 and MIME type application/xhtml+xml which were solved at the end.

    The snippet is divided into two pieces of <script> tags and the first part is simply a feature to avoid getting warning messages from your browser if your page was server over SSL (https://). If your site serves pages in both HTTP and HTTPS then you can achieve the same through e.g. a server side scripting language such as PHP.

    The snippet needs to be changed to the following on HTTP pages:

    <script src="http://www.google-analytics.com/ga.js" type="text/javascript"></script>

    and of course on HTTPS pages use this piece:

    <script src="https://www.google-analytics.com/ga.js" type="text/javascript"></script>

    Now the second part of the code needs to be put between CDATA tags to properly isolate it. The code will now look like this except you need to introduce your own Google Analytics ID:

    <script type="text/javascript">
//<![CDATA[
var pageTracker = _gat._getTracker("UA-1234567-8");
pageTracker._initData();
pageTracker._trackPageview();
//]]>
</script>

    Now you can safely run the W3 Validator without any errors caused by Google Analytics.