Building Applications using CodeIgniter (Part 2) - Configuration

The framework that you use to build your application will end up being the foundation of your program. Everything that your program does will revolve around how that framework works. Things like naming conventions, file paths and settings are dictated by the framework. But if you have chosen a good framework, like CodeIgniter (CI), you will be able to manipulate how that framework works and the tools it makes available to you by modifying it’s configuration information. In the first post I talked about application file structure. Now that the structure is solid I’m going to look at how I configure the framework so that it works the way I expect.


All of CI’s configuration files are stored in application/config.

  • config
    • autoload.php
    • config.php
    • constants.php
    • database.php
    • doctypes.php
    • hooks.php
    • mimes.php
    • routes.php
    • smileys.php
    • user_agents.php

The purpose of each file coincides with it’s name. To get us up and running we are only going to worry about autoload.php, config.php, database.php and routes.php.


The config.php file is the main configuration file for the framework. In this file you can control things like logging, character sets, extension prefixs, etc. The folks over at EllisLab have done a great job at commenting this file so I’m not going to go through the whole thing. The only thing I’m going to change here are lines 14 and 26.

Line 14 holds the full web path to your CI installation. In the past I used to type this in by hand until I had the need to write portable apps that could be distributed and installed without much configuration on the users end. Since then I have resorted to using this code I found on the CI wiki. By replacing line 14 with that code you can set this variable and forget about it. Wherever your program ends up this config variable will be set automatically so you don’t have to worry about it.

Line 26 of the config file holds the name of the index file. Since I use search engine friendly URLs where ever possible I just delete the value and leave it blank (just like the comment tells you to do).


Now that the config.php file is taken care of we turn our attention to the tools we need to build out app. What libraries, models, helpers, etc. are we going to need on a regular basis throughout the entire app? The answer to this question will probably differ based on what app your building, but I have found there are a number of common files I always load throughout any application:

Libraries - database, session

Helper - form, url, display, flash

Config - program

The libraries above, database and session, are the default CI libraries to handle database abstraction and user sessions (note, if your app doesn’t use a database consistently throughout the whole app you might not want to autoload this library). The form and url helpers are both default CI helpers but display and flash are two custom helper files I’ve developed to assist with some common tasks. I will discuss helpers in the next post. Finally, program is a custom config file that I create for all my applications which I will discuss shortly.


If you are app is interacting with a database then you need to update the database.php config file. This file stores the access information for the database or databases that your app will be interacting with. This file is pretty self-explanitory so I’m wont go to delve into it.


The routes.php file allows you to define custom URLs and map them to specfic controllers and methods. This is a very powerful tool that comes built into the CI framework. The only thing we want to update in this file to get started is line 43. Right now it’s set for the default welcome message we saw before. I usually set this variable to home just because it’s pretty generic and tends to work well in URLs but you can set it to whatever makes sense to you and your app.


Now that I’ve discussed all the default CI files, I’m going to create a custom config file called program.php (the same one we auto-loaded above) and place it in the config folder. This file will store all the application wide configuration settings and information that I will be referring to both programmtically and manually. To see what this file looks like you can dowload an example for reference.

At the very least this file will always have 2 variables: ci_version and program_version. Both are pretty straight forward in purpose, ci_version stores the current version of CI that I’ve used to build the app and program_version is the current version of my app. I’ll typically call upon the program_version and display it in the footer of the app and knowing the version of CI running comes in handy when updating or making any framework modifications.

When building an app of any size you always want to build in a quick and easy way of taking the app offline. I accomplish this with the status variable. If the status is true then the program is online and everything is operational but if it’s false then things are offline. By creating a config variable for this I can easily refer to this flag throughout the program to determine whether or not input should be accepted and processed.

Another thing I commonly store in the program config file is e-mail settings that will be used whenever an e-mail is sent from the app. This commonly consists of the from and reply-to address and names. Again, by storing this information here it’s easily accessed whenever sending an e-mail.

Your program config file can store any type of system wide configuration information that your app will need to reference from many places. You could theoretically store this configuration information in a database but then you wouldn’t be able to take advantage of the native CI config tools available. In the end it’s up to you.

Next up: Helpers

That wraps up configuration. In the next post I will review some custom helper files I’ve developed and autoload in most of my applications.