A closer look on CakePHPAs you know I have rewritten this whole website to get away from WordPress. This had two main reasons:
First, I no longer have to worry about changing APIs or incompatibilities between plugins. So if I want to use this website for something more (I already have some sort of API to access some features of this site) everything is in my hand. If the server API changes I now what changed and why and I can adapt the client APIs as well.
And second I don't have to force WordPress into being something it wasn't designed for.
WordPress is GREAT when it comes to simply having a blogging system but imho falls short
when using it for things that go beyond.
Implementing an issue tracker like I did for the new site would be a pain in the ass if I had to do this for WordPress. Besides I don't have any experience writing plugins for WP so I guess this would have taken much time as well.
When I started on writing the site I had to decide whether to go for CakePHP or Zend. I had some minor experiences with both and finally decided to go for CakePHP. The main reason was that Zend is too much blown for my taste. Yes having the ability to fine tune every single detail might be a good thing for fully featured web applications but I figured CakePHP was good enough. And well it surely is!
So I decided to give you some insights about working with CakePHP. The number one thing to mention is the great documentation on their website. I did have a good time reading through it and almost all questions I had when developing this site could be answered by reading the documentation. For everything else there is StackOverflow (ok this does apply to Zend as well but I wanted to mention it).
Cake really does a good job at doing things on its own if you let it. Mapping database tables to PHP
classes is just a matter of a few lines if you go by the conventions.
This is also the one biggest lesson I learned: Using CakePHP it is always best to go with its conventions. When I started designing the site's database I named my primary key columns the way I always do: TableName_ID (for example the primary key for a user would be User_ID). Doing so would mean to tell every class in the Model that it shouldn't use the default PK (which is simply id) and instead use a different one. So I decided to go with ID as my primary key. And yes it does make a difference between id and ID. Only the lower case version is working. Took me forever to find out why my relations didn't work as expected.
Then of course there is the Form generation which is just great. You put a few lines of code in your view and you get your form for the model with validation and security options. Everything with just a few lines of code plus a few lines of configuration. Simply love it.
All in all I love how CakePHP makes it hard to go off the MVC-Pattern while never making it hard to follow it. I never had the feeling that I would be better off mixing the Model with Controller or the View with the Controller. Having worked with other MVC-Libraries this was a great plus for me since most of the libraries I previously used (with the possible exception of Zend) did a better job at standing in my way than acutally helping me.
For a start on CakePHP this should be enough. I'll try to give you more insights in the future. So stay tuned!