ZF4 Blog

Stop using CodeIgnitor

It has been my sorry pleasure to get involved in a project where the firm are developing their 'strategic direction' in CodeIgnitor (CI). Despite using the latest V3, I quickly came to realise that it hasn't moved on beyond that which I reviewed many years ago.

The bad points

CodeIgnitor is a teaching tool, supposedly maintained by the British Columbia Institute of Technology. It is a 'hide the complexity' framework in which to teach basic PHP. BCIT don't do a PHP specific course, and even their web development courses don't mention PHP often.

They do mention in one of their courses that they teach 'advanced PHP'. I hope to the Almighty, it isn't in CodeIgnitor

One can only assume CI is maintained by the janitor, (actually, in truth, it is maintained by what looks like a single developer if the github account is anything to go by.)

Super global

CI basically employs a Super Global pattern. Bit like very early invokations of Zend. You get one uber 'object' class, and everything is descendent from that. Zend has moved on. CI hasn't. On top of that, you have to work through a myriad of 'magic' getters and setters which are not documented (actually, that reminds me - the code documention is woeful, meaning that modern IDEs struggle to figure out what is going on.) Net result, is that when it comes to debugging, you might as well have a beer, for as much sense as you'll get out of it.

Dependency injection

There isn't any.

CI employs its own archane method of injecting stuff into the super global. It isn't elegant, consistent or performant. The code base is littered with $this->CI =& get_instance(). Technically speaking =& shouldn't be necessary as get_instance() should always return the same object, but hey ho, somewhere down the line not doing it broke something and it hasn't been fixed.

You cannot do dependency injection in CI, unless you use the V3 capability to use the Composer autoloader and then shift everything you can outside of CI.

Unit testing

Because of the super global problem and lack of dependency injection, unit testing in CI is a nightmare.

The good news is that Kenjis has written a hack to get PhpUnit working. And it does work. But the guy needs lots and lots of beers for the torture he has had to make it work.

Even with that said, you'll need to read his documentation to get around the super global nature of CI and no dependency injection in many situations.

No namespacing

If you don't know what namespacing is, read this. CI doesn't have it.
Modern PHP does. This means that trying to be clever and separate out, for instance, specialist Exception classes is not going to work the way you want. In not too infrequent cases this means using require_once. Modern PHP devs have almost forgotten what that means.

CI has it's own autoloader. You can tack on Composer autoloading, but anything within the strict CI boundary needs to conform to CI rules and that ain't always easy.
require_once will soon become your friend again, just when you thought it had gone away.

Composer

By the way, don't try Composing CI into a project - it don't work. You'll need read the documentation to figure out how you can include Composable code into your CI project. It's not switched on by default. And because CI itself is not namespaced you may still need the occasional `require_once' littered about.

Poor db support

Man, there is Active Record, there is ORM, and then there is CI. Half baked, neither one or the other. My suggestion to you is forget using the so called helpers and simply write $this->db->query($sql). It'll save you a whole lot of grief. Even the DBForge library, supposedly there to help do DB migrations is totally inadequate and you end up doing $this->db->query($sql) and other low level calls.

Poor documentation

On the surface it looks good. And when it is there it is not too bad. But in common with other frameworks, the navigation is awful. It is almost impossible to search across the entire content. You will need to hunt and seek once you get through the tutorial stages, and getting to what you want quickly is not easy. Unlike the big boys (Laravel, Zend, Symfony, Slim et al), Google doesn't seem to be able to index it very well either.

The good points

None. Well, I suppose you could say it is OK if

  • you are new to PHP
  • you want a simple website up with a minimum of PHP knowledge - just follow the glad rag tutorial
  • have no need of building anything beyond the very simple using code that is never going to change

How to get out of it

Simplest

Don't use it. Zend, Symfony, Slim, Laravel all offer grown up framework support depending on your needs. For very high performance systems consider HHVM, Phalcon and Slim

But I'm already using it

  • Move absolutely everything you can out to proper modern PHP namespaced libraries.
  • Limit interface to CI with a single $this->ci =& get_instance() in your class constructors if you need it. Better still, get to grips with the CI Library system, write your code into a namespaced class and use a library class wrapper to inject the real code dependencies. That way, when you get to move the code, you know what the dependencies are and can modify them easily.
  • Now move your code into something else, hopefully by now, you'll have figured out enough to know how to use some proper modern code and can replace the CI get_instance calls to a dependency injection solution

References

Don't just believe what I say, go have a look at what others say:

This one written 4 years ago says much the same thing. And another but you don't need to look far for reasons to use something else. Strangely CI still shows as popular in Sitepoint's 2015 survey. I'd like to see a 2016 result.

In summary

Don't use CodeIgnitor. It stinks. It will hamper your forward development plans, inhibit your product expansion and stagnate your personal growth as a developer.

This site is written using Slim for its routing, Symfony for its Dependency Injection Container and a bunch of Zend security aware components.