CodeIgniter 2.0 In Progress – The Critical Changes, Implications, and What You Should Know

Well, it’s been a long time coming, but Ellislab have finally done it, they’ve officially let us know about CodeIgniter 2.0. This is a huge step forward and shows that Ellislab are dedicated to this, their only free product.

I get plenty of emails asking me if this version of CodeIgniter would be released, and it’s clear there’s been a huge buzz about this in the wider development community. So, I’m going to take you through the changes and explain what you need to know, and what this means for CodeIgniter as a framework moving forward.

I’ll make this quite clear: I will not just list all the changes in the changelog. You should be able to find and read them yourselves. This post is more of a summary of the important changes and what they mean for Ellislab, developers, and clients.

CodeIgniter 2.0 is built using PHP5!

CodeIgniter 2.0 WILL NOT work on PHP4 environments. For a long time CodeIgniter was one of just a few frameworks that supported PHP4. Whilst this did attract a great deal of people to it, it became clear that at some point Ellislab would end up forking the CodeIgniter framework to produce a PHP5 only version. For me this is no surprise at all, but there’s a different, and more appropriate way to view this change.

PHP 4 support is deprecated. Features new to 2.0.0 may not be support PHP 4, and all legacy features will no longer support PHP 4 as of 2.1.0.

Most people will assume that this change simply means one thing: that people can’t use CodeIgniter on a PHP4 server. Whilst this is true, it’s a rather insignificant implication of this change. The main, and most important thing about this change is what it does for Ellislab and the framework as a whole. Ellislab can now use the more powerful features available in PHP5 in CodeIgniter’s core.

CodeIgniter will be able to use autoloading. The list goes on and on.

In short, the most important implication of this change is that Ellislab now really has some big guns they can use to move CodeIgniter forward. The improvements in PHP5 allow them to really unleash some seriously cool, clean code.

Application Packages

Many CodeIgniter applications I’ve worked on have contained more that one ‘application’ directory. For example, my main client right now has two application directories: ‘app’ and ‘cp’. The app directory contains all the code for the front-end application, and the ‘cp’ directory contains all the code for the back-end application.

However, there are some common libraries, helpers, views, and config files that both use. Right now I have to have two copies of each of these files. One for each application directory. But, now you can create a ‘common’ code area that will allow you to place libraries, helpers, config files, language files, and views in a common location, which can be accessed by any number of application directories.

Here’s how it could be used for this purpose:

Once you’ve written this code, you’ll be able to access booya_helper.php inside of application/_common/ despite this directory being outside of the current APPPATH. This, I believe, is one of the most exciting ways to use these new application packages.

View files for packages are currently in the works, but that’d just sweeten the deal.

Drivers

There’s a new type of library known as a driver. Essentially, it’s a way of having a parent class with many child classes. Child classes are able to access the parent class, but not its sibilings. For example, here’s how you might use one:

I’m quite excited about this, it means that grouping code with similar functionality would be easier, for example:

I think drivers will be a great new way for developers, such as myself, to release a ‘package’ of libraries that all do similar things (for example some of my API libraries). Drivers will also help us keep code DRY (Don’t repeat yourself). Many of the libraries we write share common code among them, and could be grouped into a bundle of libraries with similar code, functionality, and usage. These would be perfect to use drivers for.

New Javascript Library

We’ve known about this for quite some time, and it’s nice to see it finally come to life and make its way into the CodeIgniter core. Now you’ll be able to dynamically implement Javascript using PHP.

The new Javascript library is a driver (explained above). It currently has just one child, jquery. But, this will allow you to build much more elegant jquery code for your application without as much hassle.

I’m going to write a post specifically about using the new javascript library next week, sostay subscribed to the rss for that!

Plugins are Gone

Yes, Ellislab have give plugins the heave-ho in favour of helpers. I was never a fan of plugins to be fair, and I tried to avoid using them at all costs. It’s quite nice to see that things are being ‘removed’ from this new version of CodeIgniter as well as added. At least we know that Ellislab are determined to keep CodeIgniter as a ‘lean’ and fast framework rather than some of the bulkier overweight ones that are currently available.

Code Hosting Moved

For a few years Ellislab have used a subversion system to develop CodeIgniter, but now they’ve dropped it in favour of Mercurial, a much leaner version control system. The code will be available on bitbucket, where you can download the latest bleeding edge version, or specific tags (versions such as 1.7.0).

With bitbucket, we can now fork CodeIgniter much more easily, apply fixes, and then suggest that it be added back into the core.

To Summarize

There’s no shortage of things to get excited about with CodeIgniter 2.0. I’m most excited about application packages and drivers. I could think of so many clients with code that could use these features.

Remember to keep a close eye on the CodeIgniter project now. It looks like this could really begin to move at a faster pace.

| 13