|Issue tags:||Configuration system|
A base StorageInterface needs to be created, with different storage mechanisms that implement it (currently the file storage and database storage are completely separate classes.)
The configuration system was designed to have two storage systems - files and active store. However, it turns out that there are actually more storage systems than that. For instance, there is the default configuration that ships with modules, which is read-only storage. This potentially needs to be referred to at install time, to check if config have changed from defaults, and to reset config to default values. There may be other storages which come down the line. In order to manage this, we should adjust the config system to work with 1:N pluggable storage engines. There are several adjustments that should happen for this to work.
- Currently the config class manages the interaction between the file storage mechanisms. A potentially better solution would be to create a StorageManager class which manages the interaction between the storage engines.
- Define what all of our read/write situations are so that we can architect this properly.
- Manager contains instances of all storage objects and attemps to read or write from or to them as appropriate.
When these two are done the architecture of the config system will look more like this:
It would be useful to provide an interface and base class that implements functionality common to configuration more complex than a collection of settings (image styles, content types, views, etc.) There has been a lot of discussion about what these should be named but the only agreement is they should NOT have the words ‘entity’ or probably ‘config’. For the sake of this discussion we will call them ‘thingy’. Thingy is not really a part of the configuration system, it is just a useful base class for people to extend for more complex use cases.
- #1567812: Remove "Verified" from configuration class names
- #1500238: Encode/decode data via PHP serialize()/unserialize() for DatabaseStorage (storage controller specific data formats)
- Unblocks YAML FileStorage format change.
- #1470824: XML encoder can only handle a small subset of PHP arrays, so switch to YAML
- #1589174: Configuration upgrade path is broken
- Fixes the upgrade path helper function that converts variables into configuration.
- Introduces formal namespaces in configuration object names: the part before the first dot/period.
- Unblocks #1505090: Clean up all (non-default) configuration (files) when a module is uninstalled
- #1605324: Configuration system cleanup and rearchitecture
- Fixes architectural OO design and also slightly performance.
- Separates DrupalConfig, the "storage arbitrator/manager", from actual storage controllers.
- Fixes #1605236: Move synchronization methods from StorageInterface to DrupalConfig
- Unblocks #1624580: Research and implement a proper design for StorageDispatcher
- #1447686: Allow importing and synchronizing configuration when files are updated
- Unblocks Configuration UI work and starts to untangle storage controllers.
- Introduces basic import/synchronization support.
- #1324618: Implement automated config saving for simple settings forms
- Required to properly convert variables into configuration.
- #1609760: hook_image_style_*() is not invoked for image styles upon Image module installation
- #1175054: Add a storage (API) for persistent non-configuration state
- Required to fully convert settings forms into configuration forms.
- #1599554: Tutorial/guidelines for how to convert variables into configuration
- Required to not have to repeat every variable to config conversion once more for D8.
- Unblocks various Novice conversion issues.
- Re-opens these issues:
- #1552396: Convert vocabularies into configuration
- Separates the actual configuration object from the storage controllers.
- Introduces "typed" configuration objects; e.g., Vocabulary + ImageStyle configuration objects (mimicking Entity objects to some extent).
- Introduces high-level Configuration API CRUD functions for module configuration.
- Unblocks all conversions for typed configuration; e.g., entity types, entity bundles (node types, etc), fields, field instances, text formats, etc.
- #1609418: Configuration objects are not unique
- #1605460: Implement dependencies and defer process for importing configuration [CONFIG_DEFER_SYNC]
- Enhances import/sync mechanism for complex configuration having (inter-)dependencies (mostly typed config, such as entity types, entity bundles, fields, field instances).
- #1605338: Implement pluggable storage for configuration system
- we need pluggable back ends for config storage so that sites can use something other than the db
- #1605124: Configuration system performance
- Fixes the performance of retrieving configuration and repetitive calls to config().
- @todo Generic Property API.
- #1448330-19: [META] Discuss internationalization of configuration
- Leverages Property API to introduce meta data for config object keys; e.g., required, validation, multiple/cardinality, translatable, etc.
- Unblocks translation UI for configuration.
- @todo Configuration UI
Parallel / Anytime
- #1505090: Clean up all (non-default) configuration (files) when a module is uninstalled
- Depends on formal namespace/owner standard in configuration object names.
- #1608912: (Re-)adding keys to configuration breaks the intended goal of being able to diff files
- #1608842: Replace list of bootstrap modules, enabled modules, enabled themes, and default theme with config
Original report by @heyrocker:
The config system was designed before any implementations were done, and several threads have discussed potential cleanups. I'd like to bring all those threads together here and move forward on options. Ideally, these changes would not affect the public API.
One of the most glaring issues is that there is no commonality between the file storage class and the sql storage class. I would like to see this rearchitected so that we have a ConfigStorage interface, and there are ConfigFileStorage and ConfigSQLStorage implementations of it. This will also make a lot of issues like #1447686: Allow importing and synchronizing configuration when files are updated a lot easier to implement. There has been discussion that this new interface should be a generic key/value store (this was discussed somewhat in #1202336: Add a key/value store API) however I'm not sure this will work out. msonnabaum, beejeebus and I tried building this and it had some complications, like that the config system isn't really a key/value store, its a key/key/value store if you will.
While this is happening, much of the functionality that currently lives in DrupalConfigStorageInterface would move up to the DrupalConfig class (for instance synching between files and the active store in the situations where that happens.) DrupalConfig would now hold references to two storage objects - files and active store. Then it can manage the interactions between them within its existing public API functions.
Another thing that needs to happen is we need to figure out how/where to statically cache config data. In #1270608: File-based configuration API catch suggested we statically cache the config objects in config(), but we could also just statically cache the data within each class. Regardless, a more sane architecture would make this easier at whatever level we decide to implement it.
I know someone is going to bring up whether or not we should do automatic writethrough of to files on save, but I think that is irrelevant to this issue and needs its own discussion where we decide to add a flag to control it that is on by default. (see what I did there?)
I can start mocking this up into a real patch in the next day or two if nobody beats me to it.