This document is a proposal for a high-level gameplan for the configuration management initiative.
Measures of Success
If we succeed, we should have achieved several major goals:
- Drupal configuration information will be able to be managed through standard tools.
- Drupal content will be able to be staged between servers without ID collisions.
- Drupal content will be able to saved programmatically without relying on the Forms API and without a loss of functionality.
- Configuration data is available to Drupal early in the bootstrap process without booting the database.
- Configuration is revertable, either through the UI or code.
- Links/References between content and configuration, or content and content, or configuration and configuration, can exist without being broken by being moved between servers.
- The system will be flexible enough to handle complex use cases, including ones we can't predict
- The system should cause no significant performance regressions, or even better improve performance and scalability overall.
Content VS Configuration
FIGHT! There has been a lot of talk over the years (much of it by me) about what is and isn't content and what is and isn't configuration. While I have long been an advocate of the concept that Drupal does not meaningfully make this distinction, I have had a hard time imagining an architecture under which this can work reasonably. There has been talk of having a master interface from which anything persisting data implements, but for the time being this is controversial and honestly I don't know if it causes more problems than it solves. Therefore, for the purposes of this discussion I propose the following idea:
* If it is an Entity it is content, if not it is configuration *
Ultimately, I think this gets to the crux of the problem, and I think we can get where we need to with this definition. If we have some brilliant ideas out of the blue, I don't think it will be too much work to refactor what follows as necessary in order to match what needs to be done. Also, by drawing this line in the sand now, we can get to work on some more isolated pieces of the problem and learn and iterate along the way, which I think will be very useful. Already research and experimentation has brought me a long way but at some point we do need to actually get to work too.
So what pieces need to come into place to make this all work?
Content
There are basically two hurdles to be overcome on the content side.
1) We need UUIDs in core and we need Entity support for UUIDs. I have already written a proposal for this which can be read and reviewed at
http://groups.drupal.org/node/145614
2) We need to be able to save entities from code reliably, without loss of functionality and without invoking Forms API. This should happen without a loss of functionality (IE we should be able to get the same validation, and all data should be submitted properly). The main thing I would like to see happen here is that validation (aka form_set_error()) be revamped such that error setting and displaying become separate interests, and thus we can use the same APIs for form submissions as well as saving from code (with the addition that form submissions will have some display code for their errors.) I haven't really thought through an architecture for this, and I'll want to get someone who knows Forms API much better than I do involved. Volunteers?
The rest mainly centers around getting logic out of form submit functions, and removing the reliance on environmental data that may not always be available ($_GET, etc) The former is just cleanup and testing, the latter is Larry's job :)
Configuration
I have also written a separate document that details my plans for configuration data at
http://groups.drupal.org/node/149749
One thing this document doesn't address is one of our biggest problems - when a piece of configuration references a specific piece of content, how do we resolve that reference given that IDs may break between servers? What we need is something in the config data, perhaps a specific implementation of the config interface, that specifies 'I am a reference to an entity' and includes the entity type and uuid of that content. When a module sees this, it knows that it can go and pull that content out based on the identifying information. This should work out quite well, as long as we always use UUIDs for these references. If more operations need to be done on these content items, they can be resolved using the APIs that will be created during the UUID phase.
Put It Together
You'll note that none of this changes the user experience of deploying Drupal sites much at all, and that is by design. I feel it is important to get these underlying technologies and APIs in place before moving on to what we do or don't expose to users as a part of core. In fact, if this was all we got done in the D8 release cycle I would actually be really really happy and consider the project a success. That said, there should be nothing in the above that prevents any of the currently implemented contrib modules (like Features or Deploy) or anything people are considering down the road from being implemented. Spotting some holes? Now is the time to speak! We really want to get some reasonable amount of consensus around this before our sprint in Denver June 8-10 where we can hopefully start scaffolding things together.