Working With Configuration Files

    You can access config files within your classes by creating a new instance or using the config function. All of the propertiesare public, so you access the settings like any other property:

    If no namespace is provided, it will look for the files in all available namespaces that havebeen defined, as well as /app/Config/. All of the configuration filesthat ship with CodeIgniter are namespaced with . Using this namespace in yourapplication will provide the best performance since it knows exactly what directory to find thefiles in and doesn’t have to scan several locations in the filesystem to get there.

    You can locate the configuration files any place on your server by using a different namespace.This allows you to pull configuration files on the production server to a folder that is not inthe web-accessible space at all, while keeping it under /app for ease of access during development.

    Creating Configuration Files

    If you need to create a new configuration file you would create a new file at your desired location,/app/Config by default. Then create the class and fill it with public properties thatrepresent your settings:

    1. <?php namespace Config;
    2.  
    3. use CodeIgniter\Config\BaseConfig;
    4.  
    5. class App extends BaseConfig
    6. {
    7.     public $siteName  = 'My Great Site';
    8.  
    9. }

    The class should extend \CodeIgniter\Config\BaseConfig to ensure that it can receive environment-specificsettings.

    Because your site can operate within multiple environments, such as the developer’s local machine orthe server used for the production site, you can modify your values based on the environment. Within theseyou will have settings that might change depending on the server it’s running on. This can includedatabase settings, API credentials, and other settings that will vary between deploys.

    You can store values in a .env file in the root directory, alongside the system and application directories.It is simply a collection of name/value pairs separated by an equal sign, much like a “.ini” file:

    1. S3_BUCKET="dotenv"
    2. SECRET_KEY="super_secret_key"

    If the variable exists in the environment already, it will NOT be overwritten.

    Important

    You are encouraged to create a template file, like env.example, that has all of the variables your projectneeds with empty or dummy data. In each environment, you can then copy the file to .env and fill in theappropriate data.

    When your application runs, this file will be automatically loaded and the variables will be put intothe environment. This will work in any environment. These variables are then available through getenv(),, and $_ENV. Of the three, getenv() function is recommended since it is not case-sensitive:

    1. $s3_bucket = getenv('S3_BUCKET');
    2. $s3_bucket = $_ENV['S3_BUCKET'];
    3. $s3_bucket = $_SERVER['S3_BUCKET'];

    Note

    If you are using Apache, then the CI_ENVIRONMENT can be set at the top of, which comes with a commented line to do that. Change theenvironment setting to the one you want to use, and uncomment that line.

    Nesting Variables

    To save on typing, you can reuse variables that you’ve already specified in the file by wrapping thevariable name within ${…}:

    There will be times when you will have several variables with the same name. When this happens, thesystem has no way of knowing what the correct value should be. You can protect against this by“namespacing” the variables.

    Namespaced variables use a dot notation to qualify variable names when those variablesget incorporated into configuration files. This is done by including a distinguishingprefix, followed by a dot (.), and then the variable name itself:

    1. // not namespaced variables
    2. name = "George"
    3. db=my_db
    4.  
    5. // namespaced variables
    6. address.city = "Berlin"
    7. address.country = "Germany"
    8. frontend.db = sales
    9. backend.db = admin
    10. BackEnd.db = admin

    Incorporating Environment Variables Into a Configuration

    When you instantiate a configuration file, any namespaced environment variablesare considered for merging into the configuration objects’ properties.

    If the prefix of a namespaced variable matches the configuration class name exactly,case-sensitive, then the trailing part of the variable name (after the dot) istreated as a configuration property name. If it matches an existing configurationproperty, the environment variable’s value will override the corresponding onein the configuration file. If there is no match, the configuration properties are left unchanged.

    A namespaced environment variable can be further treated as an array.If the prefix matches the configuration class, then the remainder of theenvironment variable name is treated as an array reference if it alsocontains a dot:

    1. // regular namespaced variable
    2. SimpleConfig.name = George
    3.  
    4. // array namespaced variables
    5. SimpleConfig.address.city = "Berlin"
    6. SimpleConfig.address.country = "Germany"

    If this was referring to a SimpleConfig configuration object, the above example would be treated as:

    1. $address['country'] = "Germany";

    Any other elements of the $address property would be unchanged.

    You can also use the array property name as a prefix. If the environment fileheld instead:

    then the result would be the same as above.

    Registrars

    A configuration file can also specify any number of “registrars”, which are anyother classes which might provide additional configuration properties.This is done by adding a property to your configuration file,holding an array of the names of candidate registrars.:

    1. protected $registrars = [
    2.     SupportingPackageRegistrar::class
    3. ];

    In order to act as a “registrar” the classes so identified must have astatic function named the same as the configuration class, and it should return an associativearray of property settings.

    When your configuration object is instantiated, it will loop over thedesignated classes in $registrars. For each of these classes, which contains a method name matchingthe configuration class, it will invoke that method, and incorporate any returned propertiesthe same way as described for namespaced variables.

    A sample configuration class setup for this:

    1. <?php namespace App\Config;
    2.  
    3. use CodeIgniter\Config\BaseConfig;
    4.  
    5. class MySalesConfig extends BaseConfig
    6. {
    7.     public $target        = 100;
    8.     public $campaign      = "Winter Wonderland";
    9.     protected $registrars = [
    10.         '\App\Models\RegionalSales';
    11.     ];
    12. }
    1. <?php namespace App\Models;
    2.  
    3. class RegionalSales
    4. {
    5.     public static function MySalesConfig()
    6.     {
    7.         return ['target' => 45, 'actual' => 72];
    8. }

    With the above example, when MySalesConfig is instantiated, it will end up withthe two properties declared, but the value of the $target property will be over-riddenby treating RegionalSalesModel as a “registrar”. The resulting configuration properties: