4

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?

Improve this question

3 Answers 3

Reset to default
5

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!

Improve this answer
5
  • Thanks Ben, some really good points. I'll edit your answer with my final setup.
    – jharrison.au
    Feb 20, 2014 at 21:32
  • I suppose you would cringe if I said I was contemplating rewriting Mage_Core_Model_Resource_Config::loadToXml() to load in my config file last......
    – jharrison.au
    Feb 20, 2014 at 23:02
  • shake-my-head.gif. Well, it is the most direct place to preserve the tree duplication behavior without duplicating code.
    – benmarks
    Feb 21, 2014 at 12:18
  • It's just naming something Zzz_ModuleName is just so ugly
    – jharrison.au
    Feb 21, 2014 at 13:37
  • Your other option is to change Mage_Core_Model_App::_initModules() to load your file between the loadDB() and saveCache() calls, but you would then need to manage scope-filling yourself either directly or by duplicating the functionality in ` I suppose you would cringe if I said I was contemplating rewriting Mage_Core_Model_Resource_Config::loadToXml()`.
    – benmarks
    Feb 21, 2014 at 15:59
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!

Improve this answer
0

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.

Improve this answer
1
  • It is possible and fully functional to define scope-specific settings in module config files. local.xml is a bad idea for OP's use case mainly due to those files not being cached.
    – benmarks
    Feb 21, 2014 at 12:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.