Step 5 – Final settings. Finishing the configuration of your CodeIgniter

(created at: November 15, 2014; last update: February 18, 2016)

Before we get going with our development of the app, we should make sure we have finished setting up the CodeIgniter.

First of all, let’s make sure we have a default time zone for the PHP scripts to run smoothly.

In our index.php, just after the opening of the php tag, we set the time-zone like so:


Of course, you can set it to whatever timezone you are in. Here you have a list with the supported timezones

Some people said that setting the timezone would increase computational speed for date/time functions. I don’t know if that’s true, but at least we can make sure the app knows for what timezone is working… 😛

Now, let’s move on to the configuration file. As we are working in the development environment, we will find the config.php inside application/config/development directory.

Changing the language

English, the new lingua franca (as in… is not french anymore). Of course, the english may be an important language, but if you are creating a site for people that don’t speak english, you might as well go and find the line:

$config['language'] = 'english';

… and change it to your application’s language:

$config['language'] = 'romanian';

Now, if you do this, you must have your language files ready. If you don’t have the language files, you can at any time translate the files from english into your language, by following these steps:

1. Create a directory having as name your language name inside application/language (in my case, romanian). The folder structure would look like this:

- -development
- - -autoload.php
- - -config.php
- - -database.php
- - -routes.php
- -production
- -testing
- -romanian

2. Go into the directory system/language/english and copy all the files that are there.

3. Paste those files inside application/language/romanian (or whatever your language name is).

4. Start translating every file you find in there taking care to keep unchanged the variables that are kept inside the {} curly braces.

Now you would have a directory structure as below:

- -development
- - -autoload.php
- - -config.php
- - -database.php
- - -routes.php
- -production
- -testing
- -romanian
- - -calendar_lang.php
- - -date_lang.php
- - -email_lang.php
- - -form_validation_lang.php
- - -ftp_lang.php
- - -imglib_lang.php
- - -index.html
- - -migration_lang.php
- - -number_lang.php
- - -pagination_lang.php
- - -profiler_lang.php
- - -unit_test_lang.php
- - -upload_lang.php

Composer integration

Now, in version 3 of CodeIgniter, you can use composer to install new packages (of course, you can also use Composer with the version 2 of CodeIgniter). In the config.php, which can be found in application/config/development, you can find a line that will tell the CodeIgniter if it should look for a Composer package auto-loader script in application/vendor/autoload.php. If you plan to keep the default settings, all you will have to do is change $config[‘composer_autoload’] to TRUE.

$config['composer_autoload'] = TRUE;

For Composer integration, please view the next step…

Sessions, cookies, security…

Sessions, cookies and security is something an application always needs, considering the fact that the internet is a real jungle full of dangers from all sides.


Also, if you think you will use the Encryption class, you must set an encryption key.

The encryption key must be a random string of 32 characters. If you can’t think of any random string of 32 characters, google to the rescue. Do a search for codeigniter encryption key generator, and you might find some sites that can propose you some keys. I found two, which look good:

Now, copy the random string and put it as value to the $config[‘encryption_key’].

Preventing XSS

I don’t know about you, but I always used to set the $config[‘global_xss_filtering’] to TRUE. This seem to be a bad practice, as the xss filtering should only be made on output, and not on the input. So, if you are smart, you should disable the global_xss_filtering, and only use the XSS filtering only before you output to the browser something that comes from your users.

Cross Site Request Forgery

Putting it simply, anyone can create a form on a different site than yours and send the POST data to your application. To protect you from this to happen, you can at any time create a hidden field that will keep a token (a random string that is unique). That token will also be registered in session data of your visitor so that when a submit of your form happens, the two tokens will be compared to verify if the form was submited from your site.

So, let’s change a few lines inside the config.php:

$config['csrf_protection'] = TRUE;
$config['csrf_token_name'] = 'csrf_sitecom_token';
$config['csrf_cookie_name'] = 'csrf_sitecom_cookie';
$config['csrf_expire'] = 7200;
$config['csrf_regenerate'] = TRUE;
$config['csrf_exclude_uris'] = array();

As you can see, with $config[‘csrf_exclude_uris’] you can exclude some URIs from using CSRF token.

And that’s it with the config.php. I sure hope I didn’t forget something.

Make cache and logs directories writable

Make sure the cache and logs directories, which can be found inside application directory, are writable.


  1. Great infos Avenir, about global_xss_filtering I read in the config file that This feature is DEPRECATED and currently available only for backwards compatibility purposes. Is there any replace for this feature? Thanks

    1. Hello, you misunderstood. We are not talking about the xss filtering that is deprecated. It’s the global xss filtering that is discouraged. You can still use xss filtering on your output. The thing is that the global xss filtering started from a misunderstanding regarding the security in PHP. You don’t have to clean every data that comes in contact with your application. You only have to clean the data that is outputed by the application, and only validate/filter data that is inputed. Keep in mind the mantra: “Filter input, clean(sanitize) output”.

    1. Hello, somewhere between the beta and the realeas of CI3, the developers decided to give up on that composer. But you can still install your composer. Just follow the next step.

  2. The section “Sessions, cookies, security…” , about the encryption key generation is old. The official user guide of the final CodeIgniter 3.0 release on this topic is quite different.

  3. Is the part about setting the timezone in the bootstrap file still relevant in CI3?

    I found this in the config.php

    | Master Time Reference
    | Options are ‘local’ or any PHP supported timezone. This preference tells
    | the system whether to use your server’s local time as the master ‘now’
    | reference, or convert it to the configured one timezone. See the ‘date
    | helper’ page of the user guide for information regarding date handling.
    $config[‘time_reference’] = ‘local’;

  4. In the sub chapter, changing the language, is there a preferred way to handle the user switching the codeigniter core language?

    I guess it’s just a matter of making a Switch_lang_model and setting $config[‘language’] = post($switch_lang)’;

      1. Ah, ok thanks. This is literally my second tutorial (the first was on the CI site) so thanks for your patience. I really should google more so not to bother you too much.

Leave a Reply

Your email address will not be published. Required fields are marked *

No spam? * Time limit is exhausted. Please reload CAPTCHA.