Magento 2.2 introduced a new feature regarding configuration values. Usually, configuration values are stored in the database and defined in the Magento admin area.
However, setting the configuration with code has one huge advantage:
Code can be stored in the versioning system (i.e. Git) and thus be transferred to other instances of the store.
If used correctly, all instances will have the same configuration settings. That is especially important for technical settings like:
- Activating “Flat Catalog”
- Defining payment methods and shipping methods
- Customer settings like which fields should be shown
This could have been done by setup scripts before, but there was no guarantee that the settings wouldn’t be overwritten again. Also, there was the possibility of conflicts when switching branches.
Now, there is a much easier and more reliable method:
Settings can be stored in the configuration files app/etc/env.php and app/etc/config.php
Those files are automatically created during installation of Magento 2 and contain information about the database connection and the installed modules among other things.
Local settings
For settings like the base url or development settings, it makes sense to store them in a local file so they don’t get overwritten by a database import from another instance. These settings are stored in the app/etc/env.php file which is system specific and won’t be shared among instances.
To add a setting to that file, you would usually use the command line as follows:
|
1 |
bin/magento config:set --lock <path> <value> |
The path is the same as you find in the database table core_config_data . An example is:
|
1 |
bin/magento config:set --lock general/store_information/name integer_net |
This command automatically adjusts the app/etc/env.php file as follows:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
[...] 'cache_types' => array ( 'config' => 1, [...] ), 'install' => array ( 'date' => 'Wed, 08 Nov 2017 11:52:21 +0000', ), 'system' => array ( 'default' => array ( 'general' => array ( 'store_information' => array ( 'name' => 'integer_net', ), ), ), ), ); |
In the Magento admin, it then looks like this:
Do you notice how the field is shown greyed out?
Settings from the configuration files cannot be overwritten.
And that makes perfect sense – no developer will ever have to worry about some crucial configuration settings being overwritten.
Don’t forget the --lock switch – otherwise the setting is just written to the database which has the same effect as if you’d do it in the admin area. You can find more details about the config:set command in the Developer Documentation.
Shared Settings
In most cases, configuration settings should be shared among all development, staging and live instances of a shop. To achieve this, you can use the same mechanism as with the local settings described above.
The only difference is that the configuration values will be stored in app/etc/config.php. This file should usually be included in the VCS and thus shared between instances.
To store a config setting in the file via command line, the command would be as follows:
|
1 |
bin/magento config:set --lock-config <path> <value> |
The only problem here is that the switch is only implemented in Magento since 2.2.4.. The workaround is to either create that part of the config.php manually, or use the --lock switch and cut/paste the generated code from env.php to config.php.
A Pull Request
To add the --lock-config switch, I have created a Pull Request to the Magento 2 repository. It’s merged into the core code now, and released with Magento 2.2.4.
Wrapping it up
- Configuration settings can be stored in configuration files since Magento 2.2
- Those settings cannot be overwritten in the admin area
- Use app/etc/env.php for system specific configuration
- Use app/etc/config.php for shared configuration
- Always include app/etc/config.php into your VCS (like Git), don’t include app/etc/env.php
- The system specific configuration can be set via command line, the shared configuration too, but only starting from Magento 2.2.4.
- To easier find out the path of a certain configuration setting, you can use the ScopeHint module which shows the path in the admin area.
Outlook
This is one of two new methods to lock and share your configuration values. The other method allows you to write all your configuration values to the files mentioned before:
|
1 |
bin/magento app:config:dump |
I will possibly analyze that method in a future blog post. Meanwhile, you can look it up in the Developer Documentation.
Author: Andreas von Studnitz
Andreas von Studnitz is a Magento developer and CEO of integer_net. His main areas of interest are interface development, backend development, Magento consulting and giving developer trainings. He is a Magento Certified Developer since 2011 and a Magento Certified Solution Specialist since 2014.
if only they wrote code that didnt require such a pain in the ass process… what the hell are they thinking…?
i mean… do they really think that my clients are going to be happy when i tell them they will need a developer to spend time changing an admin config value? And am i supposed to memorize all these admin config paths or am i supposed to just inspect element from my browser and look at the form name? come on magento… learned nothing from magento 1…
I think you are mistaken – it’s not required to do it this way, it’s just one more way to do so. And it’s very convenient for developers in my opinion.
You can still go to the admin area and set the configuration values in the browser, without knowing those config paths.
The values are locked once written to the config file aren’t they?
The values are locked after config:dump. At least in Mage version 2.3.4. This is very annoying for development process while sharing config setting in dev team. There is an alternative, but still not 100% solution in my opinion. Take a look at this thread:
https://magento.stackexchange.com/questions/196912/appconfigdump-locks-everything-in-configuration#answer-202826
I don’t like config:dump at all because it does too much. If you use it, you should cut out big parts. I prefer setting only crucial settings via code.
Thanks for this article, Andreas! This is definitively going be part of our deployment process.