CodeIgniter 1.7.x, ‘Core’ 2.0, CodeIgniter Reactor, Bitbucket, Zips… It’s all rather messy

It was just a few months ago that the CodeIgniter community began to explode with a torrent of frustration that CodeIgniter simply wasn’t progressing as a framework. There were also a few prominent developers considering abandoning the framework in favour of more active alternatives.

My favourite summary of the whole situation came in the form of a very enlightened article by Michael Wales at the end of November. One of the main problems highlighted there was the way CodeIgniter was put on the back-burner by Ellislab.

Since then of course, the CodeIgniter Reactor has sprung up with the aim to allow the community to have a more active role in the progression of our beloved framework. With a few active contributors, a suggestion box, and a bitbucket repository, the reactor is progressing much quicker than the standard CodeIgniter repository.

Bug fixes, new features, documentation… The reactor really is moving at quite a pace now, but not too quickly that it’s become unstable. In-fact, quite the opposite. I’ve been using the reactor on a production-level for quite some time now, and not noticed any major problems. And, any minor niggles/bugs have been fixed quickly. At he time of writing this, the reactor has had 11 commits in the last week.

Great news! We have an active framework again… right? What could possibly go wrong?!

Before we go patting ourselves on the back, and heralding the reactor as a great success, there’s a much wider question we need to look at: ‘Are people actually upgrading?’.

A few weeks ago I released brand new versions of my Twitter CodeIgniter Library and Facebook CodeIgniter Library. Both of these require a critical bug-fix found in the reactor to do with $_GET. As such, I made it (or at least I thought I did), quite clear that these libraries required, and were built for the latest reactor code.

Since releasing these libraries I’ve received dozens of emails from users experiencing problems with them. After reading through support requests, skype conversations, and debugging, I discovered that almost all of these users had tried to use the libraries on older versions of CodeIgniter. Either version 1.7.x or an old version of the official CodeIgniter 2.0 codebase.

It seems quite odd to me, since I’m the kind of developer that starts every project with a fresh pull from the reactor bitbucket repo. But, there are lots of users out there who simply copy the CodeIgniter code from another project they have, or a zip they downloaded last year, and begin writing their application.

Yet, in a recent news post on the official CodeIgniter site, it’s clear that Ellislab wants people to move the the reactor:

Reactor is the recommended version of CodeIgniter for use in the majority of day to day work. When you see “CodeIgniter” by itself on this web site, it is referring to CodeIgniter Reactor. The downloads, documentation, and forums all reflect this change. Put simply, Reactor = CodeIgniter.

Dividing the community

This new, major change has left lots of developers ‘stuck’ with 1.7.x – They know CodeIgniter 2.0 is floating around, but still believe it’s some scary unstable beta. When they do decide to look into it, they’re confused by two different versions. When they do download it from the official CodeIgniter site, they don’t know specifically which commit/version of the reactor/core they’re getting.

It’s just confusing for developers who don’t use hg or git. They come to the official site, click a download button and just expect everything to work for them. But it’s not that simple.

If we’re not careful, we could end up losing many CodeIgniter users because of this confusion. Eventually, they’ll want to find a system with a simpler install/upgrade path.

What can be done?

Firstly, we need to write a good upgrade guide. I don’t know of a comprehensive guide to help users migrate their 1.7.x applications to the reactor. For whatever reason, they get intimidated due to the lack of documentation to take them through this process. Most of them don’t even know what’s involved, and think it’s a huge time-consuming upgrade process.

Secondly, stop supporting non-reactor bases. One way I’m trying to get people on the reactor boat is to release code that’s only certain to work on the reactor. If someone emails me because it’s broken, my first response is… “Download a fresh reactor base, install my package, and run it.” – That will always work, I know it will, because that’s how I’ve built my libraries.

This is one of the few times we in the CodeIgniter community actually have to be a bit cruel to the developers who are lagging behind. In order to progress with this framework we need more unity. It’s pointless building new features and fixing bugs if half your user-base will never get them because they don’t know how to, or are scared of upgrading.

Finally, we need to get people to use hg more. I can’t stand people saying “I downloaded CodeIgniter, and this doesn’t work”. These emails don’t help anyone. As the developer of the library I have no-idea what version the user has, what bug-fixes have been implemented since then, or even where they got their download from.

At least if they’ve cloned the repo they know exactly what version they have, and can easily pull down the latest bug fixes.

Learning to use version control holds huge value for a developer, and everyone should be grabbing their CodeIgniter straight from bitbucket with hg.

My Plans

As I continue to release new libraries and improve my existing ones, I will be completely dropping support for CodeIgniter 1.7.x – If you’re still using it, upgrade now.

When new features are released into the reactor, I will blog about them. How to use them, what they do, and a quick getting-started guide. This way, hopefully, developers will be able to keep track of the changes that are happening and become more aware of the development pace of the reactor.

Since the reactor is now on bitbucket, I’m pledging to submit bug reports and become more actively involved in the reactor development. I believe in open-source, the community, and free code. I feel it’s my duty to contribute back to the framework that’s built my career, and reputation as a developer. But, you don’t have to be a CI veteran like me to do this. Bitbucket is available for everyone. So get forking the reactor, squash bugs, and submit pull requests. And if you have no idea what that last sentence means – Get reading.

There are some great developers working on the reactor, and I trust them and the code they write. The reactor IS STABLE, and you should be using it. The time for gentle reminders is over. Now we need to start twisting people’s arms and start pushing them kicking and screaming towards the reactor.