simon.schönbeck.dk

Tag: character

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

  • Error: Could not open the local file – FTP madness!

    Trying to move some automatic backups from one location to another became a bit of a struggle recently. The backups are created automatically and uploaded to a file server at a scheduled pattern. From this file server I had to use some of the backups and tried to download them to my local machine. This is where the problem started.

    I am long time user of the excellent FTP client named FileZilla and very seldom experience any issues with it. But this time during the download process I kept receiving this weird error message:

    Error:    Could not open the local file path/filename
    Error:    Download failed

    I initially thought about some permission problems like no read access until I swiftly realised it was actually on the local side the issue was and not on the server. This just made no sense as obviously why would it want to open the file when it actually had to create the file instead. I tried to download the backups to different locations on the hard disks, even external ones as well, to see if oddly enough they had magically become write protected. This was not successful and I started to think of the directory structure as downloading the individual file worked just fine.

    So to summarise:

    1. Downloading the directory containing the backups did not work.
    2. Downloading each individual file inside the directory worked as expected.

    Very strange indeed…

    I actually did not break it until the following morning when I woke up with the solution. I am not sure what happened as I would not dream about such a pity issue but I just woke up and Eureka!

    In hindsight it was really obvious what the problem was but at the point it just did not come to my mind.

    Linux and Windows have some dramatic differences and one of them is the fact that file and directory names under Windows are limited to certain characters while Linux pretty much takes it all. I was trying to download directories to a Windows XP PC with a colon (:) in the name, such as . This is incompatible with Windows and therefore FileZilla was not permitted to create such directories anywhere on the hard disks.

    Never use the following characters in file or directory names if you expect Windows compatibility:

    / \ : * ? " < > |