Comparing Laravel, CodeIgniter, & CakePHP

Today I received a comment on my Laravel Auto-Generating Named Routes post that I felt deserved its own post.

Matthew Schenker wrote I see you’ve worked with CakePHP and CodeIgniter, and now you’re mentioning Laravel. I’ve been happily using CodeIgniter for a while now, but lately I see a lot of people mentioning (and loving) Laravel. I’m not looking for one of those “which is best” answers. Long ago, I learned that this is not a good way to look at various frameworks. But I’m curious — what are your general impressions when comparing these three frameworks?

CakePHP, CodeIgniter, and Laravel are all great frameworks in their own rights. They each have their pros and cons which I will cover here. Bear in mind that these are my opinions and forming your own by messing a bit with them is always the best policy. And as mentioned in Matthew’s comment, this is not an “OMG FRAMEWORK X IS TEH BESTEST!!!1!” post.

Cake, if I recall correctly, was one of the first PHP frameworks around back when spaghetti code was standard. The idea behind Cake was to make developing applications fast (ie, “convention over configuration”) by cutting down on how much code the developer needed to write. Less time working means more time making money.


  • Built-in ORM which I’ve always really enjoyed. I really like how the results are in $post[‘Post’][‘field’] format. Building queries is really simple and you can fetch (for example) a blog post and all of its comments in one or two lines of code.
  • Reverse routing. This makes maintaining links in an application so much easier. This means if you change a controller’s name at some point, instead of search/replacing 200 instances of “admin/foo” with the new “admin/bar” (and hoping you didn’t miss one) you simply update the route in one place. Any links using the reverse route array will automatically point to the right spot at runtime.
  • Big community. Because Cake had been around so long you can find the answer for pretty much any question you come up with. If you can’t? They have their own website where you can submit questions, as well as (I believe) a mailing list.
  • Plugins. This makes re-using code super simple and help keep the app folder clean (if, for example, you are distributing an app that uses modules).


  • Incredibly slow. Recent versions of Cake (2.2.x as of this post) are much faster and more efficient than previous versions, but  it is still one of the slowest frameworks. I am personally not sure how well it holds up when an app of it gets slammed with tons of hits. I am aware that Mozilla’s plugin site runs on an (old) version of Cake, as does Cake’s own bakery and Q&A sites, which all seem to run fine. I suspect it’s a balance between caching and server fine-tuning.
  • TONS of lines of code. Some developers don’t care what’s going on under the hood; I like to be able to quickly find out how/why something works the way it does. The code is well documented but there’s just so much of it it can be overwhelming.
  • Occasionally, you need to use code to reign in just how much it does. For example, my first step is to open my AppModel and set $recursive = -1 and adding Containable to Behaviors to prevent it from auto-grabbing related models and letting me tell it what I need.
  • Autoloading can be awkward. In recent versions of Cake they’ve introduced lazy loading in the form of  App::uses. Then, if you need to have access to (for example) the Model class, you do something like App::users(‘Model’, ‘Data/Model’) at the top of the file. This is, IMO, clumsy and no better than doing a require CORE_PATH.’Data/Model/Model.php’;

Conclusion: Personally, I use Cake if I need to put together a dynamic site quickly that I don’t foresee getting a lot of hits (like for a local restaurant, for example).

I’ve mentioned on here before that CI was the first framework I ever used and helped me finally understand the concept of OO programming. It’s certainly popular, and has been around a similar amount of time as Cake.


  • Super easy to set up and use. This makes the entry level for a newer PHP developer much lower.
  • Extremely well-documented, with examples in a lot of places to illustrate usage.
  • Extremely fast.
  • Huge community. As with Cake, since CI has been around so long you can almost always find your answer via Google, CI forums, or their IRC channel. This also means there’s lots of code contribution to help get things done (like Paypal libraries, etc)
  • Sparks, the “hub” where CI packages go to hang out and be used.


  • No modular separation by default. This is a big deal for me as I prefer keeping my code as separated as possible. There is Modular Extensions, which does the job, but I’ve never been 100% satisfied with it.
  • Since 2.x broke CI has been 5.1.6+ for its minimum PHP version, but the whole $this->library, procedural function helpers, and extending a class by prefixing MY_ in front of it way of doing things just doesn’t work well for me. Perhaps this will change in 3.0? *shrugs*
  • I personally have to extend way too many core files to get CI working the way I like it. The more you modify the core, the more you have to maintain later. I’d rather be coding something productive.

Conclusion: CodeIgniter is a fantastic framework for getting the hang of PHP and OO coding and for knocking a small site together fairly quickly with low overhead.

