Regular readers of this blog will notice how we've spruced the place up a little recently. A little Photoshop here, a little CSS there, a nod to contemporary design mores, it all works wonders. We should have a party to celebrate. We really should. As you may know, this blog uses WordPress, so the redesign delivery consisted of a WordPress theme. And since Innova is very much an eat-your-own-dog-food kind of place, we wanted the new theme to use our open source offering, phpSprockets.

And there begins a cautionary tale.

From a programmer's perspective, WordPress themes are ugly. Context-switching < ?php tags are literally peppered over the code. Well, perhaps not literally, but it is quite jarring, looking rather like XML-encoded COBOL. Dynamic HTML output is old-school concatenated strings interspersed with application function calls. The combination is almost, but not quite, entirely unreadable. Naturally, being tough, manly coders with women and children to impress, we wanted to reinvent this mess into a nice, sprocketized, object-oriented project. We were all hopped up, Eclipse at the ready, requireonce at our fingertips. Then it happened.

We realized Wordpress code isn't just ugly. It's toxic. For example, here's a tiny snippet:

<a xhref="<?php trackbackurl() ?>"</a>

The function isn't returning a url, it's echoing one to the output buffer. This is fine, provided that you never want to actually do anything with the confounded url. If we were to sprocketize, we'd have to trap the output buffer and then read from it, which is all sorts of crazy.

We'd also have to work out which calls echo and which return values, because the application sometimes returns a value. We could edit the WordPress code, but then we'd be forking the application, not to mention breaking all the other themes that people have created. Even if we modified the calls to return a value as well as echo it, to preserve compatibility, we'd have to suppress the output buffer before the Sprockets rendered.

The only sensible alternative would be to write an alternative WordPress API plugin, and if we were doing that, we might as well have functions return readymade Sprockets. Somehow a two-day redesign has blossomed into an open-ended commitment to developing a project that would be beautiful, elegant, and entirely unappreciated.

In the light of this, we made the pragmatic decision to write static HTML and forgo Sprockets for the time being. It's dissatisfying not least because Sprockets works so well with other open-source applications, even those written to be able to run on PHP4, such as MediaWiki. But then, as Yogi Berra once said, if you don't set goals, you can't regret not reaching them.