Common CodeIgniter Configuration Tasks

Common CodeIgniter Configuration Tasks

Lately I’ve been learning and doing a lot of work with CodeIgniter. So far, I really like it, and it has lived up to its claim of being “a powerful PHP framework with a small footprint.”

After going through the process of setting up a few different website apps, I have found a handful of common tasks and changes that I make for just about every app. I’ve included these all below for convenience and easy reference.

Removing index.php from URL path

One of my annoyances with CodeIgniter is the fact that by default, the index.php file is included in the URLs (e.g. example.com/index.php/news/article/my_article). To me, this seems messy and unnecessary. Luckily, CodeIgniter provides instructions on removing the index.php file. For the sake of convenience, I have included the steps necessary to remove the index.php file below.

Set $config[‘index_path’] to blank value

In your application’s config.php file, there’s a config value for $config[‘index_page’], which is your index.php file. however, using mod_rewrite (below) to remove the page from the URL requires the value of this variable to be blank:

$config['index_page'] = '';

Use a .htaccess file with rewrite rules
RewriteEngine on
RewriteCond $1 !^(index\.php|public|robots\.txt)
RewriteRule ^(.*)$ index.php?/$1 [L]

It’s important to note that the code in the sample above might not work for all server configurations. Also, as seen in the RewriteCond above, make sure to exclude any assets/directories that you need to be publicly accessible. As an example, for my projects, I generally have a public directory that contains my CSS, JS, and image assets, so I always put public in the RewriteCond.

Move application and system directories

As noted in the CodeIgniter installation instructions, “For the best security, both the system and any application folders should be placed above web root so that they are not directly accessible via a browser.”

With this in mind, I always move these directories as specified. In the main index.php file, update $system_path and $application_folder values to point to new locations of application and system directories. CodeIgniter provides instructions for how to relocate these directories. For example:

$system_path = '../codeigniter/system';
$application_folder = '../codeigniter/applications/my-application';

Use autoload config file to load default systems

I find myself using the same libraries and helpers in almost every view of every project I work on. Rather than loading them in the individual controllers each and every time, I use the application’s autoload.php file to load these systems. For me, I tend to autoload the following:

$autoload['libraries'] = array('database');
$autoload['helper'] = array('form', 'html', 'url');

Setting up multiple environments

One of the first things that I needed to do was get a handle on setting up multiple environments for development, testing, and production. The CodeIgniter documentation has instructions for Handling Multiple Environments, which is fairly easy to set up. However, it involves defining the environment in the core index.php file rather than setting it more dynamically, like using the URL to help.

For me, I ended up with a solution where I replace the default environment definition from the main index.php file, and replace it with a switch statement that inspects the $_SERVER[‘HTTP_HOST’], and defines the environment accordingly. Here’s what that code looks like:

switch ($_SERVER['HTTP_HOST'])
{
    case 'someexampleurl.com':
    case 'www.someexampleurl.com':
        define('ENVIRONMENT', 'production');
        break;
    case 'staging.someexampleurl.com':
        define('ENVIRONMENT', 'testing');
        break;
    case 'localhost:8888':
    default:
        define('ENVIRONMENT', 'development');
        break;
}

In addition to defining the environment constant dynamically based on the URL, I also create environment-specific directories (as noted in the CodeIgniter documentation) in the application > config folder. Each environment-specific directory contains its own config.php, constants.php, and database.php file, where I can set variable values based on that specific environment, rather than in the main config versions of these files, as is the default. CodeIgniter will check for settings in the environment-specific folders first, and if it can’t find a setting for something, it will then look in the default configuration files. This is a very nice feature, and a great way to keep a project dynamic and easy to manage.

Inside of each environment-specific constants.php file, I define a constant named BASE_URL. For example:

define('BASE_URL', 'http://' . $_SERVER['HTTP_HOST'] . '/my-ci-website/');

Then, in the main config.php file (for DRY purposes), I update the base_url config value like so:

$config['base_url'] = BASE_URL;

Alternatively, if you don’t have any other constants to define, you could choose to not use an environment-specific constants.php file, and just set the $config[‘base_url’] directly in each environment-specific config.php file. That’s completely up to you and your project needs.

Other than the obvious benefit of having the environment be set dynamically, another nice thing about this setup is that the development directory files don’t need to be checked into source control if you’re working with multiple developers. Rather, you can set up a “template” file to include in source control, but then let individual developers set up their own config files for the development environment based on their own local computer setup.

Wrapping Up

There is a lot of configuration and setup that can be done with CodeIgniter, and doing the configuration tasks above is just a small (but important) part. But by setting up your applications like this, it will make your CodeIgniter development life much easier.

Until next time, happy coding!

There are no comments yet, add one below.

Leave a Comment