Goodbye CodeIgniter, Hello Laravel

Daniel Gafitescu
Daniel Gafitescu

A lot of PHP developers are fan boys of their PHP framework, and there are quite a few from which you can choose. Among the most popular ones are CodeIgniter, Zend Framework, CakePHP, Symfony, Yii, and the new kids on the block Silex, Slim, Lithium, and Laravel.

In the beginning of my career I stumble upon CodeIgniter and I love it for its simplicity, small footprint, and good documentation. It worked great for me when I developed a small to medium sized applications (usually Facebook apps), and the learning curve for new developers who worked with me was shallow enough that they could easily be integrated in the development process.

But last year, because of the Twitter buzz from some in the PHP community, blog posts, and the suggestions of some friends, I give Laravel 3 a try – and since that time I’ve never looked back. So, in this article I’d like to present a comparison of the two frameworks from my point of view.


CodeIgniter 2.1.3 needs PHP 5.1.6, but versions before 2 still worked with PHP 4. This was a drag since everybody moved on to use PHP 5. Laravel 3 needs PHP 5.3 and also the Mcrypt extension.

CodeIgniter 1 didn’t need Mcrypt, since if you didn’t have the extension installed then it would use a custom functions to encode/decode strings. Of course this slows down the application, and we were amazed at some of the production servers that didn’t have it installed.

function encode($string, $key = '') {
    $key = $this->get_key($key);
    if ($this->_mcrypt_exists === true) {
        $enc = $this->mcrypt_encode($string, $key);
    else {
        $enc = $this>_xor_encode($string, $key);
    return base64_encode($enc);


It’s easy to build a REST API with Laravel using RESTful Controllers where you simply have the $restful property set true inside your controller. For example, if you’re building an API for a task manager, for updating a task it would use something like this:

class Tasks_Controller extends Base_Controller {
    public $restful = true;
    public function get_index()
    public function put_update()

To handle PUT in CodeIgniter you would need this workaround:

    parse_str(file_get_contents("php://input"), $post_vars);
    $arData = json_decode(array_pop(array_keys($post_vars)));

As you can see, this is error prone and not very clean.

Code Organization

Most of the time, the project you are working on will have a frontend and backend. In order to better organize the code in CodeIgniter, the best approach is to use HMVC. In this way you would have separate directories for backend code and frontend code so that different developers can work independently. To achieve something similar with Laravel, you can use nested controllers.

The View

CodeIgniter doesn’t have a default template engine, but you can easily integrate one like Smarty. On the other hand, Laravel uses Blade as its template engine which is very simple but powerful. With Blade, it’s very easy to set up a two-step view.

You have a master template where usually you put the basic HTML structure with a header, navigation, footer, etc. Most of the time this template is called layout.blade.php or master.blade.php. The portion of code that will be injected from different different controllers is declared in the master template by @yield('content').

  <div class="header">

In custom templates declared per each method of a controller, for example a CMS page like “About Us”, you have a template called page.blade.php which looks something like this:

About page section

You can have as many section as you like to declare and reuse.

A more detailed explanation about this can be found in the section Blade Layouts in the online open source book called Code Happy by Dayle Rees.

To achieve this in CodeIgniter, at least as far as I’ve been able to figure out, is to create a master controller which all other controllers extend and call a render method. A CodeIgniter start project for implementing two step views can be found under my GitHub account.

The Model

Codeigniter uses Active Record for database manipulation which is quite easy to master, but you can also use raw queries if you have complicated requirements. Laravel uses Eloquent as a ORM which is simple and works with major database servers. For writing queries, you can also use Fluent Query Builder, which looks like a lot like the Active Record approach. And of course, you can also write raw queries too.

Command Line (Crons)

For Codeigniter to call a cron script, the best approach is to create a Cron controller. You also need to duplicate index.php and create a cron.php file right in the root directory, overriding the following the following $_SERVER values:

$_SERVER['REQUEST_URI'] = "cron/index";
$_SERVER['QUERY_STRING'] = "lang=en";

Then you can call it from the command line with php cron.php cron index.

In Laravel it’s easier. You have Tasks using the command line tool that Laravel comes with called Artisan.


  • Unit Testing – Codeigniter uses a very rudimentary testing class for writing unit tests. It is limited, but you can integrate PHPUnit. Laravel comes with PHPUnit out of the box, the most popular PHP unit testing framework.
  • Authentication – Codeigniter doesn’t have anything out of the box for authentication, but you can always use a third-party library, like Ion Auth. Larvel on the other hand has a basic auth library that you only need to configure before using.
  • Caching – With CodeIgniter, the driver supports APC, Memcache, and the filesystem. Laravel on the other hand supports those and also database tables and Redis.
  • Hooks/Filters – If you want to step in and run certain code at different points of execution in CodeIgniter, you should do so using Hooks. Laravel offers Filters.
  • Routing – Routing is done pretty much the same way in both Laravel and CodeIgniter, although I’ve found Laravel to be more flexible.
  • Configuration – Configuration is done via predefined arrays stored in config files which support multiple environments in both frameworks.
  • Extensibility – Extending the core functionality of CodeIgniter is done with Libraries, and you can find a lot of them on Sparks (a package management system for CodeIgniter). Laravel uses Bundles, which might seem familiar to you if you’ve worked with Symfony 2. You can find check already-created bundles at
  • MigrationsDatabase migrations are specific for Laravel, a concept borrow from Ruby on Rails which is versioning at the database level.


CodeIgniter used to have a bigger community, but many moved to different frameworks after EllisLab, the company behind it, dropped support and no new features were added. Some of those people joined the Laravel community which is now very active with a lot of tutorials, books, and even its first international conference.

The future seems to be very bright for Laravel since Laravel 4 is in beta 2 and its first conference has just ended. On the other side for CodeIgniter, there are few member contributors who so commit/merge patches into CodeIgniter 2 but there is no release date for CodeIgniter 3.


With Laravel 4 on the horizon, the framework definitely has the momentum now and the community behind it is very active. I’m kind of nostalgic when I talk about CodeIgniter, but it served me very well at the time. It taught me how to use MVC, was easy to learn, earned me my first money, and I even did my first book review about it, but as time went on it hardly changed. Maybe it’s just because it was very good at what it did? But web development changes rapidly, and new technologies come around, so if you want to survive you have to keep up.

Just like in politics, everyone chooses a side. And for most of the time you can stick with your choice, but it’s always good to explore new things. For me, it meant goodbye CodeIgniter, hello Laravel.

Comments on this article are closed. Have a question about PHP frameworks? Why not ask it on our forums?
Image via Fotolia