Posts Tagged ‘code editor’

Hacking the WP-Syntax plugin

Sunday, May 18th, 2008

Table of contents for Syntax Highlighting

  1. Syntax highlighting plugins
  2. Hacking the WP-Syntax plugin

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