Environment Specific Variables
Permalink 1 user found helpful
So I was in a situation recently that I wanted to have some variables for my site at an environment level basis. In this situation, it was for Stripe test and live credentials, stuff that won't be changing and that I didn't need to be stored in the system in the dashboard etc. I would generally use a define for this in older versions of concrete.
Starting with the information here;https://documentation.concrete5.org/tutorials/loading-configuration-... on how to set up an environment variable for my dev server I modified my .htaccess file as follows:
I've diverged here by adding in a folder syntax, this allows me to group any manual overrides I want together in a folder, however, the system wants to add a dot between your environment name and the name of the file you're overriding, so I added local on there too.
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 with this in mind, we now have the option of having up to four files for each config file (in this example anyway):
(using concrete.php as an example here)
1 - /concrete/config/concrete.php
2 - /application/config/generated_overrides/concrete.php
3 - /application/config/concrete.php
4 - /application/config/development/local.concrete.php
The order of preference on these is reversed, so the first file that will be looked at is your environment file, then your application root, then your generated override, and finally the base install file. So 4, 3, 2, 1.
So in my need for Stripe keys to be environment specific:
/application/config/development/local.concrete.php has:
/application/config/concrete.php has:
My development site will now grab the /application/config/development/local.concrete.php file and use the keys from there, and my 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.
I'm not sure if this will be useful for anyone, but I couldn't find anything on this, and needed to be able to do this!
Adz.
Starting with the information here;https://documentation.concrete5.org/tutorials/loading-configuration-... on how to set up an environment variable for my dev server I modified my .htaccess file as follows:
SetEnv CONCRETE5_ENV development/local
I've diverged here by adding in a folder syntax, this allows me to group any manual overrides I want together in a folder, however, the system wants to add a dot between your environment name and the name of the file you're overriding, so I added local on there too.
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 with this in mind, we now have the option of having up to four files for each config file (in this example anyway):
(using concrete.php as an example here)
1 - /concrete/config/concrete.php
2 - /application/config/generated_overrides/concrete.php
3 - /application/config/concrete.php
4 - /application/config/development/local.concrete.php
The order of preference on these is reversed, so the first file that will be looked at is your environment file, then your application root, then your generated override, and finally the base install file. So 4, 3, 2, 1.
So in my need for Stripe keys to be environment specific:
/application/config/development/local.concrete.php has:
return array( 'stripe' => [ 'public' => 'pk_test_1234567890abcdefghijklmn', 'secret' => 'sk_test_1234567890abcdefghijklmn' ], );
/application/config/concrete.php has:
return array( 'stripe' => [ 'public' => 'pk_live_0987654321qwertyuiopasdf', 'secret' => 'sk_live_0987654321qwertyuiopasdf' ], );
My development site will now grab the /application/config/development/local.concrete.php file and use the keys from there, and my 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.
I'm not sure if this will be useful for anyone, but I couldn't find anything on this, and needed to be able to do this!
Adz.
I learned something today. Thanks!