Features done right? Features done wrong? What changed, what improved, what's still missing.

This is a preview of Nuvole's training at DrupalCon Amsterdam: "An Effective Development Workflow in Drupal 8".

Nuvole gave two talks about the current status of Configuration Management in Drupal 8 at European Drupal events in the last few weeks: Drupal Days Milan 2014 and Drupal Camp Alpe Adria 2014.

Developers attending the events were mostly interested in how the future Drupal 8 Configuration Management capabilities will compare to Drupal 7, with and without the Features module (or, in general, with and without what we call the code-driven workflow).

Here is a comparison based on the current status of Drupal 8. Please note that CMI, the Configuration Management Initiative, is still under active development, and for example a couple issues mentioned in the slides have already been resolved, shortly after we gave our presentations. The very basic concepts, though, remain unchanged from our September 2013 post, so you might want to review that one if you have never heard about CMI before.

Configuration Management: Key differences between Drupal 7 and Drupal 8

Configuration is well-defined

In Drupal 7 it isn't always clear-cut whether something belongs in the "configuration" or "content" realm. Are vocabularies configuration? Are taxonomy terms configuration? And what about a taxonomy term whose ID is used as a contextual filter in a View? Several approaches to this are possible, like soft configuration.

In Drupal 8, configuration will be less subjective: Drupal has an "Export Configuration" function that exports all the site configuration; if something is not there, it is not considered to be configuration. Concepts like soft configuration still apply, but at least it's clear what is configuration and is not.

Configuration is stored in files

Drupal 7, generally, stores configuration in the database, together with content. Only a little subset of configuration is read from PHP files.
In Drupal 8 configuration will live in text files. Then, for several reasons (performance, safety, security), those files will actually be stored in the database by default (one of the most visible recent changes), but will still be accessed and managed as files.

Unified format and approach to configuration

A particularly annoying issue with Drupal 7 is that modules are free to set their own standards for storing configuration, so it is common to find sites where configuration is scattered among variables, database tables, objects exported via CTools, Features, and other places. Modules like Features at times need some "black magic" to guess where and how relevant configuration is stored.

The unified approach in Drupal 8, where all configuration is in the form of text files in the YAML format, is a great step forward. It removes the guesswork needed by Features in Drupal 7 to understand how to find and export components.

Staging configuration

In Drupal 7 you can have "staged configuration" through Features and the Features revert operation. Drupal 8 will introduce, out of the box, an "Import Configuration" facility that you can use to import either the whole site configuration or a single configuration file. The approaches are mostly equivalent, but on one side Drupal 7 + Features offers better packaging functionality, on the other side Drupal 8 will allow to import a complete site configuration (all variables, permissions...), something that is highly unpractical to do with Drupal 7 and Features.

Interface to developers

From a developer's point of view, writing PHP code to access and/or set a component's configuration in Drupal 7 is tricky, since you don't have a global interface, let alone an "entry point" that allows you to explore all the site configuration: you are forced to use a mixed bag of tricks ranging from variable_get() and variable_set() to database queries, to Ctools hooks for making configuration exportable and so on.

Drupal 8 will bring a very welcome improvement by providing a dedicated type for configuration entities and the unified interface Drupal::config($name) for getting and setting all configuration values: as a typical example Drupal::config('system.site')->get('name') will return the site name, and the same pattern can be used for everything.

The shootout: Drupal 7 vs Drupal 7 + Features vs Drupal 8

A quick feature comparison table between Drupal 7 core, Drupal 7 + Features and the current state of Drupal 8. As you see, a developer that is now using Drupal 7 without features will see spectacular advantages in Drupal 8, while experienced users of Drupal 7 and Features will still miss something.

Functionality
D7 Core
D7 Core + Features
D8 Core (current)
Export full site config (no content)
NO
NO
YES
Export selected config items
NO
YES
YES
Track config changes (full site)
NO
NO
YES
Track config changes (selected items)
NO
YES
YES
Stage configuration
NO
YES
YES
Package configuration
NO
YES
NO
Reuse configuration in other projects
NO
YES
NO
Collaborate on the same project
NO
YES
NO
What is still missing?

It's important to understand the use case for CMI. The stated aim for CMI is not to replace Features. CMI aims at making it much simpler to transport configuration changes from development to production, and this aim was reached.

All other benefits of Features are out of scope for CMI. These include: packaging configuration, reusing configuration in other projects (and not simply moving it between the development and production version of the same site) and enabling real-time team collaboration (developer A and developer B build two separate features for the same site, like the News and Blog sections, simultaneously). So there is definitely room for a Drupal 8 version of Features.

Is CMI “Features Done Right”?

No. It is a nice way to replace and improve one use case for Features: making configuration exportable into text files.

Is CMI “Features Done Wrong”?

No. It is a huge step forward to developers and it paves the way for additional modules that could offer the same functionality of Drupal 7 + Features in a much cleaner and more reliable way.

See full versions of our Milan and Alpe Adria presentations as a Slideshare embeds or PDF files, below.

Configuration Management in Drupal 8: A preview (DrupalDays Milano 2014) from Nuvole

Configuration Management in Drupal 8: A preview (DrupalCamp Alpe Adria 2014) from Nuvole
Tags: Drupal PlanetDrupal 8Configuration ManagementAttachments: Milano-2014-drupal-8-cmi-preview-en.pdfAlpeAdria-2014-cmi-d7-to-d8--dcaa-140517.pdf