We used the CakePHP MVC framework to develop the Tilaa webapp. We encountered some limitations, road bumps and nasty bugs along the way, but mostly it was a smooth ride. In this post I want to outline some things we learned along the way and which might be of interest to other CakePHP developers or newcomers.
Before we started developing the application we compared and did some testing with some of the most popular and mature ones. We flirted a bit with Ruby on Rails and the Django framework for Python, but most of our web development experience is with PHP, so for us using a PHP framework seemed like the best option.
Upon first glance the Zend framework seemed to match our requirements: It has lots of features, looked mature, offers great flexibility and has a vibrant community. But when we started working with it we quickly learned that that flexibility also adds a lot of complexity. Although we’ve got extensive experience with PHP it was tough to get started with it. It has a steep learning curve and it will take you lots of time to get up to speed. We wanted a framework to help us save time, to manage the boring bits and help us keep our code clean and organized. I’m sure you can (eventually) do that with Zend, but let’s just say it wasn’t the right framework for us.
When we started with CakePHP 1.2 we quickly got up to speed and haven’t looked back since. When we got stuck, the documentation or helpful community quickly got us back on track.
So what have we learned?
- Always use the Containable behavior on your models right from the start. If you have lots of models (like we do) it’s not even optional anymore. You need it to limit the amount of queries to your database and the memory usage of your app. And it could become a time consuming task to add the behavior later. (Oh, and don’t forget to set recursive to -1 in your model!)
- CakePHP’s ACL stuff is great for managing permissions inside your app, but be aware that if you use database ACL’s it will do lots of queries to look up ARO’s and ACO’s. Caching those is not sufficient. If you need performance, don’t use database ACL’s. If you have lots of visitors and static permissions, use ini-based ACL’s or a different permission system instead!
- CakePHP runs great under nginx with fastcgi. Don’t use Apache if you don’t have to, it’s performance really sucks :)
- CakePHP’s schema migrations have some nasty limitations. It doesn’t manage unsigned integers, it doesn’t properly keep track of collations, it is confused when you change indexes and if you use more than one database configuration it complains about missing tables. If you are aware of the limitations it’s still quite workable, but be prepared to fix some things manually once in a while. We wrote a cake shell to handle all the stuff CakePHP doesn’t manage properly, which is good enough for now. We hope CakePHP 1.3 will be better in this regard.
- Use the Security helper for all your forms! And be aware that the security helper doesn’t prevent people from modifying the contents of a select box or a set of radio buttons! You have to validate those inputs yourself after the form is submitted.
- If you need to redirect people to a different site and back (for an iDEAL payment for example), set CakePHP’s security level to low or else the session will be invalidated when the user is redirected back to your site. As far as we can tell, a low security level in CakePHP only means the session id will not be changed between requests and that you have a higher session lifetime.
- i18n and l10n support is quite limited. If this is important to you, go and try CakePHP 1.3.
This is all I can think of right now. There is obviously some room for improvement in CakePHP, but I’m sure the framework will mature over time. In our opinion, CakePHP is the closest thing to a Rails-like experience in the PHP world. Despite it’s bugs and limitations it’s still a time-saver.
We look forward to CakePHP 1.3 and 2.0!