- During a cold start, we load a lot of config files from disk. These files must be stored on the shared filesystem when using multiple web heads. This is slow and often unreliable.
- We have an active config directory which looks editable but if you actually dare to edit it, things will break horribly. This is unnecessary brittleness.
- We retain the pluggable storage backend support for active configuration. Core ships with db storage by default, with no caching.
- The config.storage service is aliased to an un-cached config so that follow-up issues (or site-builders) can swap in a caching or a pre-load layer
Advantages of this approach
- discourage people from hacking their active config
- Less potential confusion about which files are which in the import/export workflow
- less YAML parsing and file stats
- more secure - the active configuration in no longer in files
- More familiar development workflow - live database contains everything needed aside from the code
Cons or points of debate
- harder to recover from invalid config causing a site-wide WSOD (#23), but similar to Drupal 7 in this regard
- "discoverability" of the active configuration by browsing files is lost. However they can already be browsed using the single export form
- The quick "copy from active" staging and export is gone. Import/Export UI already partially addresses this, but we would need to document expected workflows (with drush, with UI export, example below, etc.) in the handbook so that we can have people test them once the change is made.
- There are some cases where there is no UI for what's in config (e.g., Breakpoint, Tour, REST modules) and editing active config directly (rather than via export/import) is safe (i.e., config entities aren't being created, deleted, or renamed, and there are no hook implementations that need to respond to what's being changed). For these cases, the development process is made more tedious by requiring either manually editing serialized db rows or going through the export/import workflow for each iterative change. However, #2226761: Change all default settings and config to fast/safe production values is an open issue for making most default Drupal settings be what is best for production, and then providing a mechanism for overriding for developer convenience. So this point could be addressed by using file storage when in DEV mode.
- Git workflows changed. Use case described in https://drupal.org/node/1831818 would no longer be possible (but may be outdated in any case). There will be no more "native" diffing against staging stored in git; there's at least an extra step of "export your config, wipe out your separately tracked config repo that is in staging or somewhere else, and replace it with the export". Drush config-export allows to specify which config directory to export to, see this Git CMI workflow: video and example.
User interface changes
No actual API changes, but some changes to developer workflow.
#2232791: Make the default core config service a db-backed storage with a cache layer.