I've written many CodeIgniter tutorials, recorded a dozen screencasts, and participated in the #codeigniter IRC support channel for years. Consequently, many people ask me why I no longer use it. I realize that this article is not particularly flattering. But, I've answered this question enough times to warrant a post, so here it is.
CodeIgniter has been the go-to framework for programmers new to PHP frameworks. It is relatively easy to use, the documentation is widely considered to be good, and there is a large support community (there are currently 140 people in the CodeIgniter IRC channel). It has stood as the most popular PHP web-development framework for years. Consequently, there are many screencasts, written tutorials, and third-party libraries available. CodeIgniter is built around the concept of legacy support. So, its design is structured around the capabilities of PHP4.
However, CI has aged poorly due to a combination of legacy support between major versions and a virtually complete lack of leadership. Despite the emphasis on legacy support, recent versions of CI require PHP 5.2. PHP 5.4 is the most modern stable release and 5.3 is now available on any reasonable host. (If your host doesn't support PHP 5.3 then jump ship as soon as possible.) By providing legacy support (changes to the framework rarely require any changes to your code-base) CodeIgniter has been unable to implement any of the features available in 5.3 that give developers more flexibility to create elegant solutions to problems.
Since CI doesn't use any of the new features, best-practices suggest that its users should avoid them in order to provide standardized code. It should be easy to find and hire a PHP developer who is versed in CodeIgniter and mismatching a bunch of code-styles is a bad way to approach that goal.
When it comes to code modularity CodeIgniter is one of the worst performers in the industry. CodeIgniter is not built using any modular design pattern so all solutions are after-thoughts that were developed by members of the community. Out-of-the-box CI supports libraries (basic classes), helpers (global function declaration), and plugins (the same as helpers, these are not used). These are all different versions of the same concept separated by intent.
There are some third-party modularity solutions available. The oldest and most powerful of these is Modular Extensions by wiredesignz. It allows the implementation of HMVC modules. Unfortunately, in order to implement this he was forced to permanently alter core system files and this makes the code brittle. Issues can easily arise from upgrading CodeIgniter. As a long-time member of the #codeigniter IRC support team I can attest to the amount of issues that users end up running into as a result of this implementation. The fault is not so much on the code that drives Modular Extensions. But, on the fact that it's essentially a hack designed to expand a system that fundamentally rejects modular code.
Another third-party system released for CodeIgniter is Sparks (getsparks.org). I was a big proponent of Sparks at first and made a number of screencasts that encouraged its use. But, it quickly became apparent that Sparks is the worst form of code modularity currently available for popular PHP frameworks. The core concept seems reasonable enough. It's a command-line tool for installing packages that pulls from git repositories, supports server caching (removal of the original repo doesn't kill the spark), and versioning. These are all good things. However, it falls flat on its face due to the fact that it can't offer more than CodeIgniter itself does. Sparks can only provide libraries, helpers and config files. This limits its function to a central repository for CodeIgniter libraries. Unfortunately, it fails at that as well due to the fact that CI developers cannot rely on the libraries that they need being available within the Sparks system. A Google search ends up being the go-to method in the end, rendering Sparks useless. It is now apparent that modular code solutions have no place in the world of CodeIgniter. These are symptoms of a greater problem.
CodeIgniter was conceived by Rick Ellis of EllisLab. It is now community supported to some extent, but still seems to wilt under its creator's needs. CodeIgniter is the platform on which EllisLab's flagship product (ExpressionEngine) is built. In part due to the preoccupation of EllisLab with ExpressionEngine change to the CodeIgniter framework has come infrequently and the magnitude of the changes have been insignificant.
CodeIgniter Reactor was released so that the community could make changes and improve the framework. Unfortunately, due to the fact that there is no strong or dedicated leader, improvement to the framework has not occurred. One could easily argue that CodeIgniter 2.0 brought only minor usability improvements at the cost of dropping PHP4 support entirely. The CodeIgniter development team is either too busy with their other projects or just not sure what CI should become. It's no longer the framework for legacy support and it begs the question, "what was the purpose of dropping that support?" as users have seemed to have gained little in exchange.
When it comes to community participation only the most daring need apply. CodeIgniter is not well unit tested. This means that there is no way to responsibly make pull-requests as you're unable to test whether or not your changes have unexpectedly broken something. There was a time when this was the standard in PHP but as a community and as an industry we're past the point where that is acceptable. The community has been trying to catch up and to create tests for CI but in the last few years very little real progress has been made as the task of retrofitting CodeIgniter with unit tests is Herculean.
In summary: CodeIgniter has proven its inability to change and it can no longer compete with the feature-set or practices found in any other modern PHP framework. When I say that CodeIgniter has died. I don't mean that nobody is using it. I'm saying that CodeIgniter has nowhere to go and can become nothing more than it is.
Solution: Don't be content exploring only a single framework. CodeIgniter is lauded to be easy to learn. It is that. But, so are other frameworks. Do your due diligence and find what best serves you and your organization. Without experimenting we can't truly understand what we prefer. It's far easier to identify strengths and weaknesses when you have something with which to compare.
I use Laravel.
In this video I discuss using the Laravel source code as a valuable educational resource.
In this video I discuss the basics of embedding your application logic into Laravel's routes. We revisit the topics from the the application logic in controllers screencast and approach them a bit differently.
In this video I discuss where to put your application logic when using Laravel Controllers. I discuss registering controllers with the router, creating a route with a wildcard to send parameters to a controller action, and restful controllers.
An application will usually be deployed to many environments over its lifetime. From the team's own development environments to a staging environment to the production environment configurations will likely need to be changed.
Laravel provides a simply way to enable different configurations on a per-environment basis.
In this video I walk through the Laravel folder structure and share some of my thoughts about Laravel.
