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.
Config
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.
config.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).
autoload.php
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.
database.php
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.
routes.php
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.
program.php
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.
Related posts:
- Building Applications using CodeIgniter (Part 3) – Helpers
- Building Applications using CodeIgniter (Part 1) – File Structure
- Building Applications using CodeIgniter (Part 4) – Code Templates
- 10 Reasons Why CodeIgniter Rocks
- Generating PDF files using CodeIgniter
If you enjoyed this post, please consider to leave a comment or subscribe to the feed and get future articles delivered to your feed reader.
Good post!!! I am a CI newbie and i just loved this post.Nicely done with a clean explanation of things.
Nice post Chris
About the program.php… to interract with variables of this custom config file you can call them like the base_url() of the std config file?
Vassi, since this config file is auto loaded and includes the CI global $config array I can access the variables using the $this->config->item() function. That’s typically how I access the variables in that file.
Hi again chris
In my current webapp i need to use a custom config file for storing some settings data, but i don’t know how can i change the variable value in that file…
In my admin panel i have a settings page where the admin can change the app settings like app_name and some other stuff. How can i access that config file to change variables value?
Hey Vassi, to be honest I would handle this differently. For all the application settings that I allow users to modify within the program I use a database. So I typically have a table called settings, or perhaps you can store the settings along with the account info. in an account table. But I store those settings in the DB as columns and then simply use an update query when the user wants/needs to update them. Even if I’m dealing with an application that doesn’t have any user settings, I typically still have a table just with one record. Some say that’s overkill but I much prefer working with databases than flat files.
Using a custom CI config file for this is certainly possible but I wouldn’t recommend it. You would first have to set the file permissions on that file to 777 so you can write to it. Then, upon submit, you would have to either append to the end or rewrite that config file completely with the new settings that your user has selected. So upon update, you would have to rewrite that config file with the new $config[] array and it’s values. I actually believe EE 2.0 uses this method for certain config settings within the program, but I much prefer the DB approach to working with flat files.
Hope that helps.
Thanks for quick answer
This settings_page is general settings not user settings for that reason i thought that is better use a config file… I already use db in this project and firstly i thought use a db table, but it would be a table with 1 record only and i don’t thinks is the best way… anyway probably with config file i should loose more time, so thanks for your message i chose the db way