5 Things CodeIgniter Cannot Do (without a rewrite)

Posted: 2012-12-05
Category: CodeIgniter

Now that PHP 5.2 is gone from my life entirely I am a happy man. As I don't use PHP 5.2 anymore I no longer need a 5.2 framework, so I quit the CodeIgniter team and started focusing on my new job.

Kapture is all PHP 5.4, and PyroCMS is moving to be PHP 5.3, so I can use anonymous functions, short ternary operators, namespaces, go fully PSR-2 and use Composer all the way. PHP 5.3 is a massive change from PHP 5.2 as of course it was meant to be PHP 6, so while it might SEEM like a small update it's really not. It opens up doors to whole new possibilities, a newer more mature style of programming and sucks SO MUCH LESS than earlier versions of PHP.

Most of the features added to PHP before this have not fundamentally changed the way a framework should look. This served CodeIgniter well and it has managed to maintain the same API for as long as I can remember. Since I started using v1.4.1 back in 2007 or whatever I can name the breaking changes:

  • Validation was deprecated and replaced with an improved Form_validation library
  • Constructors changed to use __construct() instead of PHP 4-style constructors
  • Plugins were deleted
  • extends Controller became extends CI_Controller
  • Instead of returning FALSE for unknown data it will now return NULL (like PHP does itself)

Other than that, nothing has happened to break existing applications even though we managed to add a whole bunch of features. So what features are missing from CodeIgniter that pretty much every other framework either currently has, or is working on adding?

1. Autoloading

As features started popping in to PHP 5.1, 5.2 a rewrite was suggested by hundreds of users. The folks that wanted more static and more autoloading tried pushing it, but EllisLab put their foot down, which lead to those users rage-quitting and built Kohana, which autoloaded static classes like they were going out of fashion.

CodeIgniter instead has a feature called "Autoload", which most other frameworks refer to as "Always-load" or "Eager-load". Basically it's an array of stuff to include - that's it.

Multiple times I looked into how I could work autoloading into CodeIgniter properly, but never came up with anything feasible. The main reason here is that there is no indicator to what you are actually trying to load, so when you try "new Foo;" it could be a library, a model, some random third-party code you found on a blog, a Zend class you've bundled in, anything.

CodeIgniter would need to do a series of file_exists() checks throughout to try and guess, then once the class is found we could generate a class-map cache (like Kohana). That not only seems like a slightly crazy solution, but would almost certainly confuse the large number of beginners in the CodeIgniter community that would not understand why their changes were not reflected instantly.

One solution is to use suffixes or prefixes on the classes (like FuelPHP) as Model_Foo is clearly a model, so that cut's things down a bit, but every time I proposed it on the forums half of the people involved were screaming that they hated it, and the rest were arguing over suffix or prefix, so I gave up trying.

The ideal solution would be to include the composer autoloader, but that won't happen because the community in general has always been extremely against command-line utilities being used.

2. Namespaces

CodeIgniter does not use namespaces at all. The requirement for namespaces can be somewhat avoided if you prefix or suffix classes, but that is just a workaround and not a solution. Really a namespace should be applied to all of the code in the core, then each "Spark" or package should have it's own namespace.

This drastically improves autoloading as you give the autoload class a pointer as to where it should be looking for this code, instead of how packages currently work: foreach through EVERYTHING until it finds one that matches. If two packages contain a "Curl" library then it's going to load the first one it finds. The second will never be loaded thanks to the "singleton" approach, meaning if package B requires functionality in a different version of "Curl" then it's going to break.

The other issue is one that can be seen in PyroCMS. Add-on developers can't create a module called "events". It would need a controller called "Events", but there is a class called "Events" which is a library. This is extremely frustrating and could be solved with prefix or suffix support. I would have loved to work that in, but of course namespaces are PHP 5.3 only.

3. Database Schema Abstraction

So this kinda happened in 2.0 and actually worked by 2.1. When I say it worked, I mean if you were using PDO for MySQL you could SELECT, INSERT, UPDATE, DELETE perfectly, but DBForge does not work at all - and still doesn't in the 3.0 branch.

Andrey Andreev did a great job here and created "PDO Sub-drivers" which mostly worked. He had a damn good try and getting everything working and as far as I know it's the last feature the team is working on before 3.0 is released, but really the DBForge system is modeled much too closely around MySQL for this to ever really work.

Do you know how you create a full-text searchable field in SQLite3 using DBForge? You can't.

