Harnessing the Power of CodeIgniter in ExpressionEngine 2.0

November 29, 2010


Why build your PHP utility scripts outside of ExpressionEngine and CodeIgniter when you can integrate closely? This tutorial will provide a foundation for tight integration with ExpressionEngine and CodeIgniter through the use of custom CodeIgniter controllers.

This tutorial assumes you have a basic knowledge of the ExpressionEngine 2.0 CMS, CodeIgniter framework, and are working off a clean ExpressionEngine 2.0 install.

Introduction

ExpressionEngine is a powerful CMS, now built on CodeIgniter, that allows for endless extension through the use of modules, plugins, and accessories. However, when I needed to create a simple web service that would consume an XML post and update the ExpressionEngine database, I found myself in limbo—that is—not needing the control of a module, but needing more control than that offered by an accessory. Sure, I could have created a PHP script that ran separate from ExpressionEngine and CodeIgniter, pulled in the database configuration file, and updated the database as needed. But, interacting with the ExpressionEngine database directly is dangerous and—in my case—unnecessary.

The idea here is to have the power of the CodeIgniter libraries and make use of the ExpressionEngine API. Choosing this method will prevent model redundancies and make for a much smoother upgrade day.

Configuring ExpressionEngine

In a normal CodeIgniter installation, you access your controller methods through the /controller/method URI structure. Since ExpressionEngine uses a /template_group/template structure, an out-of-the-box ExpressionEngine 2.0 installation disables CodeIgniter’s default URI routing feature, sending everything to the ee controller in the application folder. In order to create our custom controllers, we’ll need to remove this override. This will change how our ExpressionEngine install renders our site in this way:

  • Upon an incoming request, CodeIgniter will check for code to execute based on the standard CodeIgniter /controller/method URI scheme. If the URI your using corresponds to a custom /controller/method, CodeIgniter will execute that code.
  • If a custom controller/method is not found, CodeIgniter will route the request to the default controller. This will be the normal “ee” controller that will load your ExpressionEngine templates as usual.

To remove the URI routing override, open up your front-end index.php file and comment out the Disable all routing lines beginning at around line 93:

// $routing[‘directory’] = ‘’;
// $routing[‘controller’] = ‘ee’;
// $routing[‘function’] = ‘index’;



One quick note: if you’re like me, you don’t like to edit any ExpressionEngine core files. However, you generally do not overwrite the front-end index.php file in an ExpressionEngine latest-build update so I don’t have any problem making small edits to the index.php file. In fact, I recommend it in an article I wrote about server-side optimization. See the ExpressionEngine 2.0 upgrade instructions for more information.

Creating your Custom Controllers

Now, we’re ready to begin creating our custom CodeIgniter controllers. Create your new controller (in this case, test_controller.php) in the /system/expressionengine/controllers/ directory. The only caveat is that since CodeIgniter runs our controllers before the ExpressionEngine libraries are initialized, we’ll need to initialize those and get an instance to the ExpressionEngine global object. Here is what your barebones controller should look like:

<?php

if (! defined(‘BASEPATH’)) exit(‘No direct script access’);

class Test_controller extends Controller {

/**
* Contsruct
*/

function __construct() {

parent::Controller();

// Initialize ExpressionEngine objects
$this->core->_initialize_core();
$this->EE =& get_instance();

}

/**
* Index function
* @return void
*/

function index() {

}

}


Note the 2 lines in the class construct dealing with ExpressionEngine initialization. You’ll need to have these lines in each of your custom controllers. You should now have access to all the ExpressionEngine libraries as documented in the ExpressionEngine development docs.

So what?

If you’re building something that requires an ExpressionEngine backend or user-configurable parameters, you should probably build an ExpressionEngine module. However, there are times when a full-fledged module is not appropriate and rather than pulling in ExpressionEngine configuration files and building it aside from ExpressionEngine and CodeIgniter, it makes sense to make use of those libraries that are available to you. In the end, it saves coding time, and makes for a less nerve-racking upgrade day.

Has this article helped you or do you see a typo? If so, leave a comment and let me know!




Comments have been disabled for this entry.