Config

#Site Config The main config file can be found in the application/config directory called site_config.php. There are many ways you can edit the info in here, and many ways to store it as well.

The most standard approach is to leave the site_config.php file in this directory and work off of it, changing the values for your local/dev environment, and your production environment. You can also, if you wanted to, have multiple config files for each environment that you have by adding a directory in the application/config folder. For example if I have 2 environments, development and production, and I wanted different config files for both I would create 2 directories in application/config. For my development I would have application/config/development/site_config.php and application/config/production/site_config.php. Doing it this way ensures that you never accidentally leave a setting turned on or off in production. This method is true for every file in the config directory, of course if you do choose to do it this way you must ensure you have set your ENVIRONMENT definition correctly in public/index.php.

#Properties Now let's move on to the nitty gritty of the site_config, the properties. Most all of the properties are commented in the config file so that you know which each of them does, we will just go over a few of the more important pieces of the config here.

###Database Rather than setting up an entire config file for the database config we have decided to include it here. The database config section can be quite large, you can store multiple database configs here, one for each environment, and then switch between which connections are "active". let's take a look at an example...

$config = array(
    'database' => array(
        'local' => array(
            'host' => 'localhost',
            'user' => 'rootuser',
            'password' => 'megapass',
            'db_name' => 'framework_db',
            //...and the rest of the settings for this connection
        ),
        'production' => array(
            'host' => 'http://godaddy.com/mydatabase', //whatever your server info is
            'user' => 'database_user',
            //... and so on
        ),
        'active' => 'local'
    ),
    //rest of config file
);

Now that setup there has all the information needed (obviously if you filled it all out) for both of your environments, yes you can have as many in there as you like, and the last line there "'active' => 'local'" tells the framework that it is going to use the database config called 'local'. This was you don't have to constantly be changing your database config when changing environments or pushing code to production. If you really want to never have to change anything including the 'active' line then you can use the method mentioned earlier where you have multiple config files under the application/config/{ENVIRONMENT} directory. One thing to keep in mind throughout this whole setup is if you do not want to write out your config as one solid array as shown above you can break it up in to smaller section like so...

$config = array();
$config['database'] = array();
$config['database']['local']['host'] = 'localhost';
$config['database']['local']['user'] = 'rootuser';
$config['database']['local']['password'] = 'megapass';
$config['database']['local']['db_name'] = 'framework_db';
//...and so on
$config['database']['active'] = 'local';

That is completely up to you, whichever method you like to see you can use.

###Debug Another important section of the config array is the debug options. OOF is setup with special debugging output, such that all non fatal errors are captured and sent to the debug area. The debug area is an area on your webpage that is below all other content on the page. For safety, and ease of usability, the debug section is split into different sections with each section representing an environment. So to look at an example...

$config = array(
    //a while bunch of stuff here
    'debug' => array(
        'production' => array(
            'show_debug' => false,
            'start_minimized' => false,
            'show_file' => false,
            'log_output' => true
        ),
        'development' => array(
            'show_debug' => true,
            'start_minimized' => true,
            'show_file' => true,
            'log_output' => false
        )
    ),
    //and the rest of the config
);

With the above structure you never have to worry about changing the settings when pushing to production or pulling into development, of course you can use the same structure noted above if you choose not to write out the config array as one solid nested array. So let's go over what those things mean. Obviously we can say that the "show_debug" one is going to be weather or not to show the debug output on the screen. The other ones aren't so self explanatory, so let's have a look at them. There is the 'start_minimized' one, this one is what you are thinking it is, weather or not to start the debug output minimized. The debug feature has 2 main views, the minimized view, which is just a nice little div that sits almost all the way off of the screen that you click and it gives you a quick idea of the error that occurred and it has a link to see the full output, and the full view which is a full breakdown of everything that happened. It has the full debug backtrace all laid out for you in a very readable way as well as the file, if you enabled the 3rd option there, 'show_file' with the error line highlighted so you can see exactly what went wrong and where. Feel free to play around with these options and see which you like better. I would recommend that this be turned off in production and instead you set it to log the errors by setting the fourth param up there 'log_output' to true. By default if in the logging section it is enabled it will automatically log errors to the log files or database, or both depending on what you set, but with the debug active for logging it will now also log all of the debug content as well.

###Return The return parameter in the config array is a special property that allows you to set the default return value when things do not happen as you would expect, this is mainly used with the config class. For example let's say you are trying to get a property of the config array that doesn't actually exist, because there are many, many, different ways the system could return the fact that there was nothing there programming for it becomes a little difficult. I'm sure we've all seen things in the PHP manual that makes no sense, you know when they say things like, This function may return false or something that evaluates to false, or may return nothing at all. Well that stuff bothers me to no end so I made this little param so that you can decide what it will return when the property isn't there. A quick example...

class Product extends TableObject {
    
    public $id;
    // and so on
    public function after_construct() {
        $this->can_log = $this->config->item('logging', 'enable');
    }
    //and the rest of the class
}

Given the above example, what would happen if the system returned something other than false, well your logger would be happening even if it shouldn't be. So by setting 'return' => 'false' in the config you can be sure that if you call to the config for an item, and it isn't there, you will get false back.