Code Igniter is a framework for developing PHP applications. As a framework, it is designed to take a lot of the monotony and repetition out of coding by providing pre-packaged solutions to a lot of common problems. Code Igniter is designed around the MVC (Model-View-Controller) design pattern. The first step in learning Code Igniter is to realize that your programs no longer go directly to the PHP file you write, but rather they go to the frameworks loading file (index.php), which then parses the rest of the URL, figures out which controller is supposed to handle the request, and then loads that controller PHP file that you wrote and passes it all of the information to handle the request.

The default URLs for a Code Igniter driven application are of the format http://your-server/the-site/index.php/foo/bar. Through a trick of mod_rewrite, you can use the cleaner URL of http://your-server/the-site/foo/bar. This is one point that is a definite plus for Code Igniter; the URLs it produces are extremely clean and pretty. There are some difficulties to this practice, however, since I have had issues when trying to have some controllers get redirected using the internal _remap function and leave others to their defaults. Another major issue I had was that Code Igniter no longer allows the use of GET parameter passing. Not only does it prohibit the use of a question mark in an URL (it errors out and displays a friendly message saying that your URL has invalid characters in it if you try), but it also calls unset on $_GET inside the framework before it gets to your controller.

There is a config option to re-enable the use of GET, but for some reason this automatically disables all of those pretty URLs and forces you into using index.php?c=foo&m=bar instead of the original /foo/bar. This is terribly aggravating for anything that you actually need to use GET for when you still hope to have pretty URLs. I used Code Igniter on a fairly large project which had six different parameters to filter pages by, each of them optional. Using GET variables this is fairly easy since the presence or absence of the variable indicates whether the parameter is being used. Rewriting this into a URL schema without GET is much more difficult. I understand that disabling GET is a design decision to help keep the URLs pretty and enforce good practices by not allowing people to actually upload data through GET, but this particular instance was a perfectly valid use of GET.

Code Igniter provides a method inside of routes.php that allows you to use regular expressions to redirect requests in the URLs to a specific controller and method. They don’t provide much help to explain how to do it, so I assume that using it is a fairly non-standard practice. Some of the rewrites that should have been incredibly easy were not. For example, a rule like

$route[‘year’] = “events/year”;
$route[‘year/(.*)’] = “events/year/$1”;

Is needed to handle a URL like /year if there can be anything else coming after year. If you have only the first rule and you go to http://your-server/the-site/year/2007, then the server will have the default controller and default method handle the request instead of events->year(). If you have the second rule only, it will have http://your-server/the-site/year/ be handled by the default controller/method. This last issue does not make sense to me at all, since the .* should mean that it will handle something OR nothing.

Code Igniter tries to be very light weight, and to some degree it does succeed. But given a lot of the other features that have been included, I was frankly amazed that they did not integrate a decent templating engine. Thankfully, some nice third parties have created Smarty libraries that you can add to your Code Igniter project. I highly recommend using it, especially if you work now or intend to work with a separate designer in the future.

Another nice feature of Code Igniter is their use Active-Record style database queries. You can write your own complete queries, or use a lot of abstraction that they included so that your application can be reasonably database independent and porting to other database servers in the future will not be difficult. Their abstraction system has almost all of the features that I would want in an abstraction layer, and the way it handles results is quite clean. More details on that can be found in the Database help in the Code Igniter user manual.

Speaking of the User Manual, this is one area where Code Igniter is pretty much unbeatable. The user manual itself is very well written and organized, I am a very big fan of the Table Of Contents drop down on every page, and they have a plethora of examples on almost every topic. The wiki helps out some too, although it is much harder to navigate.

Code Igniter is supposed to be expandable and it provides hooks into the different sections of the framework while it runs to allow you to perform actions at different times. This is very useful, but the first time I had occassion to use a hook, I found that it did not have a hook at the point I needed, and I ended up having to make an ugly work around to handle it. I was trying to integrate Smarty’s caching system into the rest of the application, since the Code Igniters caching is poorly documented and does not seem to be as customizable. Since the cache needs to know which page is going to displayed before it can check for that cache file, I needed a hook after the controller and method had been selected and the controller instantiated, but before the method was called. Since this was not provided, I ended up having to write a hook into the earliest part of the framework (before the framework itself is even loaded). In retrospect, this probably ended up better after all, since the caching mechanism kicked in faster and significantly reduced the PHP run time and the server load time (by a factor of 15!).

Overall, I give Code Igniter an 7.5 out of 10. It has a lot of good features, it documents it well and it does fairly well at enforcing good practices. For small projects and websites with fairly simple to organize data, you can have a full blown website with administration sections and database driven page generation in very little time. For more complicated data, Code Igniter seems to break down and I ended up having a little too much bloat. As Code Igniter gets more use, I am sure a lot of these wrinkles will get ironed out. I would rate it lower, but the fact that the internal code is clean and that the documentation is so good are both signs that it is a well organized project and as such, improvements are virtually guaranteed to come.