Professional Freelance Web Developer
CodeIgniter Activist, Caffeine Junkie

Elliot Haughin

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

CodeIgniter 2.0 In Progress – The Critical Changes, Implications, and What You Should Know
11th March 2010

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 visibility modifiers to restrict access of object variables to the object itself. Static methods and variables, to allow code to call a class’ methods and variables without instantiating object. Abstract classes and interfaces, Reflection, __contruct and __destruct, 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:


// Structure:
// application/app = APPPATH (contains controllers, views etc)
// application/_common = my package, contains a few helpers and libraries.

$this->load->add_package_path(BASEPATH.’application/_common/’);
$this->load->helper(‘booya’);

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, so stay 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.

  • @GerardoRochin
  • Will modular support be built into CodeIgniter 2.0?
  • Thanks for the great insight.

    Packages look good. I've been using Matchbox to achieve this functionality so far.

    CI 2.0 documentation suggests that packages be placed in "third_party" directory. Your code suggests a name such as "common" which makes much more sense. If I write my own code that is shared among apps, it shouldn't be called "third party" code. Same goes with other people's libraries. They are third party, but they may or may not be placed in "third_party" directory.
  • third_party is just an example, it can be deleted with no effects to anything.

    Packages and Matchbox are two very different things. Packages will not allow modules.
  • Thanks for good news!
  • Thanks for the update. That's fantastic news so far and I can't wait to see what else CI 2.0 will bring.
  • Jay
    Hi Elliot,
    When plugins will be removed as you say, how can I then easy integrate php scripts easily that I previously been able to do? Make a require/include? Doesn't make sense to me.

    Thanks for answers!
  • Jay
    Hi Elliot,

    Any news?
  • Thanks for the summary. I am really excited about this release.
  • GiN
    Oh, it's great news. Unfortunately there is still no normal way to use all CI features with XSLT.
  • Good article. I'm not sure that it's right to say "CodeIgniter 2.0 WILL NOT work on PHP4 environments." as that is not at all what the article said. They just said they are no longer testing it.

    It's like saying you will no longer test your website in IE6; it may well still work perfectly fine, you ust don't care enough to check.

    What a day for CI fans though eh? Lot's of new code to look through.
  • As soon as a php5+ function makes its way into the codeigniter core, the application will not work on php4.
  • Sure but I really doubt that will be until 2.1. At the recent page of changes it will be a long time before any big changes happen to the core.
blog comments powered by Disqus

Boring Stuff

Design © copyright Elliot Haughin 2009

Content published here are copyright their respective owners.

You cannot copy content from this site, either in English or translated to another language.

Keep Subscribed

Theres lots of ways for you to keep up with me on the web.

Please Note

Information given out on this blog should only be used as a guideline. I hold no liability for any code I write.

Always consult a professional before acting on this guidance.