Locking the system configuration and using local.xml exclusively - good or bad idea?

Question

I'm proposing an idea of completely locking users out of the system configuration and instead managing all config through local.xml.

Pros

1. No untracked config changes
2. Easily manage environment-specific changes (staging vs. production settings)
3. All config changes must pass development and staging testing

Cons

1. Slower process for config changes
2. Potentially large local.xml file
3. All config changes must pass development and staging testing (yes it's a pro and a con)

I'd like to know how this might affect things like web/unsecure/base_url and if anyone can see any side effects I'm missing. Has anyone done this before?

Answer 1

Depending on the admin users / business owners, you may have a hard time getting buy-in. That's your first hurdle.

The other thing you need to address are any modules which use setup scripts to write configuration setting to the database. This is a legitimate practice from which your approach deviates, and it is therefore incumbent on you to deal with this yourself.

You have two areas where your configuration files could be stored. I'll make my recommendation after explaining the process of config loading (for posterity; I suspect you know this already).

When Magento configuration is being compiled, the result is a massive XML DOM which takes up residence in the Mage_Core_Model_Config::_xml property. The process involves compilation of file-based contents from the following sources, in order:

1. app/etc/*.xml (including local.xml of course)
2. app/etc/modules/*.xml
   1. app/etc/modules/Mage_All.xml
   2. app/etc/modules/Mage_*.xml
   3. app/etc/modules/[others].xml
3. Module config files (config.xml)
4. app/etc/local.xml (again)
5. core_config_data table via Mage_Core_Model_Resource_Config::loadToXml()

You could make use of (1) and just add an additional .xml file in the app/etc/ directory, but due to the mechanics of configuration merging you would never be able to override default values declared in module config files.

I'd recommend module-based storage, and I'd recommend making that module load after all others. You can do this two ways:

1. By simply naming the module's declaration file in such a way that it is last in the list if you do glob('app/etc/modules/*.xml')
2. Finding the last-loaded module and make your module <depend /> on that module.

Edit: you really should take the module-based approach, because the .xml files in app/etc/ are not cached! Credit to my friend Vinai for that bit of wisdom!

Answer 2

The idea is pretty out there and I can see why it can be beneficial especially in terms of being able to have it tracked via your source code management tool of choice.

In simple terms, the pro is being able tracking changes. The con is that it's a slower process. It's really a case by case scenario when it comes down to the fine details.

I'm sure you are aware of this tool which will make this process a lot easier: https://github.com/netz98/n98-magerun

Check Ben Mark's answer on your question about web/unsecure/base_url - it is possible.

I would personally try and divide what needs to live in the XML file and what's ok to stay in config and have a more flexible/hybrid solution. If the build is Community, I'd install an Admin Actions extension to have the admin changes logged but this will be standard on Enterprise. Good luck!

Answer 3

You can partially achieve this already via module config.xml files.

If you look at a random magento module which defines configs, you find the part, which defines defaults for configs. But this would not work if you have multiple storeviews.

There are also and in module config, but iam not sure if the can get used for this.

At least, the local.xml is not the correct place for this I think, as it defines basic setups, not app specific configs.