When I first started my funding drive, my plan was to get funded through feature freeze and then evaluate where things stand. Of course, back then, feature freeze was in December of 2012. When we decided to extend feature freeze, I was somewhat concerned about my ability to keep working on core until March, but a combination of careful planning and a large contribution late in the game made everything come together well.

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.

One the third day of DrupalCon Sydney, all the Drupal 8 initiative owners conducted a Q&A with attendees in Sydney. Some of us were there in person, and some connected via Google Hangout. In a moment of weakness, I sent a message on Twitter to request questions via the cheeky hashtag of #IOHeckle. There were so many questions from (and discussion with) the audience that we didn't get to most of the Twitter questions, but they were generally really interesting so I decided to answer them anyway.

A couple months ago I wrote about the funding I have gotten for CMI, and this is an update on our progress and next steps.

Progress in 2012

For the most part, CMI has been progressing very well. We spent much of 2012 re-architecting the system after hitting a few walls in the initial implementation. Much of this work involved abstracting the way configuration storage is managed, making it pluggable and flexible. Since then, we've been moving forward with conversions and features. Here are some of the highlights.

Drupal is in an interesting place right now. For the last few months I've been saying that we have all the pressures of a large commercial software project with none of the resources. This summer I went to a few general open source conferences (as opposed to Drupal-specific ones) and it was really interesting to notice that most of the big open source projects today have a major commercial entity pushing them forward.

Working on core takes time. Writing patches takes time, reviewing them takes time, just keeping track of what all is going on takes time. Most of us are volunteers but the most valuable thing that I lack as an initiative lead is raw hours. One of the reasons I agreed to lead the configuration management initiative is because I was getting a generous donation of 50% of my billable time from NodeOne (now Wunderkraut) to work on the project.

NOTE

This article is now obsolete and very much out of date. For current status and information on the configuration API for Drupal 8, please visit the official handbook pages.

Today Dries committed the initial implementations of a central API for managing configuration in Drupal 8. This was the second major commit as part of the configuration management initiative (the first being the API for generating UUIDs.) This new system saves configuration to XML files stored on disk, that you can push to another site and load to make them active. For a high-level overview of the system, please see

http://groups.drupal.org/node/191283

The first alpha release of Services 3 has just been rolled and should be available for download on the project page by the time you read this. This is a full rewrite of Services from scratch, with a variety of new features and improvements. This rewrite was initially done by Hugo Wetterberg and then taken over by me for various cleanups and fixes. Services 3 includes a variety of new features and upgrades including

<

ul>

I'm currently chasing a wild goose of an idea in Drupal 7, and found myself in a situation where it would be really convenient to run the Drupal install script through a debugger. Normally, this won't work because the installer runs through many stages of redirect plus batch api. However, I knew I had read that there were changes in Drupal 7 to make this possible, and catch pointed out in IRC that Drush can install Drupal now. So I went over to see how Drush does it and half an hour later I had the following script. Drop it into a standalone PHP file and you're set to go.