How To Fix The WP-Syntax Special Character Escaping Issue

I use WordPress as my blogging platform, it’s a great tool, has a heap of plugins so you can do much with very little effort, which suits me fine :). As a software development blog I often have code snippets that I need to post and I want these to look good (i.e. formatting, syntax highlighting). This is why I use the WP-Syntax WordPress plugin. I am not going to go into why it’s so great, if you’re curious you can check it out for yourself. Suffice to say, it does the job fine except for one very annoying issue. Whenever you have any kind of special characters in your code (which you inevitably do e.g. <, >, & etc.), these always render as their escaped representations. For example if you wanted to write:

if (foo < 5 && bar > 6)

you would end up with:

if (foo < 5 && bar > 6)

Extremely annoying. This only happens if you use the WYSIWYG editor in WordPress, which is why the plugin FAQ recommends switching off the visual editor and using the source code editor, but that eventually gets to be beyond annoying.

The other day my annoyance threshold reached it’s limit and I decided to find a solution to this issue. I armed myself with an apple (for munching purposes :)) and set to googling. I eventually found a couple of sites which mentioned this issue e.g. this one and this one. Both of these tried to point me to the following link – http://blog.felho.hu/escaping-problem-with-wp-syntax-wordpress-plugin.html.

Unfortunately when I tried to go there I got:

Parse error: syntax error, unexpected $end in /home/felho/www/blog.felho.hu/wp-includes/default-filters.php  on line 213

What a massive fail! Most of the time you don’t want to duplicate information that can be found in other places on the web (which is why we link), but sometimes the beauty of the internet is the fact that you can find the same info in many different places. In this case – the internet failed. The information was only to be found in one place (with everyone else linking there) and that place was dead.

Thankfully the magic of google cache came to the rescue and I was able to recover the original post. So, in the interest keeping the information alive on the web :), I’ll re-post the solution here. Here is what you need to do to fix that special character escaping issue:

Jump into your WordPress configuration and deactivate the WP-syntax plugin for the moment
Jump into your WP-syntax plugin folder, in my case it was the wp-content/plugins/wp-syntax folder under the root of your WordPress install
Crack open the wp-syntax.php file and find the wp_syntax_highlight function (in my case it was on line 94)
Inside the function find the following line:

$geshi = new GeSHi($code, $language);

Replace this line with the following:

$geshi = new GeSHi(htmlspecialchars_decode($code), $language);

If you’re running your WordPress install on a server with a PHP version which is older than 5.1, you will not actually have the _htmlspecialcharsdecode() function. Of course I would be surprised if your PHP version was older than 5.1, but just in case it is, here is what you need to do. You will need to roll your own _htmlspecialcharsdecode() function, so put in the following code right before the line that you replaced above:

if (!function_exists("htmlspecialchars_decode")) {
    function htmlspecialchars_decode($string, $quote_style = ENT_COMPAT) {
        return strtr($string, array_flip(get_html_translation_table(HTML_SPECIALCHARS, $quote_style)));
    }
}

Save and exit the file and then go an reactive your plugin in the WordPress config.

This should solve your special character escaping issue – it solved mine.

Here is the funny thing, after I made sure everything was working I went and had a look at the code in wp-syntax.php again, and here is what I found right above the line that we replaced:

if ($escaped == "true") $code = htmlspecialchars_decode($code);

Now, I am no PHP expert, but it looks like we shouldn’t have needed to do what we did, this line should have taken care of everything, but obviously $escaped isn’t equal to “true” and so _htmlspecialchars_decode()_ function never gets called (either that or it does get called, but shouldn’t be). I didn’t really want to experiment with my live blog, but if you have a extraneous WordPress install with WP-syntax floating around somewhere feel free to poke around. It feels like this shouldn’t be an issue. Anyways, do let me know if you find something out. In the meantime you have a work-around thanks to blog.felho.hu (which is still down :)) and google cache.

Image by Dr Case

Table of Contents