Plugging it all together

In my last three posts I've been detailing some of the solutions I've used to have WordPress support a GitHub flavour of Markdown. Specifically this has been to have code examples syntax highlighted. My setup involves:

• The Typewriter plugin for general support of Markdown in WordPress
• Parsedown as an alternative Markdown rendering engine that supports the GitHub syntax
• The WP-Syntax plugin for syntax highlighting using GeSHi on the server.

At the risk of opening up the site to some sort of hack, as a security hole that I haven't thought of gets exploited, I thought I'd share the code for the plugin I've written to bring these components together.

This also means I can share the code I was referring to in my post on extending Parsedown to change it's output to fit with WP-Syntax's requirements. Finally you may understand what I was blithering on about!

There are two additional bits of code in this plugin that we haven't seen before. The first is specific to WP-Syntax and so to an extent has no place here. But I've decided that if I'm going to support this plugin, I'll need code for each of the major syntax highlighting plugins in it if they have s similar setup.

The issue is with the priority that WP-Syntax registers it's filters on the content. It registers with a priority of zero, so it's the absolute first thing to run. Reading the comments the reason for this it to avoid conflicts with some other plugins, but we need to make sure that our process to convert the Markdown to HTML runs before WP-Syntax. I therefore check for the existence of the WP_Syntax class (hopefully proving the site owner has installed and activated the plugin) remove the filters it has registered and then register them with a priority of one. Our content filters are then registered at priority zero, guaranteeing they run before WP-Syntax. It may be wise to change this priorities to two and one respectively in the future so any plugin authors wanting to extend things further don't need to perform the same mucking about.

The other piece of code adapts our GeSHi supporting extension of Parsedown to include an escaped="true" attribute during the render of pre tags. I discovered this was necessary because WordPress automatically escapes HTML entities to ensure it's tricky for attackers to embed <script> tags and other nasties in to post content. WP-Syntax asks for this attribute to know not to escape our already escaped attributes. This is also specific to WP-Syntax and when/if I generalise this plugin, I'll have to make it detect the plugin in use, or at least for the user to select some options.

For now it's designed for my use, and can hopefully be useful to other people, so I thought it would be best to share it as is. Some things I'd like to do to extend it:

1. Support for any requirements of other syntax highlighting plugins. At least the ones stated in my post about it.
2. Related to the requirements would be to work out extensions to the Markdown that would allow the setting of other attributes on the code blocks. This would mean they could support some of the advanced features these plugins have, like line highlighting.
3. I'd like to add a preview window below, or as a tab of, the main editor. I'm not using WordPress as my main editor environment, but I know a lot of other people are and it's good to encourage its use.

Any other suggestions are welcome. You can find the code for the plugin on GitHub, or just download this zip. Setup involves installing the Typewriter plugin, and optionally the WP-Syntax plugin. Then extract the zip to the plugins directory of your WordPress installation, and activate it in the usual way.

I hope you like it and it saves you some time. If you are using it then let me know. I'm interested in hearing if there's someone else that has decided this is a good workflow for them too!