Unifying Drupal Configuration at Drupalcon Chicago

 

by David Strauss @DavidStrauss on Twitter

Issues we're facing

Drupal has too many overlapping configuration methods. It's confusing and not good enough for developers coming from other platforms. The code relies on configurations which could be in the database or could be in the database. You never take code from production to development and you never push your database to production.

I don't think contrib can solve this.

Terminology

  • Auditable: Ability to determine whether a configuration ite is correct without touching anything. This is something features does well.
  • Declarative: Defines what configuration should be.
  • Imperative: Specifies what you want to have happen, as in an ALTER statement.
  • Configuration Binding: Making sure there is a relationship between what you want to happen and what is used.

Lessons from Other Projects

  • Jenkins (formerly Hudson): Good atomic units of configuration, nice disk representation of configuration. I can edit the config file on disk, or I can use the GUI to alter the disk representation, or I can track the config file through SVN.
  • BCFG2: Good: Configuration is stored in flexible bundles;

Variables are good because they're declarative and persistable to disk, but they're bad because they're generally defined in PHP and it's basically a key/value store that doesn't enforce bindings; updating a value through the UI doesn't write to disk, it writes to the DB, which could be overridden by the settings.php.

There's hook_update_N(), which allows use of Drupal APIs and can do almost anything, but it's imperative. The Schema API changes aren't imperative, and it's single-purpose. Finally, we have configuration in the database. It allows blurring of content and configuration, but there's no automation and it's completely imperative.

I'm sympathetic to the declarative configuration. My goals:

  • Delcarative
  • Flexible bundling/feature grouping
  • Seamless GUI/storage integration
  • Persistable to disk in a VCS-friendly format

My Goals for D8 Configuration

I'd like to drop settings.php and replace it with a pluggable system so that you could use code to generate a configuration item. I'd like to add a sites/[host]/config directory, which is not web accessible. We may even move it out of the web root.

I propose that we do this through a canonical representation of JSON which is key-sorted. This will allow us to store data in a way that keys are sorted in a predictable order and whitespace indentation is standardized. This way if I update in the GUI and the file is changed on disk, running a diff wouldn't reorganize everything. It's also human-editable if I really want to.

The reason I'm advocating JSON are that it's very portable. It's more accessible than serialized PHP. PHP has good functions for parsing it. XML is so much more verbose, and parsing speed is an issue, and we won't be able to make it directly accessible with PHP. You also don't have the attribute ambiguity of XML.

I haven't created as coherent a vision for all the namespacing. I'd like to have a settings file affect multiple modules.

Did you enjoy this post? Please spread the word.