Kicking Ass and Taking Names with CodeIgniter

I'm writing this article for all the PHP developers out there who are looking for a way to develop apps faster, better, and smarter. I'd like to make a case for the CodeIgniter framework as a way to achieve all that awesomeness, so bear with me while I make that case.

If you're anything like me, then you probably spent a great deal of time working with PHP without the benefit of any frameworks. You learned PHP from the ground up, building all kinds of apps and tools. You've likely coded any number of content update tools, custom e-commerce solutions. and other bespoke applications for clients. Every single one of those apps was probably based on super-localized process requirements or one-off (if not gonzo) data schemas, or both.

And, again, if you're anything like me, after a while (usually after 2 years or so) you started getting antsy. The thrill was gone, as B. B. King sang, and you were ready to not work so hard doing all the basic stuff that every project demanded. But still you slogged on, discovering a whole world of tools like SMARTY templates, PEAR libraries and lots of other geeky goodness. For the most part, the more you learned, the more you realized that most of your projects just didn't need all that heavy-duty stuff.

Meanwhile, your friends were all talking about Rails and how cool and fun it was, how quickly they could build apps with it. They had a gleam in their eye, and they talked about web development like they were young and in love, and yeah, it was infectious. They worked hard, but then they went out for a pint, and there you were, the poor bastard still working in PHP, and suddenly you weren't the cool kid anymore. 

So you looked at Rails, maybe bought a book, started to dig around. It was sexy, and sleek, and exotic, like a shiny new sports car that promised you a world of adventure. But then you took a look under the hood, because that's what you do, and everything seemed a bit strange. Not bad strange, just different strange.

Then it hit you. "I'm a PHP developer, dammit!" You had a bunch of existing apps for existing clients, and all of them were written in PHP. You didn't know how Rails would perform in a real-world situation. Rails gave you pause, you see, because it was all so magical--nothing wrong with magic, of course, but it just didn't seem right for your legacy applications, that this connected here magically, and could easily look up that other thing there, if only you gave it the right name.

But still, you were intrigued about this whole world of Model-View-Controller application development, because it made a lot of sense to hire a sheriff to bring some law and order to PHP Land. You knew that the best thing about PHP was also its worst feature--that there were a million ways to attack any problem, and it seemed that every project you were ever on featured at least 10,000 different approaches to the simplest, most straightforward problems.

And that's when you probably first heard about MVC frameworks for PHP, and somewhere in there, you heard about CodeIgniter. But you didn't have enough information about it, so now you're reading this piece. My goal here is to give you a 10,000 foot overview so you can get introduced to CodeIgniter. Granted, I wrote a book on the subject, so I'm pretty much committed to the framework's success, but that doesn't mean that I'm 100% sold it can do everything well. And it certainly isn't for everyone, no matter your PHP expertise.

So just for now, I'm gonna give you the basics and you decide later if you want to try it.

It's a flexible, compact, and simple Model-View-Controller (MVC) framework for PHP. If you're as analytical as I am, you're probably wondering why I'm using weasel words like flexible, compact and simple, so I'm going to drill down a bit to explain. I'm not going to give you any textbook explanations, either, just talk from the benefit of having written about 40 applications over the course of the last 2 years.

Let's go with the two most important things, at least for me as a developer: simple and compact. Compact because it is cut down to a manageable footprint. CodeIgniter 1.7.2 weighs in at 1.6 MB (as compared to 9MB for CakePHP). It contains various libraries and helpers to get you through all the tedious crap you'll encounter in every project--form helpers to build forms, HTML helpers to replace the tedium of markup, and libraries for handling calendars, emails, ZIP downloads, basic shopping carts, encryption, FTP, languages, caching, pagination, and lots more.

With CodeIgniter, use what you want, and ignore what you don't. If there isn't something already built-in, reach out to the community to get what you need, or extend CodeIgniter with your own helpers and libraries.

What about "simple"? Well, with most projects, you'll be breaking your code into three easy-to-understand areas. 

You organize your application using controllers. The functions in your controller make up your routes and paths. For example, if you have a path like this on your site:

/store/category/123

Then that means you have a store controller with a category() function inside it. That function takes some kind of ID as an argument (in this case, "123") and you can use that argument however you like--but usually its passed along to a model function that queries what you want from a database. Simple and straightforward. Oh, by the way, if you don't want to take the time to sanitize every single user input, you can adjust one config setting to have CodeIgniter do it for you.

I tend to create lots of different controllers to keep my applications well-organized, but there's no reason why you couldn't just have one single controller for you project. CodeIgniter doesn't really care, but if you're working with other developers, having more controllers makes it easier to split up the work.

