Configuration Management in Drupal 8

Time slot:

March 8th, 1:45 PM - 2:45 PM

Room:

Michigan A/B

Problem:

Configuration management and the deployment problem. The excellent work of Earl Miles and the Features team helps us to get our configurations into code, but we have no reliable way to correlate configurations, to relate one configuration item to another, and currently features support is provided by only a certain set of modules. Each 'exportable' thing needs to provide its own tables and there is no central way to store data that is not loaded on every single page load.

Proposed solution:

A new system settings API based on the work I have started on github (link below). This API aims to be like the variables table on steroids where everything is inherently exportable and alterable. In addition it tracks meta data about each setting so that settings can be correlated and exported. If a location field relies on a google maps api key or if a view relies on a field, one single central API can alert us of that dependency easing the creation of install profiles, features, or other configuration changes and allowing related configuration changes to be grouped dynamically for easier and more complete configuration deployment and sharing.

In addition, the storage mechanism is a pluggable system that can be swapped out via settings in settings.php so that the settings can be stored in a separate database, database engine or in code, allowing it to be tracked by version control.

Each setting is an atomic entity and each setting is stored in a log with the original setting and the new setting. The log position is stored in the primary settings table (or other system). This is useful because it means that the logs can be replayed on another server to fast forward to the more recent change set and because the old and new settings and meta data were both recorded after any necessary alters were performed, rolling back configuration changes from a reliable Drupal recovery console should become possible.