We have a new configuration system, but we have not defined any standards in terms of how to implement it. I believe there are two main considerations that need to be addressed.
- How much information should be stored in each file?
- What is the naming convention for configuration files?
This is just a stake in the ground to get discussion going.
- For configuration of 'things' (aka image styles, actions), we have one file per 'thing'. This has already been implemented in image styles and it seems to make a lot of sense.
- For groups of settings (aka what is currently managed by system_settings_form()) I propose we keep one file per settings form per module implementing settings. I realize this is a somewhat arbitrary way to divide things up, but it mirrors the way the UI is organized which should improve findability and maintains a consistent organizational scheme. This is how the Performance settings were done in the initial patch. EXAMPLE: System module implements the settings form at admin/config/development/performance. This should be implemented as one XML file provided by the system module. Block module does a form_alter() to add the 'Cache blocks' setting to this form. That setting should be provided in a separate XML file provided by the block module. One file per form per module.
- For settings NOT exposed in the UI, these should be grouped together in one more XML file, provided by the module responsible for those settings (in the case of core this will mostly just be system module.)
- For 'things', files should be named
<module>.<thing singular>.<machine_name>.xml. EXAMPLE: image.image_style.thubmnail.xml.
- For 'settings', I don't have a good formal guideline, just that they should be named similarly enough to their accompanying form that it is recognizable. One thought would be to use form_id but that isn't always going to be ideal. Perhaps with a '.settings' suffix? EXAMPLE: system.performance.settings.xml, block.performance.settings.xml (note that right now we don't use the settings suffix).
- I don't have a suggestion for the non-form things, other than it should be
- Do we want to have a 'core' prefix for core-provided configuration? I think it is kind of pointless, but there might be some scenarios where it could come in handy.
- I have heard some people suggesting that we should implement variables with one variable per file and I don't think this is workable. The number of files is already going to be enormous and I don't see a ton of gain towards adding thousands more to the mix.
- If anyone brings up the possibility of changing file format in this thread, or challenges the reasoning behind XML being chosen, I will ask that they be banned. This is already going to be an enormous bikeshed, lets at least keep the bikeshedding on topic.
- File names are our only querying mechanism at the moment, so naming them properly is very important. "give me the list of config files matching
foo.bar.[^\.]*.xml" is all we have (for now) - additional filtering on specific properties inside the definition needs to happen in PHP, after unserializing the XML to PHP, and is therefore costly. This means that the file name for the configuration of a given "thing" must (of course) contain the thing's "primary key" (node type name, field name, view name...), *with a prefix* that unambiguously prevents clashes.
- The automatic copying of module settings only has "by file" granularity. This means that the granularity of config files for a given subsystem is also determined by what we want modules to be able to specify as part of their initial config. This also has implications in terms of systems like Features, which may want to deploy only one setting in a file, rather than all of them.
I'm going to let this issue run for two weeks, then take a decision based on feedback. This is not rocket science and we should be able to come to an agreement reasonably quickly. It is also really important to get a decision in place rather than spread the bikeshed across the 80 other issues where we are converting core subsystems to CMI.