WordPress 2.8.4 upgrade

Stuart — Tue, 08 Sep 2009 08:59:55 +0000

I spent most of Sunday and much of yesterday upgrading all of the WordPress installations that I’m responsible for, following the news that an internet worm is trawling the web looking for sites with security vulnerabilities. The scale of this particular attack is considerable, because the worm targets all versions prior to the current 2.8.4, which was only released on 11 August – less than a month ago. A friend had already had one of her sites hacked and I’ve since read about others I know who’ve been affected.

When I first heard about this issue, I was a bit slow to get to grips with its urgency and vaguely planned to do the upgrades “sometime” this week. The hacked friend urged me to take it much more seriously. Now I’m reading some of the horror stories of people trying to fix their hacked sites, I’m so glad she made the effort. At the risk of sounding like a latecoming evangelist, I’m going to repeat the warning. Don’t wait – do it now. Lorelle provides the best summary that I’ve read about this.

My newest client site, which is still at the pre-live stage, was already on version 2.8.4. All of the rest were at various version levels: 2.3.x, 2.5.x, 2.6.x and 2.7.x. Some of them hadn’t been upgraded because there had been no pressing need for clients to engage me to do so, some because they depended on plugins that weren’t compatible with 2.8 and some because of pure inertia. I was a little daunted by having to upgrade so many sites so quickly, but in the end everything went relatively smoothly.

The biggest technical issue that I encountered was that some of the files in one particular installation were owned by the web server, rather than by my account. This meant that I couldn’t delete them prior to the upgrade. I was rather puzzled by this, because other installations on the same server didn’t have the problem. The solution in the end was to run a custom Unix shell script via CGI. It was very quick and dirty, with no error checking. This is what it looked like:

#!/bin/sh /bin/rm -rf /usr/www/users/[account name]/path/to/some/files/* /bin/rm -rf /usr/www/users/[account name]/path/to/other/files/* echo "Content-type: text/html" echo "" echo "Deletion script" echo "

script has run

" echo "" exit

I put it into the cgi-bin directory for that particular website, changed its permissions to make it executable and then ran it. The first time, it failed. This was because all of the end-of-line characters had changed to ^M in the process of transferring the file from my PC to the Unix host. A quick spot of editing in vi, the Unix editor, soon sorted this out. After this, it ran perfectly and did exactly what it was supposed to. I made sure I deleted it when I was done with it, keeping a copy for future reference.

As far as WordPress plugins were concerned, I feared the worst and was pleasantly surprised. When I’d last scouted around towards the end of July to check plugin compatibility with 2.8, few of the ones that I use were formally supported. Since then, presumably due to the focus on the pre-2.8.4 security issues, every single one is now entirely compatible with the latest version. Nothing broke on any of my sites. Now they’re all done, I have that feeling of contentment that comes from a good spring-clean.

Update: a week later, everything’s still going strong. Only one issue emerged on one site after a couple of days. In upgrading to the latest version of the Twitter Tools plugin, I failed to spot that you now need a bit.ly account and API key if you want the plugin to auto-generate links to blog posts in the “tweets” that it creates. Easily remedied, it took less than five minutes to sort out.

Stuart Hardy » WordPress

WordPress 2.8.4 upgrade