Environment Specific Variables/Config
Sometimes you might want to store information that won't change for your site at an environment level (production / development). For example you're working on a site, and want to integrate a third party system like Stripe, which gives you a set of test and live keys to work with their system. You could obviously create a package and administer this in the dashboard area, alternatively you could create some environment specific variales.
This example is based off of the information in the tutorial: Loading Configuration Based On Host and Environment which will show you how to create different environments for your site.
You can either modify your vhost file
<VirtualHost *:80> ServerName your.local.addr DocumentRoot "/www/concrete5_installation" # Define c5 environment SetEnv CONCRETE5_ENV development/local </VirtualHost>
Or you can modify your .htaccess file
# At the top of the .htaccess file SetEnv CONCRETE5_ENV development/local
Note the use of a hierarchical folder structure of development/local as this will allow you to group manual overides together, rather than the files sitting loose in the application/config. Concrete5 will automatically add a period (.) between the end of your environment name and the name fo the file that you want to override. E.g. development/local.concrete.php
You have the ability to have a core override of a config key/value file by having it sit in /application/config/filename.php, so now we have the option of having up to four files for each config file (in this example anyway):
1. /application/config/development/local.concrete.php 2. /application/config/concrete.php 3. /application/config/generated_overrides/concrete.php 4. /concrete/config/concrete.php
Note the order of these files. This is the order of preference from the system. It will first look to see if there is an environment level config file, then it will check for a root level file, then a generated overrides level, before finally defaulting to the concrete config. Utilising our Stripe example with having two sets of keys (test/live), we want our test data to be stored in the /application/config/development/local.concrete.php file.
<?php return array( 'stripe' => [ 'public' => 'pk_test_1234567890abcdefghijklmn', 'secret' => 'sk_test_1234567890abcdefghijklmn' ], );
Our live data will be store in the /application/config/concrete.php file. In this example no environment is implying the live production server.
<?php return array( 'stripe' => [ 'public' => 'pk_live_0987654321qwertyuiopasdf', 'secret' => 'sk_live_0987654321qwertyuiopasdf' ], );
So now, our development site will grab the /application/config/development/local.concrete.php file and use the keys from there, and the live site will grab the /application/config/concrete.php file.
It is worth noting, that these won't be modified by using the Config::save command, as that would affect the generated_overrides specific file, and this should only be done for constants that won't need to be changed.