Colin Charles Agenda

WordPress: Plugin architecture makes it great, but a long way to go for release engineering

I especially enjoyed reading Steve Yegge’s blog rant, titled The Pinocchio Problem. If you haven’t read it, you should, as he believes that world class software systems have two things in common: an extension language and a plug-in system.

Updating WordPress a couple of days ago (this is now becoming a regular chore, spanning over 14 steps, not all of which can be automated (deactivating plugins, reactivating them in the correct fashion to not watch them bomb), I was thinking about the WordPress plugin architecture. Its very nifty, allowing one to make WordPress just rock totally harder. Some that I can’t live without are:

The plugin system probably makes WordPress one of the best pieces of blogging software out there. In fact, WordPress has made Matt, the most popular Matt in Google! The sheer energy of all the folk using and developing on WordPress is amazing, as I witnessed at the inagural WordCamp 2006.

It amazes me, that companies regularly, commercially offer WordPress hosting. They come up with these “1-click installs” and upgrades, that I’m wondering what I’m doing wrong with upgrading WordPress regularly. Sure, most of the 14 steps I stated earlier, include silly things like cd’ing to the correct directory, moving it and so on – all of which are script-able. But the plugin deactivation, and correct activation (like, you don’t want to start the Flickr Widget without the Sidebar Widgets, which would seem the alphabetical thing to do, but clearly make the plugin system whinge), as well as running the upgrade itself, happens via a Web browser. Manual intervention to me, sucks.

Now, on to release engineering. We users get a lot of WordPress releases. A PHP blogging system, looks like it can be a lot of work, if you’re going to manage multiple blogs. Or websites – I’m starting to see a lot of websites that are just blog based, with pages that link to “permanent” content. Companies are doing this, regularly now. I’m of the camp, that its a big mistake, as good ‘ole HTML is probably better for a website (fine if you need sidebars, a standard top toolbar, etc… – use Apache SSI, or a little amount of PHP templating). The announcement list, is one that everyone running WordPress should be on (ditto, with MediaWiki, but I’ll save that rant for another day – though most of what I mention about the plugin architecture, also plagues MediaWiki).

A good plugin system, will have a mechanism to provide updates. Firefox has this – at the very least, when you upgrade Firefox, it looks for newer plugins. When you upgrade WordPress, you could still be running age old plugins. And when you manually check to see if these plugin versions match, sometimes the websites themselves aren’t too direct without you using your mouse and hovering over a link.

I find some plugins critical – Akismet, so my comment spam level stays down, to a manageable state. I’ve been bitten by an update before, that I didn’t know about. Easy fix? The moment you feel you’re getting too much spam, visit the website to look for an update. Too manual for me. Just recently, the AdSense Manager – over a span of a couple of weeks, there have been two releases. One of which, is significant enough to warrant an update – the Google AdSense ID was not being passed to Google. Suddenly my traffic stats at Google, for the blog, seemed to drop to zero.

What’s missing with WordPress, is a plugin updater. With release engineering such that one can run a SVN checkout version of the Sidebar Widgets, and have to visit a website to get the latest code from HEAD for the Flickr Widget, it would rock, if an updater regularly spidered the SVN repository and informed you if there was a new release, or something sitting in HEAD (okay, trunk, whatever).

Technorati Tags: , , , , , , , , , , , , , ,