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

Routes are a great feature, but if you try using them with Plugins you might find that you start pulling your hair out. Fear not however, there's always a solution and it's usually not that difficult. If you use routes of the form below, you can map directly to a plugin's page:

Easy when you know how.

One word of warning though, the first parameter in this route has a default which is the controller action. This means that if you create route which expect parameters (as I did in the example) it will work with no parameters, but if any parameters are passed the first one will be understood to be the method name.

Quite often the question is asked "How can I access XYZ in my controller/view/model etc?". IMO this question rarely needs to be asked ;).

Using the following simple approach should empower you to answer most questions:

1. Set DEBUG to 2 in your /app/config/core.php file so you can see the executed SQL whilst you are developing, you can set it to 3 to see a dump of the current controller at the foot of the page (might make your page loads a bit cumbersome - especially if you have ajax requests).
2. Use the Search facility, pay particular attention to the API.
3. Don't be afraid to look at the cake source code; you may be able to quickly see the answer to your question. DON'T make changes to the code (except perhaps temporary debug code) or you may find that upgrading becomes a 2hour task instead of a 2minute one.
4. If in doubt stick something like this in your code: [Code]
5. Don't forget that CakePHP is still PHP :); If you know some data has been set somewhere but you don't know where it is - use what PHP provides such as Get defined vars and search the output on your screen.

If you still don't know where something is after that - think if what you are trying to do is logical, and if you think that it is, it might be worth asking.

The singer Beyonce

If you use MPTT tables anywhere (The cake acl system uses it) you may have found that when you delete an entry, the lft and rght fields for the neighouring nodes don't get updated. This may have rather dire concequences ;)

There is an open ticket for how to delete from the cake acl tables, but as it is potentially quite generic, I thought I'd include the (potential) fix here. Below are two versions of a delete method, one takes care of associations, and the other doesn't:

Should anybody use this and find it causes a problem please let me know.

A long time ago, I took to using elements as shown in the paste below.

I hope the time I spent trying to figure this out is saved for others :)