Working With Configuration Files

Every application needs a way to define various settings that affect the application.These are handled through configuration files. Configuration files simplyhold a class that contains its settings as public properties. Unlike in many other frameworks,there is no single class that you need to use to access your settings. Instead, you simplycreate an instance of the class and all your settings are there for you.

Accessing Config 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:

  1. // Creating new class by hand
  2. $config = new \Config\Pager();
  3.  
  4. // Creating new class with config function
  5. $config = config( 'Pager', false );
  6.  
  7. // Get shared instance with config function
  8. $config = config( 'Pager' );
  9.  
  10. // Access config class with namespace
  11. $config = config( 'Config\\Pager' );
  12.  
  13. // Access settings as class properties
  14. $pageSize = $config->perPage;

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 Config. 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.     public $siteEmail = 'webmaster@example.com';
  9.  
  10. }

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

Handling Different Environments

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

Make sure the .env file is added to .gitignore (or your version control system’s equivalent)so it is not checked in the code. Failure to do so could result in sensitive credentials being stored in therepository for anyone to find.

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(),$_SERVER, 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 ofpublic/.htaccess, 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 ${…}:

  1. BASE_DIR="/var/webroot/project-root"
  2. CACHE_DIR="${BASE_DIR}/cache"
  3. TMP_DIR="${BASE_DIR}/tmp"

Namespaced Variables

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.

The same holds for a “short prefix”, which is the name given to the case when theenvironment variable prefix matches the configuration class name converted to lower case.

Treating Environment Variables as Arrays

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['city']    = "Berlin";
  2. $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:

  1. // array namespaced variables
  2. SimpleConfig.address.city = "Berlin"
  3. address.country = "Germany"

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 registrars 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. }

… and the associated regional sales model might look like:

  1. <?php namespace App\Models;
  2.  
  3. class RegionalSales
  4. {
  5.     public static function MySalesConfig()
  6.     {
  7.         return ['target' => 45, 'actual' => 72];
  8.     }
  9. }

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:

  1. $target   = 45;
  2. $campaign = "Winter Wonderland";