• "So much city thinking seems mad keen for a return to city states; autonomous islands, connected to each other through finance and fibre but not to land that surrounds them. It's a little bit collapsist; let's wrap the city around us while we still can. But maybe we could think about network technologies as a way to reintegrate rural and urban rather than accelerate the dominance of one over the other. Perhaps all this brilliant city thinking could lift its eyes a little and look beyond the city walls – I'd love to see what we'd come up with then."
  • "Stacey is an easier way to create a portfolio site. No database setup or installation files, simply drop the application on a server and it runs. Your content is managed by creating folders and editing text files. No login screens, no ‘cms’." Elegant – perhaps even more so than some of the stripped-down Ruby static-site management tools I've seen.
    (tags: php cms simple )
25
June
2009

An ExceptionNotifier for CodeIgniter

CodeIgniter really is turning out to be The Little PHP Framework That Could. I’ve now dived pretty deep into it and still have few complaints; as I’ve said before, it makes all the boring stuff easy, has almost no “magic”, and stays out of the way.

As the application moves towards production, though, I began to miss a few things from Rails – notably, its ExceptionNotifier plugin. ExceptionNotifier will send you an email every time there’s an error on the site, which is really very useful with production applications.

So I investigated alternatives for CodeIgniter. I stumbled across this Stack Overflow post, which basically outlines exactly what I was looking for.

Except it doesn’t work.

Never mind! We can fix that, and the end result is MY_Exceptions.php:

(You might want to “view raw” on that – there’s some funky syntax-highlighting going on).

This really does work out-of-the-box with CodeIgniter 1.7.x. You just drop it into system/application/library, call it MY_Exceptions.php, and it’ll extend the existing Exceptions library. Obviously, you’re going to need to change a lot of the obvious details like email addresses you want things sent to, and the name of the production domain you’ve configured in your app’s config.php. You also need to make sure the error log level is set to “1″ or higher in that config.php file. But that’s about it; it really does work, and means that in production alone, you’ll get email from your app when a PHP error gets thrown, along with not only the line number and file the error was thrown in, but the URL that the user was accessing to generate the problem.

Not bad for an hour’s work. And, because it’s a Gist, you can either copy and paste, or just clone it straight into your application.

26
November
2008

Your guide to surviving the Digg avalanche with Wordpress

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.

Links & notes for this month

Endnotes