Laravel is still in its early days compared to the “grandpas” of the framework world (I believe it was first introduced in 2011), but it has already gathered quite a following.


  • Modularity is built in via “bundles”, making it really easy to drop in/reuse code across application
  • Eloquent ORM is a simple, super fast ORM that makes working with database relations easy
  • Very configurable and extendable. I can set up apps with the folder structure the way I like it and how it works best for me.
  • Blade template engine. Very fast (compiles to PHP then caches the results) and very extendable. So easy to add new features without hacking the core.
  • Artisan (CLI). Before I started using Laravel I had zero use for CLI tools like migrations and tasks. It’s so easy to create both of those things with Artisan that I can’t believe I waited so long to try it out!
  • Reverse routing!
  • Excellent documentation.


  • It’s still quite new which can mean some instability with the code. However, since 3.x’s release (and certainly since 3.2.x’s, the most current as of this post) this has slowed down quite a bit.
  • Laravel’s core files are all within (at least) the Laravel namespace and not all of the files in core use a namespace slash ( a \ ) in front of a call to another core file, which makes extending some classes a bit trickier. This is not a huge issue and one not every developer will need to worry about.
  • Routing can feel a little odd sometimes. In my dynamic controller routing post I showed the workaround I used to dynamically route to an add function in any controller. I have not dug deep enough into the semantics of Laravel’s routing methods to understand why such a workaround is necessary but it does add another layer of complexity, IMO.
  • Because of its newness the options for finding answers are still limited in comparison to CakePHP and CodeIgniter. However, the forums and IRC seem to be quite active with helpful people, so usually the answer is findable.

Conclusion: Laravel is currently my framework of choice. Its coding style meshes the best with my own which makes developing much quicker for me.

So there you have it! A personal comparison of 3 big players in the PHP framework world. As always, the best framework for you is the one that you code best in. The “Cons” foreach 😉 framework are my personal beefs with each of them and should be taken with a grain of salt. The best advice I can give is to try them each on for size and see which you like best.


(CakePHP) Get a Database Connection Instance

In my current project I am working on, I am using CakePHP and need to fetch some data from the database very early in the request cycle (don’t worry; it’s cached to avoid unnecessary queries).

In past versions of Cake you could use ConnectionManager::getInstance(). However, in 2.2 (and possibly in earlier versions of 2.x; I do not have the time to check), this no longer works.

The solution is to use the getDataSource method. So, by calling ConnectionManager::getDataSource('default') I can retrieve an instance of the default database connection and go along my day. Yay!

CakePHP 1.3, Smarty 3, and Theming. Woohoo!

There are various solutions out there for integrating Smarty with CakePHP. I’m here to introduce another one, that I feel is a little leaner than the other solutions I’ve found.

Jump to the code:


  • Cake 1.3.2 (No idea if it will work on < 1.3.2)
  • Smarty 3

Just place this in your /app/views folder andmake sure your AppController has the following lines:

public $view = "Theme";
public $layout = "default";
// The following line is optional; the default ext in the ThemeClass is set to .html.
// Uncomment to set to your desired extension
// public $ext = ".some_extension";

Your views would (unless you change the $ext variable) then be saved with .html extensions.

CakePHP, Using Edit For Add/Edit Functions, & Plugins (Oh My!)

When I work on a project I usually combine my add/edit functions into just edit. This saves some space in my controllers and makes maintenance a lot easier as I have only one function to edit instead of 2.

To accomplish this in Cake, you’d just do something like this:
Router::connect('/:prefix/:controller/add', array('action' => 'edit', "admin" => true));
This will map your controllers in your “app/controllers” folder nicely.

But let’s say you’re building an app that includes plugins. You may think “Ha hah! I’ll just slap this in my routes.php file”:
Router::connect('/:prefix/:plugin/:controller/add', array('action' => 'edit', "admin" => true));
And it will work..kinda.

More specifically, it will work for the subcontrollers of your plugin. For example, if you have a news plugin, and the news plugin has a comments controller, the above route will work, because it will map “/admin/news/comments/add” to /admin/news/comments/edit”.

HOWEVER!! This will NOT work for the news controller itself
Dramatic Chipmunk

*ahem* Luckily, the fix is easy and only took me 2 days to figure out (hey, I have kids; things get put aside…yeah, that’s my reason)
Router::connect('/:prefix/:plugin/add', array('action' => 'edit', 'admin' => true));
Now you can access “/admin/news/add” as you’d expect!

Quick Little Tip Regarding Cakephp forms

Occasionally when I am coding something in Cake that requires a form, I run into a problem if I use something like

if( !empty($this->data) ) ...

