Although it’s easy to use WP Chili out of the box, WordPress does have some limitations, like the following:

• you need to change to the Code editor before adding a snippet to your post
• you need to make your snippet postable yourself, escaping all HTML entities
• even if snippets are very short, they are intermingled with their explanations and it’s tricky to concentrate on writing the best post with so many distractions in between

Using WP Chili & Enzymes

Now I’ll show you a better approach by using together WP Chili 1.0 and Enzymes 2.2.
All you need to be up and running is the classical roundtrip: download, unzip, upload, and activate.

How to highlight code snippets

You can start by writing a simple enzyme for automating things, like the following hilite custom field:

return 
'<pre><code class="' . $this->substrate . '">'
. htmlspecialchars( $this->pathway ) 
. '</code></pre>';

hilite can be used with the following patterns:

1. {[ =snippet= | .hilite( =language= ) ]}
2. {[ .snippet | .hilite( =language= ) ]}

The first pattern comes in handy when you want to highlight some very short and naive snippet
{[ =echo htmlentities( $name );= | .hilite( =php= ) ]} renders

echo htmlentities( $name );

So far, so good, but if the snippet has a character that WP texturizes, then hilite seems to fail. In fact
{[ =$welcome \= "Hello ".$name;= | .hilite( =php= ) ]} renders

$welcome = "Hello ".$name;

The above issue is not a hilite‘s bug but it could be fixed by adding new code to it, or with new enzymes along the pathway, like the following requote custom field:

$from = array( '‘', '’', '“', '”' );
$to = array( "'", "'", '"', '"' );
return str_replace( $from, $to, $this->pathway );

which makes that
{[ =$welcome \= "Hello ".$name;= | .requote() | .hilite( =php= ) ]} renders

$welcome = "Hello ".$name;

The best option is to add another custom field for hosting your snippet and use the second pattern: in fact hilite‘s snippet has been rendered by {[ .hilite | .hilite( =php= ) ]} and requote‘s one by {[ .requote | .hilite( =php= ) ]}.

How to highlight code files

Sometimes you have a file that you want to show in its entirety, and having to copy it into a custom field is annoying or maybe not an option, if the file is alive, for example.

In such cases you can use an enzyme like the following file custom field:

return file_get_contents( $this->substrate );

It’s use is again very simple and very similar to the above patterns:
{[ .file( =blog/wp-content/plugins/hello.php= ) | .hilite( =php= ) ]} renders

• Added the new feature for transcluding a value, rather than a post/key reference to it (which is still available). This comes in handy when you have a “normal” value and it’s a bit annoying to define a custom field just for that.

For example, let’s say that you have a template called mark-template.php with the following code:

<span style="background-color:<?php echo $this->enzyme; ?>;">
	<?php 
		echo $this->pathway; 
		$this->pathway = ''; 
	?>
</span>

Then you could use it {[ =like this= | =cyan= \mark-template.php ]} to get something like this

Download

This version is available for download from wordpress.org

• Added the new feature for passing a value as an argument to an evaluation enzyme, rather than a post/key reference to it (which is still available). This comes in handy when you have a “normal” value and it’s a bit annoying to define a custom field just for that.

For example, let’s say that you have a custom field with the key mark and the following value:

return 
	'<span style="background-color:yellow;">' 
		. $this->substrate 
	. '</span>';

Then you could use it {[ .mark( =like this= ) ]} to get something like this

Download

This version is available for download from wordpress.org

I’m releasing now Enzymes 2.0 which is quite a step forward. The features are

• a new syntax for retrieving properties of posts, pages, and authors; as well as the old syntax for custom fields
• a new syntax for identifying posts and pages by means of their slugs; as well as the old syntax with their numbers
• a new elaborate method allowing for an easier processing of indirect arguments
• a new merging method helping at crafting how the pathway is built by evaluation enzymes
• slash and backslash templating uniformly supported by transclusion and evaluation enzymes
• a cleaner code
• a new manual
• new examples

A WordPress Plugin

This version is available for download from wordpress.org

The previous version

I released Enzymes 1.2 one year ago from mondotondo.com, and re-released it as version 1.3 one month ago from wordpress.org. Both were almost the same thing. Here are the only differences:

• updated the description header, accounting for the new address (notelog.com)
• removed the signals to my server for activation / deactivation of the plugin
• packaged as a wordpress plugin, available for download from wordpress.org

The fact that it got 60 votes but only 50% stars means two things:

1. voting people are lazy thinkers
2. it’s a difficult task at many levels

