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 &lt; 5 &amp;&amp; bar &gt; 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 –

Unfortunately when I tried to go there I got:

Parse error: syntax error, unexpected $end in /home/felho/www/  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 htmlspecialchars_decode() 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 htmlspecialchars_decode() 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 (which is still down :)) and google cache.   

Image by Dr Case

  • Oh, I hadn’t even noticed this. I never use the visual editor; I write posts in WriteRoom and cut’n’paste HTML in WordPress.

    Looks like the HTML escaping is done twice. Once by the WordPress visual editor, then again by WP-Syntax. It would be nice if WP-Syntax had an option to set the default value of escaped to “true”. Now it’s unset by default, so you get this problem.

    I would, maybe, place this bug in the WordPress side. It’s not OK for WP to behave differently depending on which editor you use. The raw editor should sanitize the HTML just like the visual editor does. Although, I can see how that could be a problem as well if the sanitizer is too eager to mess with your carefully hand-crafted HTML.

    • Hi Ville,

      I write all my posts as plain text and so find the visual editor really nice for quick editing especially since I’ve started using the FCKEditor plugin :).

      You’re probably right about the double escaping, I am just glad I don’t have to worry about this special character thing, it was highly annoying.

  • Alan,

    I actually used WP Syntax on my website for a while, but I found it to be very annoying (I had the same issue you were having).

    This is not meant to be spam, but I did write an article on a code formatting solution that I think looks and functions much better than WP Syntax: Code Formatting and Coloring in WordPress without a Plugin .

    BTW, I love your site and I bookmarked it.

    • Hi Chris,

      Your article looks very interesting, certainly well worth considering if you don’t want to use a plugin for code formatting. I am much happier with WP-Syntax now that I’ve fixed that escaping issue :).

      Thanks, I am glad you like my blog :).

  • I had the same issue and feel your pain. I found similar pages and carried out the change. From what I understand, in your pre tag, you’re meant to add escaped=”true” or something like that as an attribute, but I couldn’t get it to work, so I just stuck in the htmlspecialchars_decode.


  • Alan,

    Nice blog post. As James mentioned, on the plugin site itself (, it does mention the you can add the “escaped” attribute to the “pre” tag. I’m certain this wasn’t always there. I’m pretty sure this was only recently added. This works for me. James, not sure what your problem is.

    • Thanks Gerard, maybe I’ll give that a go as well.

  • thanks you
    very good topic
    but can you help me to use it my blog don’t allow upload new plugin

  • orçun candan

    working well.
    Thanks much

  • Thanks, you solved my problem!

  • I can not even tell you how much time and effort you have saved me. I have probably 40 or 50 posts that I just moved to using WP-Syntax, and was completely frustrated with the plugin. Once again, thanks!

  • Voles

    Thank you, works for me! :-)

    Btw, is back online (see for the post about WP-syntax).

  • Willy

    Excellent. thank you very much. I searched a lot this solution and had to use a translator to understand this post. My native language is Spanish.

    Congratulations Alan