This almost by itself is why I have spent the last little while transitioning PyroCMS' installer over the the Laravel 4 database component, because it is capable of installing PyroCMS on MySQL, PostgreSQL and SQLite - which will be a feature in PyroCMS 2.3.

4. Unit-Testing

Until 3.0-dev CodeIgniter never had any unit-tests on the core. They were added by some heroic work by Greg Aker (ex-Reactor team member), Pascal Kriete (EllisLab employee) and multiple contributors. I use the word heroic, because getting CodeIgniter unit-tested was a MISSION and a half.

The core is getting fairly well covered (when I left a few months ago it was 40-50% somewhere) but there is going to be a lot of CodeIgniter that you just can't test - especially your applications.

To draw yet another comparison to Laravel 4, you can unit-test your applications perfectly.

5. Good Migrations

I wrote Migrations for CodeIgniter, so I am not offending anyone by saying they suck.

Why did I write shitty migrations for CodeIgniter? Because it was the best that could be done without a command-line helper much like Oil for FuelPHP or Artisan for Laravel. Really migrations should be generated with simple arguments, use a timestamp instead of a generic number and run with some command like "php ci migrate", but instead you need to implement $this->migration->current() in a hook or some crap to make it run on page load.

I'm sorry.

So break the API!

Every project has to walk the line between "Never Change Anything" and "Fuck You Start Again". We've seen these changes rip communities apart at one end of the spectrum, and let others rot and fade away. While I am over the moon that CodeIgniter has not rewritten itself a million times (that would really screw with PyroCMS) the but there needs to be some sort of middle ground that just isn't happening.

It's not that development just isn'y happening, because it is. CodeIgniter has had more bug fixes, tweaks, improvements and new features than any other version in history.

The issue here, is that if it's going to move to PHP 5.3 there are only three logical outcomes.

A) Major Changes

To take advantage of the missing features I've mentioned (especially the ones that PHP 5.3 brings) and removing ALL of that old PHP 4 "tech debt" would essentially make it a new framework, and need serious effort to migrate an application.

B) Trivial Changes

The API will stay pretty much the same, but some new PHP 5.3 syntax will be used in the core like short ternary operators. If that happens then there would be little point updating the framework version requirement in the first place, and people will complain that the new features were not enough to warrent them having to change their code at all.

C) Change Nothing

CodeIgniter keeps on as it has been and flagrantly ignores new PHP 5.3 features, ignores PSR-0, ignores Composer and ignores all the new stuff out there in PHP.

It's not "A"

I say this for a few reasons. Firstly, who would do it? Right now Andrey and Alex Bilbie are doing an amazing job of keeping on top of issues but they are not paid to do this, they do it because they use CodeIgniter and want to make sure it stays working - the same reason I asked to be on the team.

There are other Reactor engineers, but as their friend I know what they're up to these days - and it's not CodeIgniter.

The logical question to ask next is why don't EllisLab do it? They've not rewritten it in the last 6 years, why would they start now? All of the CodeIgniter developers in EllisLab that I knew from the old days have quit the company, so who is there to do it? Derek Jones is the new CEO so he's going to be busy running the whole company, not writing a PHP framework.

Fork CodeIgniter?

That's happened three times already. Kohana and FuelPHP were both created for this reason, Kohana aiming at PHP 5.2 and FuelPHP utilizing PHP 5.3 and namespaces. Laravel 3 was also based heavily on CodeIgniter, Kohana and FuelPHP - so they've already done the hard work, built a community, built a website, set up the Twitter account, trademarked a name, organized the conference - I don't see how another fork is going to help anything.

Is CodeIgniter Dead?

Absolutely not; and nobody is in a position to suggest that it is (looking at you Shawn McCool). CodeIgniter is simply never going to change, and maybe that is ok.

Thousands of companies of all sizes are using CodeIgniter so whatever happens the framework is always going to be around, but it will be exactly the same as it is now for years to come, which means you aren't going to have to upgrade any legacy apps any time soon. Yay!

I wrote this because people have been asking why I've ditched CodeIgniter for PyroCMS, and started moving it to Laravel 4 instead. I'm sure people will think I'm just wildly slagging CodeIgniter off, but I think its possible to respectfully highlight a products shortcomings without there being any hatred or resentment.

