Part 3. Decoupling the Configuration.

Before going any further we should address something that we will be using more as we move forward. Configuration.

Machine-specific configurations and credentials should never be stored in your version control repository. They should be kept on the machine and accessed by your application on deployment or runtime. Keeping them in version control history only creates security vulnerabilities. The last thing we want is for someone to look at our GIT history after checking out the code and find server configuration details or database credentials.

These values could be set in other ways. Such as editing .htaccess or Apache/Nginx config and virtualhost files. This can be cumbersome at best and sometimes not possible at all. It may not be allowed by your hosting provider, or you may be running your code via the command-line interface.

More detailed information on dealing with configurations along with other best practices can be found on The Twelve Factor App website.

We are going to keep them in a file on the server and pull them in using a package called phpdotenv. This package takes the contents of a file and adds them to the $_ENV. They can then be accessed with getenv(), $_ENV and $_SERVER automagically.

Let’s install the package using composer.

$ composer require vlucas/phpdotenv

Now let’s open up our bootstrap.php file and utilize this package. We’ll the following code just after the setting of our App namespace so that our configurations load into the environment as early as possible. Using this package is as easy as passing the environments file to the constructor and then calling load().

// Load Environment file
$dotEnv = new \Dotenv\Dotenv(APP_ROOT.'/configuration/environments','environments.env');
$dotEnv->load();

We now need to create the file and put something in it.

At the beginning of this series, we created a file called environment.env.example. We will use this as a template to build the actual file from, all our environment keys will be defined here with fake values. At setup, the end-user can copy this file and enter the correct values for the machine.

Let’s start with the displayErrorDetails key in our configuration. This is a value that should never be true in a production environment. So let’s add that to our example file with the value of false. We’ll then create the actual .env file and set the value to true.

APP_ENV="production"
DEBUG_DETAIL=false

I also like having an entry to specify the name of the environment. This can be used later for turning special debugging, among other things, on and off.

Let’s add our actual environment.env with the development values. Be sure to add an entry to your version control system’s .ignore file to filter out all .env files. We don’t want them to accidentally get committed to your version history. Using GIT you would add the following line to your .gitignore file.

/configuration/environments/*.env

Now back to our environment.env file. Add these values to it for now.

APP_ENV="dev"
DEBUG_DETAIL=true

We will now have our own environment files added the next time we run our application. Because we called the environment loader before the config loader, we can now use these values in our settings file. Like so.

'displayErrorDetails' => ('true' === getenv('DEBUG_DETAIL')),

We should once again be able to run our application in the browser and see the Slim Welcome page.

Finished.

Debugging can now be turned on and off dynamically based on server configuration. Later we’ll add other machine-specific things such as database credentials and 3rd party service authorizations. We could also add non-sensitive things that change per machine. Such as cache directories, log directories, or log and error levels. The possibilities are limitless.

Code.

See the final code for this article on github. 003 Decoupling the Configuration