Don't mail me my site errors

19 April, 2007

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...

Save errors to the database

As far as I'm concerned, there are 2 parts to the data of an error - the generic details i.e. the class/url/controller/action that is affected, and the specific (and potentially private) details of the circumstances in which the error occurred. For example, if a helper file is missing, I want to know about it, but if that helper file is only included under certain circumstances it would be wise to be aware of how the error occurred such that it is possible to reproduce, prevent and add a test case. Below is the new and improved error class:

It is a little more complicated than the previous version, and I won't include the necessary table definitions in this blog post (although they can be easily deduced). I will however make a version of the administrative plugin available as an online demo/download. To explain in brief the extra logic, the class now does the following:

• If there is a problem connecting to the database, email me
• Otherwise, so long as the error doesn't relate to the bug tracking tables themselves:
  1. Get the session data
  2. Get any form data
  3. Get the sent headers
  4. Load the models for the plugin "mi_bugs"
  5. Find or create the (unique) bug for the error or url in combination with the plugin/controller/action which caused it.
  6. Create a detail report linked to the bug with the session, form and header data

In the past few hours, there have been approximately 50 incidents logged, and 10 unique 'bugs', it is now a relatively simple (and actually interesting at times) task to browse what has been logged and prioritize which, if any, require action. It can be extended also; I've hooked my anti-Spam system into it such that form submissions which are identified as spam are recorded for later analysis.

Wrapping Up

The code presented here allows you to know, in a useful and manageable way, what errors are generated by your site(s). A demo/download will be available shortly for (amongst other functionality) browsing/administering the info this class will collect.

Bake on!