My recent talk about what might happen if gamers ran the world made Digg yesterday, and went a bit big. Big to the point that I got a nice email from my host pointing out that my PHP processes were killing the entire shared host that I’m hosted on, and that I needed to rectify this immediately.

The fires were mainly calmed by installing WP-Super-Cache, which did pretty much what it says on the tin. That said, I did learn a few things from the incident. In no particular order:

  • WordPress’ PHP processes for rendering a page are really, really intensive. Most of the time, that’s not a problem, but when you’re being bombarded with hits, it’ll take it’s told. Flat HTML might be the way forward.
  • Super-Cache isn’t exactly difficult to install, but it requires permissions in lots of places. The best advice I can give is to walk through the installation instructions carefully, and when it doesn’t work, go over the troubleshooting guide in readme.txt one step at a time. The few issues I had were resolved by walking through the troubleshooting process.
  • Most importantly, a combination of the two parts above: you should assume that at some point, you’re going to need this kind of caching, and you’re going to need it fast. Installing and configuring WordPress plugins on a server being bombarded with hits really isn’t much fun. Instead, install the caching plugin of your choice when you set your server up, and make sure it’s working at that time. Then, when the horde descends upon your lowly shared host, you can head straight there and click “enable caching”, rather than having to fight fires for an hour when you really should be working, or in the pub. This also means you can configure the thing to not cache your feed, which is a useful thing to be able to do; I’m about to head off and do that now.

Everything appears to have cooled off now, and I’m not getting any more emails from Joyent about my usage. To Joyent’s credit, they were helpful at explaining the problem and tolerant of the time it took for me to fix things, which was appreciated. And next time I get an absurd amount of traffic, with any luck, I’ll be ready for it.

So, this blog (for its sins) is running on WordPress 2.0.5. That’s a bit out-of-date. The main reason is because it has all sorts of jiggery-pokery to make it work the way I want – a tagging solution based on Jerome’s Keywords that was modified when I moved to 2.0; all sorts of template hacking to make the beautiful breadcrumb trail at the top you see work.

I’ve resisted upgrading due to the hell that was hacking plugins and templates into future versions of WordPress. Until now, that is. WordPress 2.3 (finally) introduces a proper tagging solution – entirely separate to the “categories” system. Well, not quite, as we’ll see – but it finally means that the architecture of is now entirely possible within WordPress itself.

Of course, now you’ve got to convert your custom tagging solution to the new schema. I’ve written a small script to do this for myself – only took about an hour, and that’s mainly because I was exploring the schema, and my PHP is a little rusty. Of course, now I know a reasonable amount about how tagging is implemented in WordPress 2.3, and felt I should write this up properly, so that anybody else converting custom tagging solutions might save themselves some time.

Continue reading this post…

Mac OSX 10.4 still only ships with PHP4, which is fine and all, but I eventually bit the bullet and decided to install PHP5.

The most immediately obvious way to do this is with Marc Liyanage’s excellent installer. I unzipped, installed the .pkg, and rebooted Apache.

Except Apache didn’t want to reboot. Apache refused to start, actually. Looked like a potential crisis!

Fortunately, a few minutes of digging found the solution. Pretty obvious, really:

you can’t load both mod_php4 and mod_php5 Apache modules at the same time.

I had mod_php4 enabled already. By commenting out the lines referring to it, Apache started up just fine, running PHP 5. Crisis averted.

As you probably know, when it comes to code (both in and out of work) I’m a Ruby and Rails guy. It’s not necessary to go into much detail “why”: the expressiveness of Ruby and the dynamism and speed of development in Rails are big wins for me.

But it’s not always possible – or practical – to knock out Rails applications for every task, and right now, I need to deploy something in PHP. Something very simple, that doesn’t warrant the deployment overheads of Rails (which we’re all aware of, right?)

Refusing to get caught up in WordPress if at all possible (not going into that again, either), I set out to look for a nice, well-documented, lightweight PHP web framework.

Oh dear.

Continue reading this post…