CMI at feature freeze

I figured that since feature freeze has now come and gone, it would be a good time to offer an update on the status of CMI.

TL;DR

CMI is in very good shape at this point. I am amazed and humbled at the amount of work that has been done by hundreds of contributors that have helped out in the last two years. We have implemented all the major features we needed by this point with almost no compromises from our original MVP. That said, there is still plenty of work to do, particularly around testing and documentation.

Overview

When we started nigh two years ago, I had in mind a very broad set of goals for the system.

Store configuration in machine-readable files that can be managed in version control and staged between environments.
Provide an API for updating configuration in an environment, as well as a basic UI for performing this update.
Convert core to use the new system 100%.
Provide internationalization and translation functionality for configuration.
Provide developer and user documentation on the system and how to use it.

It seems like so little, and yet it is so much. Now that feature freeze is over, it seems like a good time to take stock and see where we're at with these goals.

Store configuration in machine readable files

This is done, and has been for some time. The system has undergone an enormous amount of change since its first commit (at least one major rearchitecture, changing from XML to YAML files) the public facing API and interaction with the files has changed very little since that first commit.

Config update API and UI

The API to update config has been in place for some time. However, since some of the most complex areas of core have yet to be converted (most notably fields and node types) it has not been tested to the fullest extent that is needed. It is possible that this testing will determine that we need some additional dependency handling, which we will add if necessary. Beyond that, there are some issues that could use help and input as far as the update process.

The UI went in last November during BADCamp. It is very basic, but it allows users to see what configuration they have staged for import, and a button to press to import that configuration. Some additional issues are in the works to make this UI more functional.

Convert core to the configuration system

Conversions to core started in earnest at DrupalCon Denver last year and have been progressing very well. One of the major things to happen here was the introduction of the ConfigEntity system to handle complex 'instanced' configuration like Views, Fields, or Roles. Generally the conversion have centered around three areas:

Convert system_settings_form() implementations to CMI - There are only two conversions remanining.
Convert all variables to the config and state systems - We are down to less than 150 calls to variable_get() in all of core! Most of these will be taken care of when the field/node system is converted.
Convert configurable data to the ConfigEntity system - A lot of work has been done here, but this is where the most work remains.

Additionally there are some specific issues that are super-important to the cause and could use attention

I would say that we are roughly 80% finished converting core to the configuration system, which I consider really amazing and fantastic. Most notably Views was committed to core fully converted to CMI from the very beginning.

Internationalization and translation

This has probably been the most troubled and difficult aspect of CMI since the beginning. It took a very long time to come to consensus about an approach, and the code took a very long time to get committed. Unfortunately, because of time constraints, some features that would have been very helpful for D8MI (like integration with admin forms) had to be abandoned. However right now we are most of the way there.

We added a context system which allows configuration to be modified based on arbitrary contexts (language is one such context, but this could also be used by systems like Domain Access.)
A configuration schema system was added to be able to identify which configuration is translatable and which isn't. The process of creating these schema files is in progress and can be tracked at (http://drupal.org/node/1910624). This is a great place for new contributors to dive in and get involved!
The config schema now needs to be integrated with locale module. There is a patch in progress for this at (http://drupal.org/node/1905152).

Documentation

Of course, as always, this comes last. However I think the time has come to get started on this seriously. There is an existing handbook page for the technical documentation of the system however it is largely out of date. A fantastic exception to this is the schema and context docs written by Gábor as each of those systems went into place.

In addition to technical docs, we will also need user-centric documentation about working with the system for both simple and advanced use cases. I am hoping to work with an experienced technical writer to build these pages, so if you are/know of someone who is interested in getting involved in this way, please get in touch!

Additional topics

There has been a lot of discussion and debate about what to do with configuration when a module is installed/uninstalled, and the meta-question of 'Who owns a piece of configuration?' The classic example of this is when node.module provides a default view for the Drupal homepage. Is this node's configuration or views'? What happens to the view if it remains and node is uninstalled? These questions have been discussed in great detail at (http://drupal.org/node/1776830) and that remains our largest outstanding architectural question. Right now it is somewhat blocked while we decide what to do about disabled modules (see (http://drupal.org/node/1199946)).
There has been a very long and detailed discussion around what to do with the url alias configuration which includes some unique questions about what exactly is configuration and what is content.
There has not been a lot of talk about content staging since CMI began, but great strides have been made in this area regardless.
- UUIDs are now a part of every entity, allowing them to be staged between environments even when serial IDs change.
- Entities can now be serialized and unserialized to/from a machine readable format that all Drupal installations will understand.
- The new entity API makes saving nodes programmatically safe and reliable.

There are even basic web services for CRUD functionality in core through the REST module! So the basic building blogs for a variety of solid content staging solutions are in place, although those solutions will have to live in contrib, which frankly I think is fine.

Getting involved

The planned deadline for the integration phase (when all APIs are frozen and all conversions are complete) is July 1st 2013. There are three big sprints until then that we plan to use to boost our standing (please come and sign up for these):

Thank you to my sponsors

As a reminder, my time on this work is sponsored by the individual donations from ChipIn on my site, as well as the generosity of donations from the following companies:

Acquia Riot Games Bluehost Dennis Publishing Pantheon WebEnabled Reload.dk Annertech Comm-press GmbH Undpaul.de

Thank you all for your support. I will have an update on funding and work on CMI post-feature-freeze in a followup post in the coming days.

And of course THANK YOU TO EVERYONE WHO HAS CONTRIBUTED TO THE SYSTEM. Getting this implemented into core has taken a great deal of blood, sweat and even tears to get done. It has not been easy but we have come so far. I am really excited to see CMI get pushed through these last phases of the core cycle.

topics: drupal planet drupal

Original Article:

CMI at feature freeze