I wrote recently about how to have your site(s) email you whenever a problem occurs. Trouble is "problem" turns out to be a rather broad scope. If you have a missing file or fundamental problem of some kind, you would want to know so you can fix it; if there was a dead link on your site, you would also want to fix it; if someone just mistypes the url (or follows a link from an outdated source) you may not want an email each time this happens. At some point in between reading the comment from (the esteemed) Dr Tarique Sani and deleting the 4000+ emails I received from my site in the meantime, I came to realize that there has to be a better way to record what errors are occurring on a site. So that's what I'll be talking about today ;).

Limiting Scope

When I reviewed the emails that my site has sent me in the past week, there were many duplicates. The cause for most of the generated errors were either links to old pages which don't exist anymore or have been moved, or broken links on the site. When I switched host I also changed from (case insensitive) php4 to (case sensitive) php5, this caused many links to stop working. I was glad to know of how and why these errors were occurring, but once would have been enough ;). Of the types of errors that can occur, there is one case in which I want an email every time it happens - if there is a missing connection (which should be rare to never). So changes have been made to check for and only email in this circumstance, for the rest of the time...

Following on from my previous post, I thought I'd mention a similar use that can make a developers life a little easier. Usually when developing software there are at least 3 environments: Development, Test and Production. For larger projects there may be more, but for a simple website (and a tiny team of 1) there is often 2 environments: the one on the development machine and the live site.

So picture the scene, you just finished adding some enhancements to your website, all goes remarkably well on your local machine, and after running through your last few tests you decide you are ready for the move to your production server. So, you export the database, initiate the file transfer and then go to your live site and.... disaster: You have a completely blank screen that you desperately want to get rid of. What do you do? The error doesn't occur on your local machine so you have to debug in the production environment - better do it quick before a user notices and phones the helpline... But there is a better way.

If you have your website on one server for testing/development (like this laptop) and your live site on another, it's quite likely that once in a while your database.php file from one or the other will find itself referring to the wrong database. Over at With Cake a solution was proposed to allow you to switch database sources in the app model, however it might be easier to manage by switching at the source of the 'problem'.

With a modification to your database.php file like so: