yellowup.com

In my previous article I picked WP-Syntax as my plugin of choice for syntax highlighting. At the time of writing I was using version 0.7. The plugin is not perfect: there are a few issues that need to be addressed. I will do so in this article.

Using the visual editor messes up your code snippets

In order to use WP-Syntax, or any syntax highlighting plugins for that matter, you will have to give up using the visual editor. Which is a shame, because that happens to be one of WordPress’s strong suit. Fortunately, Shantanu Goel devised a quick fix which I have adopted to hack WP-Syntax.

In wp-syntax.php, find:

1
2
3
4
5
6
7

function wp_syntax_code_trim($code)
{
    // special ltrim b/c leading whitespace matters on 1st line of content
    $code = preg_replace("/^\s*\n/siU", "", $code);
    $code = rtrim($code);
    return $code;
}

Replace with:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

function wp_syntax_code_trim($code)
{
    // special ltrim b/c leading whitespace matters on 1st line of content
    $code = preg_replace("/^\s*\n/siU", "", $code);
    $code = rtrim($code);
 
    $code = strip_tags($code);
    if (PHP_VERSION > 5.0) {
    	$code = html_entity_decode($code, ENT_QUOTES, "UTF-8");
    } else {
      $arrSearch = array("<", ">", " ", "&");
      $arrReplace = array("<", ">", " ", "&");
      $code = str_replace($arrSearch, $arrReplace, $code);
    }
 
    return $code;
}

You can now continue to use the visual editor. Simply add a <pre> block with the lang (and possibly class) attribute and paste the code in the visual editor. WordPress will no longer mess up your code.

The line attribute for line numbering is invalid (X)HTML

This might not seem like a big deal, because it is only used as an instruction for WP-Syntax, it does not end up in the final output. Unfortunately, now that we have hacked WP-Syntax to work in the visual editor, WordPress will add its two cents: it will strip the line attribute automatically to make the code XHTML valid. Fortunately, this is easily fixed.

If you recall, the Highlight Source Pro plugin abuses the class attribute for the same purpose. This is valid XHTML, so WordPress will allow it. We can hack WP-Syntax and swap out line for class in much the same way.

In wp-syntax.php, find:

1
2
3
4
5
6
7
8

function wp_syntax_before_filter($content)
{
    return preg_replace_callback(
        "/\s*<pre(?:lang=[\"']([\w-]*)[\"']|line=[\"'](\d*)[\"']|\s)+>(.*)<\/pre>\s*/siU",
        "wp_syntax_substitute",
        $content
    );
}

Change this to:

1
2
3
4
5
6
7
8

function wp_syntax_before_filter($content)
{
    return preg_replace_callback(
        "/\s*<pre(?:lang=[\"']([\w-]*)[\"']|class=[\"'](\d*)[\"']|\s)+>(.*)<\/pre>\s*/siU",
        "wp_syntax_substitute",
        $content
    );
}

You can now use the class attribute to specify the first line number.

Changing the highlighting colors

WP-Syntax uses the default GeSHi colors for its syntax highlighting. I don’t particularly like them, let’s see if we can do better. Of course, if you don’t like my colors either, feel free to change them!

In wp-syntax.php, find:

1

add_action('wp_head', 'wp_syntax_head');

Add this line:

1

add_action('wp_syntax_init_geshi', 'my_custom_geshi_styles');

Now find:

1
2
3
4
5
6
7
8
9

function wp_syntax_head()
{
  $css_url = get_bloginfo("wpurl") . "/wp-content/plugins/wp-syntax/wp-syntax.css";
  if (file_exists(TEMPLATEPATH . "/wp-syntax.css"))
  {
    $css_url = get_bloginfo("template_url") . "/wp-syntax.css";
  }
  echo "\n".'<link rel="stylesheet" href="' . $css_url . '" type="text/css" media="screen" />'."\n";
}

Add these lines:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

