A brief not to say that I'll be putting a couple of Demos back on the site, and I'll be adding to the main demo page as I go. All of the demos will be put up as plugins.

The pagination demo and source has always been available, and adding to that, the the next example is the Title tutorial. A very simple example based on the original tutorial from the wiki demonstrating the use of associations, requestAction, class/method inheritance and AJAX.

Next on the list is to tidy up and make useful the ajax-chat that I wrote a while back, with any luck that will pop up tomorrow.

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:

If, like on this site, you have some demo applications with some data in them, it's wise to try to ensure that the test data you spent an hour or two creating doesn't get deleted.

For the demos that were on this site (they'll be coming back after some tweaking) I set up a script to run once per hour to truncate and reimport the test data - thus ensuring that malicious data, should there be any, is removed and there is always some data to play with.

More than likely, most users who would visit a site with a demonstration aren´t going to click a link marked "delete" unless they want to check it works. There are a group of site users however who will click all of your delete links thus leaving subsequent visitors with no data to play with.

One of the changes I made to my site recently, was to override the App Error Function to keep track of how things are going wrong. I did this by simply logging all the information available and redirecting the user to a safe page (the home page).

I've found this to be very useful in general, especially for debugging what was going wrong with multiple inter-plugin requestAction calls on the same page (2 pastes on the same blog didn't work without some tweaking, I might say something about that soon).