If there is another method that posts to the URL that the above code rests on (an Auth class trying to preserve the page the person was trying to reach, for example), then chances are good the method will think the user is trying to post to that method as well.

Anyway, my quick solution to ensure that only the data *I* want is posted is this:

if( !empty($this->data['ModelName']) ) { ..

This ensures that the method is only looking for the data that we want to post to it.

Custom Error Handling in CakePHP when debug = 0

Not sure if this is the most correct way to handle this, but I wanted to use a custom error method in my controllers. However, if you’ve been working with CakePHP a bit, you’ll notice that Cake automatically throws a 404 error when you set debug to 0.

To get around this I opened up /cake/libs/error.php and commented out the following lines:

/*if (Configure::read() == 0) {
$method = 'error404';
if (isset($code) && $code == 500) {
$method = 'error500';

This seems to solve the problem, for now. Hopefully this will be fixed in a future version of Cake because I detest modifying core files.

Quick 'n' Easy Way to Dynamically Set Per Page Limits with CakePHP's pagination

Maybe this is old news to some Cake veterans, but it took me longer than I would’ve liked to figure this out.

I have a settings table which holds a “per_page” variable and value, to allow admins to set their own per page limits for their site. However, because Cake defines $paginate variable like so:
public $paginate = array(..);
you cannot define a Configure::read or $variable to pass the “limit” key along. And pasting $this->paginate in 4 or 5 actions was not my idea of a good time.

After some head-scratching it dawned on me – define the other keys (fields, order, etc) in the $paginate variable and then simply define the “limit” key in the action itself!

Now here’s what my Controllers look like:
public $paginate = array(
'ModelName' => array(
'order' => ..,
'fields' => ..,
"conditions" => ..

Then in my action, I simply do a quick check to see if the per page limit has been set (don’t want to limit 0,0!!), and if so, set that as the limit variable:
if( $limit = Configure::read("per_page") AND !empty($limit) ) {
$this->paginate["ModelName"]["limit"] = $limit;

I couldn’t believe how easy it was 😀

Quick tip for the form helper in CakePHP when editing

While working on my latest crazy idea, I was testing the edit function of a particular section and realized something alarming:

If I had an error while editing, the form helper was changing my /edit/id form URL to /add!

I could not for the life of me figure out what the problem was. After an hour of various curses and attempts to correct the issue, I stumbled across this little bit of information:

You need to add a hidden id field with the id for the record as the value in order for the edit URL to persist. D’oh!

I simply added this to all my edit views and voila! It worked! Hopefully this will help someone else 🙂

Just a couple of updates

I am still working on my OMGSUPERAWESOME project, although I hit a stumbling block and have spent the last 3 or 4 days tearing my hair out.

I mentioned how I had started developing with Kohana. Everything was working well (for the most part)….then I read a post from one of the lead developers that Kohana 3.0’s code would most likely be incompatible with 2.3.x’s. Apparently this is fairly common with Kohana, and I suppose depending on your point of view it can be a good thing or a bad thing. For me this was very bad.

Maybe I’m just stubborn but I like the tools I’m working with to remain somewhat stable between versions. I don’t want to be told that the code I’m writing now will have to be completely reworked to work with the new codebase. That’s a humongous waste of my time, and any users that may be using my software.

So I was playing with the idea of going back to good ol’ CI, but I gotta say — I really did not relish having to go back to writing 2 to 3 times as much code just to get a semblance of the functionality offered from Kohana or one of the other frameworks. Maybe I’m lazy, or maybe I’m just looking to increase my productivity. Maybe both.

So I started playing with CakePHP again, and spent the better part of last Sunday measuring the difficulty of setting up the MVC for a fairly straightforward part of my app. It wasn’t as hard as I was afraid it would be so I continued working with it and slowly have become more impressed with it.

I’m still a little hesitant to say for sure that I will end up sticking with Cake; I’m concerned that if I release my app and someone has an issue that isn’t directly related to my code (ie, it’s an issue having more to do with Cake) it’s going to be a lot harder for me to track down since I’m not as familiar with Cake. I’ve “made up my mind” that I was just going to say **** it and go back to CI only to remember why I was so frustrated with CI in the first place. On the other hand, Cake is a lot more rigid and I find that I end up bending my app around it, whereas with CI it’s more of a silent partner. Of course, with CI it’s pretty easy to end up with a lot of spaghetti code.

Suffice it to say I haven’t definitively made up my mind yet. *sigh*

php frameworks – my opinion

I heart PHP. I’ve been working with it in one form or another for over 8 years — back in the PHP 3 days, even! I’m entirely self-taught, relying on and tutorials to help me figure out how to do stuff.

Last fall I was working on a niche-oriented CMS and was getting majorly bored/burned out by all the procedural stuff; the code felt horribly messy to me and I wanted to get into OOP (Object Oriented Programming) but previous attempts had left me scratching my head.

Somehow I stumbled on CodeIgniter and I was immediately hooked. Once I figured out my way around MVC and their way of doing things I tripled the amount of code I was able to put out. Was my code the best you could ever find? No, but it was definitely a step ahead of where I’d been.

Once I finished the CMS I decided to tackle another project and turned again to CI. I’ve been working on this project for the majority of 2008, and might have it done by the end of the year.

Now, I really love CI because it’s so easy and flexible, and it’s pretty much agreed that they have the easiest to understand documentation. However, I began to get frustrated with some of the features the default CI lacks – Auth being the biggest — so I started “shopping around” some other popular frameworks. Following are the ones I dabbled with. Note that there are no benchmarks because frankly that wasn’t my concern — realtive ease of use and the speeding up of my development were the primary concerns was.

Zend Framework –
Impression: After Symfony, I say ZF is probably the daddy of the frameworks. You can develop some really powerful stuff with it. That said, I found it to have a really steep learning curve and to be too loosely coupled for my taste. Requires more manual configuration than most other frameworks. It took me almost a full day to figure out the Zend_Db class and even then I wasn’t able to move too far with it. I was really impressed with their ACL and Auth classes, although I didn’t get far enough to really dabble with them.
Conclusion: If I had more time to play with it, I’m sure I could figure ZF out and develop some really cool stuff. For now, I will most likely stick with implementing components of ZF with other frameworks.

CakePHP –
Impression: One of the most popular frameworks. Pretty strict with naming conventions. Models are a must (this is not a bad thing). I actually played with this for a couple of days and got a lot farther with it than I did with ZF. The docs (2.2) are pretty good and I was able to find almost everything I needed to know within them. Because it’s so popular, finding things that weren’t in the docs — like a form tutorial — was really easy.

Conclusion: I may go back and try my hand developing something with Cake. If you have moderate experience with MVC, it’s not (IMO) that hard to learn. It’s a lot slower than pretty much any other framework but it also does a lot of stuff for you that could speed up your production.

KohanaPHP –
Impression: Kohana is a relative newcomer to the PHP Framework scene; it originated as a fork of CI when a bunch of CI developers got tired of waiting for EllisLab (creators of CI) to fix bugs with CI. Right now the current release is 2.2 (I think) and while a lot of things are different from CI, it’s still feasible to port CI apps to Kohana by renaming a few things and following some different rules, like using helper::helper_function instead of $this->load->helper(‘helper’) and helper_function(). I wasn’t very impressed with their docs; I found reference to the “Forge” class, that helps consolidate form creating/validation rules, only to find out Forge has been depreceated in Kohana 2.2.
However, Kohana does seem very powerful and I don’t think it would be too big of a leap to go from CI to Kohana. I really like that they have an advanced archive class as well as auth and payment modules.

Conclusion: I will probably use Kohana at some point; I may even recode the 2nd draft of my current project in Kohana since it provides more built-in functionality than CI does. I really like that it is community based; however, from what I’ve read the framework seems to depreceate things fairly often, which could make developing with it a pain in the ass.

CodeIgniter –
Impression: As I said, I love CI. It was so easy to learn and really helped speed up my PHP production. The community is awesome, the docs are awesome, and it’s so flexible I can do pretty much anything I want with it. The “bare-bones-ness” of it, though, is also frustrating at times, especially when I have to manually code something in that the other frameworks provide by default — again, mainly Auth stuff. I think it’s kind of neat that it’s used and backed by a company (EllisLab, which produces the Expression Engine commercial CMS), which should provide security as far as it being around. The bad thing about that is that since it’s developed and maintained by a company, fixes to bugs and other issues can take a lot longer than a community driven framework. I’d really like to see CI get into module-type stuff or at least include company-supported libraries like auth and payment.

Conclusion: I will likely stay with CI for now; when I get more time to dabble with Kohana more it will become more of a competition in my mind. I have to say, though, that for each (hee!) framework I tried, I ended up going back to CI with relief mostly for its flexibility. That could just be due to my being most familiar with CI, though.

To wrap it up, my choices would likely go like so:

  1. CodeIgniter
  2. Kohana
  3. CakePHP
  4. Zend Framework

I know that this hasn’t been a very “techy” type of comparison; as the title suggests, these are merely my opinions on the 4 frameworks I’ve tried out. Eveyrone has one that clicks for them, and you’re definitely entitled to use that one and call it the best (for you!).