WordPress Maintainability

For a while I’ve been maintaining my own WordPress packages. I use quite a few plugins that weren’t included in Debian, some of them have unclear licenses so they can’t go in Debian while the rest would have to go in Volatile at best because they update regularly and often have little or no information in the changelog to describe the reason for the update – so we have to assume there is a potential security issue and update it reasonably quickly. As I’m maintaining plugin packages it seems most reasonable to keep maintaining my own packages of WordPress itself which I started doing some time ago then the version in Debian became outdated.

Now WordPress isn’t a convenient package to maintain, the design of it is that a user will upload it to their web space via FTP or whatever, it’s not designed to be managed by a packaging system with the option of rolling back upgrades that don’t work, tracking dependencies, etc. One example of this is the fact that it comes with a couple of plugins included in the package, of which Akismet is widely used. The Akismet package is periodically updated asynchronously from the updates to the WordPress package with the apparent expectation that you can just FTP the files. Of course I have to build a new WordPress package whenever Akismet is changed.

Now there is a new default theme for WordPress called TwentyTen [1]. This theme ships with WordPress and again has updates asynchronously. Just over a week ago my blog prompting me for an update to the theme even though I hadn’t consciously installed it – I have to update because I don’t know whether one of the other users on the same system has chosen it and because having a message about an update being required is annoying.

The Themes update page has no option for visiting the web site for the theme and only offered to send it to my server via FTP or SFTP, of course I’m not going to give WordPress access to change it’s own PHP files (and thus allow a trojan to be installed). So I had to do some Google searching to find the download page for TewntyTen – which happens to not be in the first few results from a Google search (even though those pages look like they should have a link to it and thus waste the time of anyone who just wants to download it).

After downloading the theme I had to build a new WordPress package containing it – I could have split it out into a separate package and have the WordPress package depend on it, but I’ve got enough little WordPress packages already. It doesn’t seem worth-while to put too much effort into my private repository of WordPress packages that possibly aren’t used by anyone other than me.

Plugins aren’t as bad, the list of plugins gives you a link to the main web page for each plugin which allows you to download it.

I wonder what portion of the WordPress user-base install via FTP to a server that they don’t understand and what portion of them use servers that are maintained properly with a packaging system, my guess is that with the possible exception of WordPress.com most bloggers are running on packaged code. It seems to me that optimising for Debian and CentOS is the smart thing to do for anyone who is developing a web service nowadays. That includes files managed by the packaging system, an option to downgrade (as well as upgrade) the database format (which changes with almost every release), and an option for upgrading the database from the command-line (so it can be done once for dozens or hundreds of users).

deb http://www.coker.com.au lenny wordpress

I have a repository of WordPress packages that anyone can use with the above APT sources.list line. There is no reason why they shouldn’t work with Testing or Unstable (the packaging process mostly involves copying PHP files to the correct locations) but I only test them on Lenny.

3

Pre-Meeting Lightning Talks

This evening I arrived at the LUV [1] meeting half an hour before it started. I was one of about a dozen people sitting in the room waiting, some of us had laptops and were reading email but others just sat quietly – the venue is sometimes open as much as an hour before the event starts and in bad weather some people arrive early because it’s more comfortable than anywhere else that they might hang out.

So I went to the front and suggested that instead of just doing nothing we get some short talks about random Linux things to fill the time. This seems to be a good opportunity for people to practice their public speaking skills, share things that interest them with a small and friendly audience, and keep everyone else entertained.

With some prompting a few members of the audience got up and spoke about Linux things that they were doing or had recently read about. They were all interesting and I learned a few things. I considered giving a talk myself (my plan B was to just speak for 15 minutes about random Linux stuff I’m doing) but decided that it would be best if I just encouraged other people to give talks.

I have suggested to the committee that we plan to do this in future and maybe have a mention of it on the web site to encourage people who are interested in such things (either speaking or listening) to attend early enough.

I think that this concept has been demonstrated to work and should also work well in most other user group meetings of a suitable size. At LUV we typically have about 60 people attend the main meeting and maybe a dozen arrive really early so people who would be nervous about speaking to an audience of 60 may feel more comfortable. For a significantly larger group (where you have maybe 300 people attend the main meeting and 60 arrive early) the dynamic would be quite different, instead of having more nervous people give talks you might find that a membership of 300 gives a significant number of people who have enough confidence to give an impromptu short lecture to an audience of 60.

As an aside the Connected Community Hackerspace [2] is having a meeting tonight to decide what to do about an office in a central Melbourne area. One of the many things that a Hackerspace can be used for is a meeting venue for lightning talks etc.