OddThinking

The poor blogger at Brainsnorkel is being forced to write BASIC code. Here at SomethinkOdd, I’m lucky enough to choose my own projects. What could be modern and zeitgeist than working on a plug-in for WordPress blogging software, written in the programming language du jour, PHP? Here, in 2005, we are past the horror that is maintaining code using line numbers!

Or are we?

WordPress Plugins Architecture

WordPress has been built to support customised plugins, written by volunteers all over the world – a group that I am aspiring to join very shortly. In fact, the WordPress code sometimes looks as it is nothing but plugins and support for future plugins. WordPress works on a pipe architecture – they call them “filters” – where each part of the code takes the output from the previous section, modifies it appropriately, and passes it on to the next filter, before it finally gets pushed out to the user’s browser.

The plugin I am developing, EmailShroud – consists of a filters carefully inserted into several of the pipelines of text being pushed around by WordPress. Another popular plugin, PHP Markdown, takes a similar approach, albeit on a much larger scale.

Plugin Cross-dependencies

Unsurprisingly, there is a dependency between some filters – they need to run before other filters. WordPress deals with this by allowing each filter to declare its own priority (on an integer scale). WordPress runs the filters in order of their priority (low number = highest priority).

Sound familiar?

Programming with these priorities is like programming with line numbers. In the same way that BASIC coders have to increase their line numbers in increments of 10, to leave space for intermediate lines later, WordPress developers separate their filter priorities by units of 5 or 10 to allow later developers to slot their filters between them.

Only, it’s worse! Due to the distributed nature of development, this can have unexpected effects.

Let me give a recent example.

I put my EmailShroud filter at priority 40 (because it needed to run after a priority-30 filter) and it worked fine.

However, today I upgraded the PHP Markdown plugin from 1.0.1a to 1.0.1b (‘a minor jump’, I thought).

EmailShroud broke!

It took an hour to find the problem. It turns out that PHP Markdown has changed the way it integrates with WordPress. Thankfully, it is well-documented by the author, Michel Fortin, so I was able to roughly understand it. PHP Markdown is now forced to move one of the standard WordPress filters, balance_tags, around to keep it out of its way, and it is pushed it out to priority 50, where it was chewing up the output of EmailShroud.

EmailShroud is now working again at priority 55. In theory, of course, that move could have broken another filter than expected to run after EmailShroud.

It’s like everyone around the world is trying to write parts of a BASIC program, and never being quite sure what line numbers to put in, because they can’t be sure of where the rest of the code will be.