Anything having to do with data is put into models--I tend to use separate models for different database tables, but you could flatten yours into just a few models. Some guys use a basic model that allows them to get one, get many, and so on, and just extend that into every situation. Inside each model are functions that do something specific with a database table. You could, for example, have a function that specifically pulls out a single category, all categories, or some other combination.

In no way do your model names have to match your database table names. Nor do your database tables have to follow some kind of predesignated structure, with certain field names. This makes CodeIgniter an ideal framework for use with legacy data schemas. CodeIgniter doesn't care that your key field is id or myID or foobarID, you tell it what you want in your model functions and it works.

I've built some projects without any models at all--that's right, CodeIgniter doesn't really care. This is a handy thing to know if you're just mocking up a static prototype. Just place all your static content in views and you're done. Of course, you could put the static content into models, if you like. It's up to you.

One more note about your model functions. You can use CodeIgniter's ActiveRecord functions to avoid the use of SQL altogether, or you can use raw SQL if you like. You can also download an object-relational mapping (ORM) library to abstract your data handling work even more, if that's more your speed. It's up to you.

Everything the user sees on the screen is placed in views. Again, I tend to create a lot of views, and organize them into various folders for each set of controllers, but you could do whatever you wanted here. Adding client-side tools like jQuery is easy, too--just add a folder for your jQuery files and reference them in your views, and voila, you're done. Start using jQuery. CodeIgniter doesn't care.

There's plenty more to CodeIgniter than that, of course--you can create custom libraries and helpers, and store configuration details in their own files, too--but you don't have to do much with any of that. Just make a few config entries to find your server root and database install, and you're ready to roll.

What does all this mean? Well, if you've worked on any non-MVC PHP project, you know that things tend to get a bit messy. You end up with PHP files that contain SQL queries mixed in with your HTML, and config items are thrown in for good measure. If you're experienced enough, you know to put your configuration strings into a global header include (for example) and to organize your functions and classes into separate files.  Add enough developers, enough late nights, and enough crazy client requirements, and things start to slide into sloppy land.

But here's the thing--CodeIgniter's MVC approach forces you to think smart, to think long-term, if you will, about your project, and start putting things in their proper places. Anything that deals with data goes in the model. Anything the user sees in a browser goes in the view. Anything that pertains to application structure or routes goes in the controller. If you need to refactor, you find yourself writing libraries and helpers.

In fact, you'll find very quickly that the controller provides an amazingly concise way to keep yourself on track. Customer reports a problem with a page, just ask for the path. Aha, the /store/category section is buggy? Open the store controller and look at the category() function. Looks like you're running two model functions and building a view. Now you know how to proceed, and it doesn't matter that it's 3 a.m. and you haven't slept in a long while.

Throughout this piece, I hope I've made a case for CodeIgniter's flexibility. Use what you need to get the job done, don't use what you don't need. CodeIgniter works with from-scratch data schemas, or ones you inherit. It has powerful libraries that allow you to add sophisticated functionality while still keeping the core of your application organized in a straightforward way.

I've written all kinds of applications with it, what some would consider the bread and butter of the web development world:

* all kinds of content management systems

* shopping carts and payment gateways

* community forums and discussion boards

* gadgets and widgets that connect to social media APIs, such as Twitter

* custom data-entry applications, such as contact databases

* any application that requires lots of calculation, such as billing and invoicing 

* any application that integrates with a web service, or uses FTP or email extensively

* any application that deals with calendaring or event management

In particular, CodeIgniter really shines if you're inheriting or upgrading legacy code or legacy data structures. In my particular line of work, I find myself rewriting apps that have seen better days, and in every case, I've never had a lick of problems with the underlying data structure (unless of course, the schema was bad and needed redoing, but that's a whole other story).

I've also had a great deal of success using CodeIgniter in dynamic project situations, where the customer requirements seem to change every week--change requests show up, and I can react quickly with solid code.

Frankly, if the application isn't right for PHP, then it probably isn't right for CodeIgniter. So anything that needs to be thread safe, requires multithreaded operations, or burns up a lot of RAM, you'll probably end up with the same challenges as with standard old PHP. If you're doing heavy-duty enterprise stuff and still want to work with PHP, you're better off with Zend. 

If you're doing  a lot of stuff that isn't in the typical "web application envelope" (creating games or doing system-level programming) then CodeIgniter isn't going to magically make things better.

If you're integrating your CodeIgniter app with non-CodeIgniter stuff, then you might have a few challenges around sessions and cookies, but that's probably true no matter what you're building.

That's about all I have to say at this point. If you'd like to try out CodeIgniter, then download it for free at:

If you'd like to hang out with a few CodeIgniter guys, check out my Twitter list:

We don't talk about CodeIgniter all the time, but it's a good starter list of CodeIgniter developers, and I hope to keep growing it as I keep meeting more people!