The main reason - and I will repeat this over and over again until everybody is tired of hearing it - is that PHP is going through a massive change. Composer, PSR's, the PHP-FIG, Travis-CI making unit-testing suddenly become cool, etc ALL mean that there is a whole new world being built out there. New PSR components doing amazing things, and making things like my CodeIgniter Curl library look like an absolute piece of shit. New times call for new tools, so use something new.

Laravel 4 has become the "go-to" framework for me because it's built exactly how I would have wanted to see FuelPHP 2.0 built. Components of Laravel can be used in any framework and the framework itself is extremely skinny and unassuming. It's all PHP 5.3, namespaced, PSR-1 compliant, and feels extremely familiar if you've ever built anything with CodeIgniter, Kohana, FuelPHP or even Sinatra.

Something that makes Laravel stand out from the crowd is that it swallows it's pride to leverage any existing tool that does the job instead of bullishly reinventing the wheel for the sake of it. Monolog, Symfony Console, Doctrine Common, etc are all used where needed to perform the tasks they were built for.

Make Your Own Decisions

Don't blindly go and switch everything to a new framework just because some guy said so on a blog, that would be ridiculous. If PHP 5.2 support is your thing then stay where you are. If you like CodeIgniter and it does everything you need then awesome, carry on.

If like me you've hit the limit on what CodeIgniter will actually let you do, or you just feel bored and want to try something new, then absolutely check Laravel 4 out.

That is the GitHub repo for all of the composer components, take a look at /app and run composer install to get started.

Whatever you do, if your framework does not support Composer then fuck that noise. Use Composer to install your packages, and if you are trying to use something that does not have a composer.json then shout at the until they do - or send in a pull request.


Spicer Matthews


Great way of putting it!

All new stuff in my world is L4 and legacy CI apps will be slowly migrated to using mainly composer libraries.

Hari K T


Nice post mate. You have covered well. Happy to hear you are going with PSR-2 too. Awesome.



Hi Phil,

great post,as always! I've been using CodeIgniter for long time and recently upgraded hosting to support PHP 5.3 so I started learning Laravel. I really like it but there is one "obstacle" that is keeping me from using/switching to Laravel (or even FuelPHP etc) for new projects: I built a simple CMS in CodeIgniter that I use for most of my simple websites. Switching to new framework would mean I have to rewrite this CMS (which is not that good anyway) with a new framework and when I think of this I usually say "meh,I need to make a website fast, let's use CodeIgniter with CMS I built". So somehow I keep putting away the switch. Every time I hear someone says "I switched to different framework and developing is faster!" I want to ask them: "But what about CMS?You need backend ,clients needs to update stuff etc..You switched to laravel and build new CMS for your project? How does Laravel or FuelPHP etc help you develop websites faster when you leave your CI CMS behind and you have to build the one from scratch?"

I was wondering if you have any advice on how to approach this? Should I just force myself and reserve some time every day and rewrite my CI CMS? (Another problem is that it might be shitty CMS because I am just learning Laravel). Or go and find some existing cms in Laravel like pongocms? As I said, If I start making new website in Laravel I need CMS behind it and in Laravel I dont have it. Not everyone works in a company (I am a freelancer) where they,for example, work with FuelPHP or Laravel AND they have CMS built already. If a client approached you and said :" I would like you to build me a simple site in Laravel or FuelPHP with ADMIN" what would you do? Use one of existing CMS solution?Build your own simple Laravel CMS?

Sorry for my English,it is not my first language. Hopefully it is clear enough what I wanted to ask.

Keep up the good work and thanks.



Nice post:) thank u



Can you recommend any 'affordable' hosting solution that would support cli, git, composor (with enough memory)? I'm really struggling finding something that I can use.

Andrey Andreev


With the exception of fulltext indexing for SQLite - I do believe that the rest of DB Forge finally works fine!



Jan: You've successfully fallen into the "I need to use the same tool for everything" trap. If you need to use a CMS then do it, if you are writing something custom then use a framework. If you are just trying to knock out some basic site then which framework that CMS is based on is totally irrelevant.

Andrey: Great work dude, that certainly takes a black mark away from CI for the 3.0 release. Hopefully EllisLab get that design on the user docs and you guys can release soon.

John Kevin Basco


Very very very nice article! Thank you. I really liked that you didn't need to tell anyone that a framework is dead just to point out amazing features and advantages of another framework. And I really liked your saying "use the right tool for the right job". Keep up the good work!

Dustin Graham


