Tag: html

  • 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.

  • <code> vs. <pre> in WordPress editor

    Writing my earlier post about the textarea issue I initially ended up with a funny looking post. It was due to the examples of HTML code included in the post not being parsed properly. Apparently I had been writing my post in HMTL mode instead of Visual mode and all the HTML code was parsed as “real” code.

    The code was wrapped in <code> tags, instead of the usual <pre> tags which keeps the code looking as expected.

    If you are neither certain of the exact uses of each of these two tags I suggest you read this documentation page for a quick overview of the differences along with other usage hints.

  • HTML textarea default value line breaks

    This one I struggled to find the right formula to get it working. The solution was so simple and basic that I wonder why I did not just try it before all the complicated approaches.

    I basically needed to have line breaks occurring in the default value of a textarea field inside a HTML form. That is between the <textarea>…</textarea> tags.

    My first approach was to simply add \n where I wanted a line break. I also tried all possible combinations of \r, \n, CR, LF, separate, together, quoted, escaped… you name it. Nothing worked.

    Googling around proved no good. Most people kept referring to the nl2br function in PHP, but this is not what I was trying to achieve. Besides this is all client code, pure HTML, no server side processing involved.

    I ended up at the W3 HTML specification and saw the light! A simple example copied from their site included the solution to all my struggles:

    <FORM action="http://somesite.com/prog/text-read" method="post">
       <P>
       <TEXTAREA name="thetext" rows="20" cols="80">
       First line of initial text.
       Second line of initial text.
       </TEXTAREA>
       <INPUT type="submit" value="Send"><INPUT type="reset">
       </P>
    </FORM>

    Notice how they simply added a line break in the actual HTML source. This is so simple that you may even not notice the subtle difference. Let me show you how I had my initial code:

    <form>
    <p>Some random paragraph</p>
    <textarea>First line \n Second line</textarea>
    <p>Some more randomness</p>
    </form>

    As normally white space in HTML is simply ignored I did not give a thought about the fact that a line break can be created in the default textarea value by simply…, yes, adding a line break when writing the source code.