Unifying Drupal configuration

Time slot: 
March 8th, 1:45 PM - 2:45 PM
Michigan A/B

Our configuration management strategy is practically non-existent. When we work on large Drupal sites, we cobble together an overlapping set of strategies involving (1) Features (2) hook_update_N() (3) manual changes (4) variables set in settings.php (5) exportables. It's a mix of automation and manual effort, declarative and imperative models, database and codebase. It complicates testing and deployment. Worse, it makes Drupal a hard sell in markets where users expect the sort of coherent approach found in many Java and .NET projects.

Proposed solution: 

We need to rapidly move toward declarative configuration stored on disk in a canonical format friendly to version control. The format should be easily parse-able, human readable/modifiable, and organized to minimize visible changes in diffs. I suggest we used a sorted JSON dictionary in a format similar to Python's "pretty" format. This format features nice indentation for human understanding, parses efficiently using json_decode() (way faster than XML), is easier to manually modify than serialized PHP, and is portable enough to maintain with system configuration tools outside the PHP world.

When Drupal reads such configuration off of disk, it should either treat it as the real source of the data (as we do for variables set in settings.php) or treat it as a state to automatically converge upon (as Features treats CCK field configurations). Modifications from the GUI should write updated JSON to disk.

This model allows us to hit an ideal balance: non-intrusiveness for basic users (who probably don't care how we're persisting configuration as long as changes work from the GUI) and advanced users (who need to manage configuration in VCS/SCM tools and may want configuration to be read-only in production).

Newly installed modules should include bundled JSON representing the defaults, and Drupal should copy the file to a configuration management directory when the module's enabled. This allows easy "resets" to defaults for many modules by re-copying the configuration.

I've taken this strategy mostly from Hudson/Jenkins, the CI tool. The tool allows complete system configuration from the GUI and persists it to disk using XML files for the central configuration and each job. It's possible to update the configuration from the GUI or to change it on disk and reload it. Hudson writes the files in a canonical structure that is easy to read and allows a VCS tool to easily track changes to jobs. It's a dream: no extra effort for pure GUI users but a powerful system under the hood for advanced use cases.

Diamond Sponsors


Platinum sponsors


Gold Sponsors

Treehouse Agency
Drupal Connect
Chapter Three