Hey Phil. Wonderful post. I really enjoyed reading your detailed analysis. I've actually been working on a new project that decided to go with CodeIgniter. As I have been previously using ZF and Magento, and even writing two of my own custom "frameworks" for a pair of projects, I found CI to be quite simplistic, and "old" feeling.

I was a few hours into migrating a different project over to CI, when I found this post. Taking a look at Laravel, I think it would be a lot more fun to migrate to that, than CI since I essentially have a fresh slate to work on.

Going to dig into the docs a bit, and see what I can see. But, I DO love all the new features of 5.3. One thing I was trying to stay away from for this project is the sheer size of ZF2, and Laravel seems to have the nifty toys of 5.3, without the hefty size of ZF2, so it looks like the perfect candidate. Thanks!



Nice post! Thanks. Very good overview of the shortcomings. Sorry for my english



Hi, when we could expect laravel 4 to come out? :)

Akinyele Olubodun


Good post Phil. I have also moved to Laravel. I appreciate your constructive presentation of your view. It is really insightful.

Good job.



Solution is easy name current as LTS then release new with new PHP features ..



but about Laravel, I dont thing it make success with current strategy .. Publishing a tools to make it popular need better strategy

Paolo Umali


Laravel 4 is the easy bridge into making PHP developers embrace Composer and usage of worthy component packages. Frameworks after embracing Composer are now like dishes with same ingredients but prepared differently or with some extra seasoning/recipe. Just choose which one tastes good for you.



I love laravel, don't make me feel frusted when create the layout, the way how work CI is kinda messy, Laravel make me feel more freedom and is more powerful, add bundles is more easy and the bundles are more powerful than a CI libray.

Also, if in CI a wnat a CMS or create my own cms or use pyro cms, but with laravel there are a bundle for a cms, just add the bundle and create more functionallity.

well, laravel is awsome, thank CI for many years of awsome way to create apps, but your "sons" laravel, fuel php and kohana are better

Jason Stanley


CodeIgniter is dead. It doesn't know it yet. Its dead for the reasons you list above. Its dead because - I assume - EllisLabs didn't want to make CI2.0 in PHP5.3.

I have been using CodeIgniter since 1.4 and when the 2.0 announcement came out I argued daily for weeks about how CI2.0 should be built in PHP5.3. 5.3 was obviously the future. Instead they stuck with 5.2 which I think was a really bad error.

CodeIgniter can still be saved. 5.3 support can be added. Things like auto-loading and name spacing can be done. Phil speaks about the reception to using a prefix or suffix on model / libraries etc and the reception he got. The problem is that this was proposed as an option. People do not like change and it was something people could argue against. Realistically someone needs to make a decision. "We are doing this. In the next version of CI models and libraries will require the following naming convention."

Phil talks about upgrading applications. Many applications do not need to upgrade if CI upgrades to PHP5.3. They can chug along on on CI2.x until they reach a point where they need a rewrite. Its like if you was using Zend or Symfony or Joomla and a new version came along. You would only invest in rewriting and upgrading if you could justify the cost. PyroCMS would upgrade (I presume). The app I wrote for a client this year wouldn't. The next app I wrote for a client would be written in the new version.

The problem is that PHP is moving into the future and CodeIgniter is stuck in the past.. PHP is become a better language with far more powerful development options. You talk about the command line and how some people do not like it. In my opinion its only been in the most recent versions where actually using it has become worthwhile.

I used to always recommend CodeIgniter to new developers. It was simple and while it wasn't at the cutting edge of PHP it was a good way to introduce a developer to a simple workflow. Now I would recommend Laravel. CodeIgniter would be poison to a new developer as they would be touching outdated versions of PHP and older work flows. Its now a terrible choice if you want career development.

CodeIgniter is going to limp along for some time yet. However, the brightest people are going to move on. (Look at yourself) You look at EllisLab's products. In the next year or two there will be better options which are written in PHP5.3 (Even phpBB is being written in Symfony.) What EL products are built on will be a handy cap in attracting new developers.

The only time I see CI upgrading is when EllisLab's requires it. Considering how PHP announced the EOL of PHP5.2 on 16th December 2010, I don't think there is much chance of that happening any time soon.



Hello! This is my first comment here so I just wanted to give a quick shout out and tell you I really enjoy reading your blog posts. Can you recommend any other blogs/websites/forums that cover the same subjects? Thank you!

Posting comments after three months has been disabled.