Magento 2 Configuration settings - Clarify app:config:dump vs app:config:import

Question

I just want to understand the workflow of Magento 2 configuration settings.

Intro

In Magento 2, there are these command-line commands: app:config:dump app:config:import

Questions

Am I correct in saying:

• app:config:dump is for importing from database into configuration file (app/etc/config.php).

• app:config:import is for importing from configuration file (app/etc/config.php) into the database.

• Assuming this is correct, would I only really use the configuration file when importing data into a new database from existing settings in a config.php file (ie run app:config:import once, then change everything I need in the admin backend instead of in config.php file (ie site specific styling etc).

• After I am done with everything (so last step), I run app:config:dump, to update the config.php file again?

• Somewhere along the way all my settings became locked in the M2 backend, I assume it is because I ran app:config:dump? (I figured out clearing specific entries from config.php json they will be editable again, and saved to database).

This workflow of locked configuration settings in backend is really inefficient so I decided to clear everything in config.php file (instead of the modules enable/disable) settings.

Can someone please clarify these for me please. Thanks

Answer 1

I have been fighting with the Magento deployment workflow and configuration properties for a while

LESSONS LEARNED

1. It can be painful!

app:config:dump creates the env.php and config.php files dumping all the database config in them. They then "lock" these fields in the admin

A change to env.php or config.php files will instantly create an error 500 until it is read into the database. So put maintenance before you change things.

For one little change use the command line instead. (more later)

2. app:config:import first wipes all settings in the database

if a setting is not in the files, that particular option will be back to default. (whereas in #3 they are left as is)

I didn't expect that the first time!

The idea is that it is for a deployment in a stable deployment workflow where you clone everything eg deploying containers at installation

3. setup:upgrade will update settings from file only

Settings not in the file will be left as they are (whereas in #2 they are reset to default)

This allows you to set some settings locked in file while leaving others editable in admin.

BUT: running setup:upgrade it also clears generated files and caches, so you have to compile and deploy static again each time, not great if you just want to change a few small settings. (But in a magento workflow you can just copy the compiled and static files over from the build machine orrepository again which is quick)

UPDATE: @john-hall reports quite rightly that setup:upgrade --keep-generated will preserve the generated files to minimise disruption

4. config:set (saves to env or config) and config:sensitive:set (saves to environment) are the least disruptive way to change things

They update both the file and the database.

They do not wipe cache, generated files or anything - as a matter of fact for some things you might have to clear config cache manually to see an effect.

It can be complicated to figure out the path and options but but it beats having to go either of the previous two ways

eg: bin/magento --scope=store --scope-code=default config:set web/unsecure/base_url bin/magento config:set -c msp_securitysuite_recaptcha/frontend/enabled_login 0

There is a ridiculously long list to figure out, name wise, so I do

bin/magento config:show > configlist

so i have a file i can search through.

5. anything in these files is locked in admin

You can lock easily from command line or by putting it in the file and then importing/upgrading

6. the only unlock is remove-from-file and 'setup:upgrade'

there is no way to "unlock" via bin/magento config:set that I could find. There really should be. You have to leave it out of the files and then it will get unlocked. Note that you can then change it in admin, but you can't use config:import then

To use in a deployment/rollout system

Note: I am still not 100% there

A bit of work needs to be done on this approach because a lot of modules are sloppy and write into the config file settings which could be different from instance to instance, for example different between the dev, build and production instances. Theoretically they can mark variables in the module xml definition as "env" versus "config" or mark them as sensitive, but they don't.

1. sensitive settings go in environment variable, or env.php

these are not put into source control. I've stuck with env.php for now

2. setting that are going to be the same between all stay in config.php

This can be put in source control and copied from machine to machine.

I am using a partial config.php that leaves "open" things i want to allow changing from the admin interface so I have to use setup:upgrade not the config import. But then often this is rolled out with other changes so that would run anyway.

3. Things that are machine/environment specific go in env.php

You can move entire config sections out of config.php into env.php so that you have one env.php per machine/instance and a shared config.php

So whether something is in test mode or not, alternative email addresses etc.

This is one that will take time to decide.

I hope this helps

I have spent quite a few hours comparing, merging and producing my config.php and env.php that lock everything I want to speed up but leaves open things we want to be able to modify. It's not there yet, and just today I wiped entire sections trying to make something editable in admin again...

Answer 2

Try this

open config.php file from app/etc/config.php location.

Now remove everything from this file except - modules array like below code :

return array (
'modules' => 
array (
'Magento_Store' => 1,
'Magento_AdminNotification' => 1,

then save this file !!

now after saving this file you need to run below command :

php bin/magento setup:upgrade

php bin/magento setup:di:compile

php bin/magento cache:clean

php bin/magento cache:flush

Then logged in to your backend admin panel - and check now configuration are unlocked and able to editable.