Nonetheless it’s a good idea because this is and will be for many years to come the blogging era, where millions of authors post content to the Internet. There is no good reason for that content to be unstructured except lazyness and complexity.

Nothing can be done about lazyness but complexity can be substantially reduced. The solution needs:

• a mechanism for adding XML tags from some dictionary
• a template system for showing XML content appropiately

On the path to something readily usable (I hope Matt will provide it in WordPress 3.0), a mechanism could be a jQuery plugin for the visual editor, and a template system could be based on Enzymes.

Autocompletion

I think that tinyMCE can be extended by plugins, but I don’t know how to. jQuery itself has an autocompletion plugin that could be used this way. When an author presses a < key, the autocompletion gets triggered and the popup … pops up :-)

If you have ever used IME (for Japanese for example), you should know what I mean. Options are organized in a hierarchy and you get the most relevant at the top, depending on the few characters already typed. XML dictionaries could be ajaxed and locally cached; they could be plugins that you install into your blog, or be web services too; they could be international standards compliant or be completely custom.

The most-relevant-first feature of the autocompletion popup would be a big help for authors. If I already opened a Tag, then the most relevant options after pressing < could be:

1. the closing tag for that Tag
2. any tag that could be inside that Tag (properly sorted if needed)
3. any root of the cached dictionaries (if possible in Tag)
4. an option for accessing additional dictionaries (if possible in Tag)

Templates

A PHP template for properly rendering XML content is very easy to write, and Enzymes could be used in the clockwork. In fact an Enzymes feature is the possibility of easily transcluding all the content of a post or a page by means of the special char *

The XML to HTML template can be transformed in an Enzymes template with a couple of PHP instructions, thus allowing you to almost copy and paste already available templates. Then you could apply a solution like this:

1. write a private post or page with the XML content, using the autocompletion feature described above (say this post is #123)
2. write a public post or page with the Enzymes statement {[123.* /template.php]} in its content

The post in 1. needs to be private because you don’t want it to appear on the blog as is, and 2. makes the transformation happen. As an added benefit, you can display that semantic content inside of a greater context, and you can transclude it wherever you want in your WordPress blog (as many times as you like).

Meanwhile, if you are using a Chili + Enzymes setup, then it’s possible to write an Enzymes template capable of making Chili 1.x highlight a web page perfectly (expanding on my previous php template).

Here is the new updated (2007/02/19) chili-web.php Enzymes template. At the moment it supports XHTML, and embedded CSS, JavaScript, and PHP snippets.

'.htmlentities( $code ).''; } function snippet_php( $open, $code, $close ) { return snippet_wrap( 'html', $open ).snippet_wrap( 'php', $code ).snippet_wrap( 'html', $close ); } function php_inside_html( $matches ) { list( $all, $before, $open, $code, $close ) = $matches; if( '' == $open ) return snippet_wrap( 'html', $all ); else return snippet_wrap( 'html', $before ).snippet_php( $open, $code, $close ); } function php_inside_css( $matches ) { list( $all, $before, $open, $code, $close ) = $matches; if( '' == $open ) return snippet_wrap( 'css', $all ); else return snippet_wrap( 'css', $before ).snippet_php( $open, $code, $close ); } function php_inside_javascript( $matches ) { list( $all, $before, $open, $code, $close ) = $matches; if( '' == $open ) return snippet_wrap( 'javascript', $all ); else return snippet_wrap( 'javascript', $before ).snippet_php( $open, $code, $close ); } function php_inside( $class, $code ) { return preg_replace_callback( '/(?:(.*?)(\<\?php\s)(.*?)(\?\>))|(?:.+)/si', "php_inside_$class", $code ); } function snippet_web( $class, $open, $code, $close ) { return snippet_wrap( 'html', $open ).php_inside( $class, $code ).snippet_wrap( 'html', $close ); } function format_code( $matches ) { list( $all, $before, $open, $tag, $code, $close ) = $matches; if( '' == $open ) { return php_inside( 'html', $all ); } else { switch( $tag ) { case 'script': $class = 'javascript'; break; case 'style' : $class = 'css'; break; default : $class = 'html'; } return php_inside( 'html', $before ).snippet_web( $class, $open, $code, $close ); } } function format_clean( $out ) { do { $len = strlen( $out ); $out = preg_replace( '/(\[^<]*)\<\/code\>\/is', '$1', $out ); } while( $len != strlen( $out ) ); return $out; } } ?>

)(.*?)(\<\/\3\>))|(?:.+)/is', 'format_code', $this->result );
	echo format_clean( $out );
?>