Voting starts in March for the Drupal Association Board election.
This is a tracking issue for the file-based configuration work going on as part of the configuration management initiative. The actual work on this is going on in the initiative sandbox in the branch 8.x-file-config, but this issue is for the purpose of providing periodic updates and occasional patches to demonstrate progress and help keep the issue on the radar of members of the core team. The goal is to provide a standard api through which configuration information can be stored, exported, and imported in a standard format (currently XML.) Prior architecture discussions on this issue can be found at http://groups.drupal.org/deployment-build-systems-change-management.
The goal for the initial patch is
- A full API for interfacing with configuration information
- At least one core implementation (ideally more though)
- Whatever work needs to be done at install-time to make this work
- This is a configuration subsystem that intends to read and write configuration objects.
- Configuration objects are basic key/value pairs. However, the value may be in a structured format, such as XML or JSON (or in more usual terminology, the value may use a Content-Type other than 'text/plain'). [« sun has an idea...]
- Configuration objects can be stored in different storages. The subsystem supports multiple storage engines. Each storage engine has to implement methods defined on the
- One of the main purposes of the subsystem is to allow configuration objects to be stored in multiple storages (e.g., files and database) and be synchronized between them. This is primarily for performance reasons, as filesystem access and value parsing can be a bottleneck. It also allows for an explicit "reload" operation, which protects the system from things like syntax errors in the config files. The subsystem therefore differs between "active" storage and "non-active" storage.
- Every configuration object is additionally verified through a signature based on its content.
- The subsystem comes with a bare
SignedFilehandler that uses native PHP functions to read and write a file including its signature.
- For Drupal, there is a base (abstract)
DrupalConfigStoragestorage engine, which partially implements the storage engine interface and provides additional methods that use the
SignedFilehandler to read and write files to disk. Its main purpose is to implement the synchronization between the file storage and the "active" storage. Most notably, it implements the
delete()methods, which save or delete a configuration object from both storages in one go.
- There is a
DrupalConfigStorageSQLstorage engine, which Drupal uses by default as active storage. It reads and writes configuration objects to the SQL database. Very similar to
variable_del()in the past.
- Lastly, there is a
DrupalConfigclass, which is the main application programming interface for Drupal modules and all code. It is instantiated and returned by the
In its current design, an instantiated
DrupalConfig class only handles one configuration object. To access a different one, a new
DrupalConfig has to be instantiated.
The internals can be pseudo-depicted like this:
$config = config('file.key'); | ----------- new DrupalConfigStorageSQL('file.key') | v new DrupalConfig(DrupalConfigStorageSQL) | v ->read() <------------------------------------ DATABASE | v config_decode() | v ->set([property], [value]) | -----------|= RESULT: $config (DrupalConfig) ->storage = DrupalConfigStorageSQL ->data (array) [property1] => [value1] [property2] => [value2] ... $value = $config->get('name'); | v drupal_array_get_nested_value($config->data, array('name')) $config->set('name', 'value'); | v drupal_array_set_nested_value($config->data, array('name'), 'value') $config->save(); | v config_encode($config->data) | v DrupalConfigStorage->write($data) | -----------> DrupalConfigStorageSQL->writeToActive($data) ------> DATABASE | v ->copyToFile() | -----------> new SignedFile('file.key') | | DrupalConfigStorageSQL->read() <--- DATABASE | | v v SignedFile->write($data)
- File formats:
- Internationalization: http://groups.drupal.org/node/185609
- Synchronizing/re-loading configuration updates from disk: http://groups.drupal.org/node/190729 (especially http://groups.drupal.org/node/190729#comment-632198)
- UI for reloading new config after update
- Server-specific configuration overrides (e.g., database, etc)
- Upgrade path from variable system to configuration system
- #13 Retain Default/Override/Revert/Enable/Disable functionality instead of ditching it?
- #15 Cr1) DX for getting a single configuration value?
- Procedural config_get() helper proposal in #26
- #15 Cr2) Default value handling in contrib/modular scenarios?
- #15 Cr3) Enforced sub-namespacing of configuration objects?
- #15 Ma1) Chainable DrupalConfig methods?
- #15 Ma2) Wildcard configuration lookups?
- #15 Ma3) Replace glob() with DirectoryIterator?
- #15 Ma4) Format encoding/decoding responsibilities?
- #15 Ma5) Proper separation of functionality in classes and methods?
- #15 Mi3) Verified storage vs. unverified storage?
- #22 Do not expose the notion of "files" in the API?
- Singular vs. plural terms in config object names? E.g., the object holds only one, so
PASSED: [[SimpleTest]]: [MySQL] 34,830 pass(es). View
PASSED: [[SimpleTest]]: [MySQL] 34,819 pass(es). View
PASSED: [[SimpleTest]]: [MySQL] 34,613 pass(es). View
PASSED: [[SimpleTest]]: [MySQL] 34,612 pass(es). View
PASSED: [[SimpleTest]]: [MySQL] 34,397 pass(es). View