function my_custom_geshi_styles(&$geshi) {
   $geshi->set_keyword_group_style(1, 'color: #0000FF;', true);
   $geshi->set_keyword_group_style(2, 'color: #0000FF;', true);
   $geshi->set_keyword_group_style(3, 'color: #0000FF;', true);
   $geshi->set_keyword_group_style(4, 'color: #0000FF;', true);
 
   $geshi->set_symbols_style('color: #000000;', true);   
 
   $geshi->set_strings_style('color: #808080;', true);
   $geshi->set_numbers_style('color: #808080;', true);
   $geshi->set_regexps_style('color: #808080;', true);
   $geshi->set_escape_characters_style('color: #808080;', true);
 
   $geshi->set_comments_style(1, 'color: #008000;', true);
   $geshi->set_comments_style("MULTI", 'color: #008000;', true);
}

We have now used WP-Syntax’s custom filter to overwrite GeSHi’s default colors. You might want to take a look at the documentation if you are unsure what the various GeSHi’s functions do. You can also take a look at the code comments in the geshi.php file. It also helps to look at the specific language file, for example php.php. You can find it in the geshi subdirectory of the geshi subdirectory (not a typo) in the wp-syntax directory.

Downloads

For your convenience, here is the modified file. Please note that if you are using a different version of the plugin you will need to hack it yourself, do not replace it with this file!

WP-Syntax plugin

One tool us programmers cannot do without is an editor with proper syntax highlighting features. As I will be regularly pasting code snippets on this website, I needed a plugin to do the same thing online to aid in readability. I’d like it to support multiple programming languages, show line numbers and allow me to overrule the default highlighting colors.

The Wordpress Plugin Directory contains a number of code highlighting plugins. I’ve limited myself to the most recent ones, which are certain to work with WordPress 2.5:

• Highlight Source Pro by Christian Knoflach
• WP-Syntax by Ryan McGeary
• WP Chili by Andrea Ercolino

I have tried all three and will share my experiences with you.

Highlight Source Pro

This plugin is based on GeSHi (the Generic Syntax Highlighter). Code highlighting is done server-side, so JavaScript is not needed.

I’ve done a test run with this plugin, first with a XML snippet and later with a PHP snippet. I had hoped I could just slap a <pre> block in here and the plugin would pick up which programming language I was using, but unfortunately you will have to specify it yourself by setting the lang attribute. The class attribute can be abused to specify any number as your starting line number. There are no line numbers if you omit the attribute.

The result of my XML test was not satisfactory: it worked, but only the XML tag and the more common attributes like xmlns were highlighted. It should be able to do more with a well-structured XML document. The PHP test fared a lot better: although I didn’t care much for the default colors, my code was highlighted properly. The plugin is intelligent enough to add horizontal scroll bars when needed, which I much prefer over unspecificied line breaks.

WP-Syntax

Like Highlight Source Pro, WP-Syntax is also based on GeSHi. It should therefore work with the languages I use most of the time: CSS, HTML, JavaScript, PHP, SQL & XML.

I again did both tests and it probably comes as no surprise that the results were completely identical, as both plugins use the GeSHi engine. WP-Syntax also supports line numbering, although it uses its custom line attribute instead of HSP’s neater class solution. If you care about XHTML validation, that you should probably skip WP-Syntax or avoid line numbering. I prefer WP-Syntax’s default layout for code snippets over HSP’s.

An issue I ran into that affects both plugins is that WordPress will seriously mess up your code snippets if you dare to use the visual editor. We will have to find a solution for that.

WP Chili

WP Chili is based on Chili - the jQuery code highlighter. Unfortunately I can be very brief about this plugin: it does not work for me at all.

The same two tests once again: XML was not recognised. My PHP example fared slightly better but it did not yield a nice looking code snippet, it looked rather like a <p> tag with color formatting. It did not add horizontal scroll bars when needed. I couldn’t get it to work consistently: a few times it worked, most of the time it did not.

Conclusion

The choice is between Highlight Source Pro and WP-Syntax. There is little difference between the two. Neither does exactly what I want. It should be noted that WordPress plays havoc with code snippets if you use the visual editor. It is dissapointing that neither plugin offers a solution for this problem.

Out of the two I picked WP-Syntax. I will have to make some modifications anyway and WP-Syntax’s default layout is more to my liking. To be continued!