We've been working on taking the admin screens, for example the user permissions, and storing them in XML on the disk, which becomes the canonical storage area for that data, so that when you update them it writes to disk and when you need them, the data is fetched from disk.
We started this at DrupalCamp in June, and that was the basis of the configuration patch that was committed to core three weeks ago. Big accomplishment. A ton of people helped to get this patch in.
We need to convert all the core systems to use the new configuration management systems. It's a big job. We have fifteen or twenty ways that core stores configuration currently: anything that is not an entity is configuration. For example, what about URL aliases, when you have a site with 32,000 aliases? We need to decide this on a system-by-system basis. Any time you want to convert a system that seems simple, as soon as you start working on it, it turns into a big blob of mess! Some of these systems will need lots of discussion and thought to work out.
After the code sprint I've done the lion's share of coding on this (also Justin,) but I don't scale! I'm trying to get a company off the ground, and I need everyone who is interested in this to get involved in the configuration management initiative. I have Fortune 500 directors coming up to me telling me how important this is, but don't contribute code. I have really simple issues in the queue that sit there for weeks; please get involved. We have issues of all skill levels, and I'll be holding sessions every day this week in the code sprint room at 1:00pm.
Questions and Answer
Q: This will lead to lots of files that change. How will it affect VCS?
A: That's a developer issue. For us to make something that's abstract enough to approach the needs of a generalized developer is not realistic to get into Drupal core. Developers can manage this on their own.
Q: What's going on at Drupalcon>
A: On Friday, me and Justin are running the code sprint. If we start working on big issues, we'll pull them off to the side, and if newbies want to be involved, Justin will help them. Most of the plan is to convert core subsystems to fix the issues with deployment and make progress on the issues queue.
Q: The line between configuration and content is different for each site. How do you deal with that?
A: We've spent a lot of time trying to solve this issue by taking a different workflow for content and configuration, but Drupal melds these two things together. We should stop approaching the problem that way; we should treat everything in Drupal as its own thing. Don't force it into a framework. Of course, I just said that everything that's not an entity is configuration. So what changed?
Since my last talk, the entity system has become more powerful, and when I looked at the ability to create a deployment management system that works for EVERYTHING, it looked like too much to handle in one core release. I said to myself, with the stronger entity system, I think it makes sense to say that everything that's not an entity is configuration. This is a good step; we're moving forward. It's more about being pragmatic about our release schedule.
Q: You specifically mentioned URL aliases. How are you approaching these on content vs configuration?
A: I was talking with Dave Reid about this. I don't think they are content at all; Dave has a different opinion. I think Dave doesn't want to have tons of aliases in the configuration system and I sympathize wholeheartedly! There is a gray area, and some areas are going to be easier to handle than others.
For example, roles bring together users and permissions. Where does that lie in this view? There's all sorts of stuff where the field definition is configuration and the field data should be content. We'll have to talk about what we want to do with these issues.
Q: How does Features play with configuration management in Drupal 8?
A: I don't have an answer to that; I have a meeting with the Features guys later this week. I don't want to break their upgrade path. I think there's a lot of things in the configuration management system that will make their lives easier, for instance having a single API for all configuration to go through. Right now, people have to implement Features in their modules, so it's hard to get broad coverage.
On the other hand, we're talking about grouping data into these files, so the ability to granular-ly deploy one piece of information will be more difficult.
Q: One of the problems with versioned configuration is conflicts with production. How do we figure that out?
A: I have figured out that this will be your problem. This is a good place to note that you shouldn't make changes on production.
Q: Are Views and Taxonomies in config, and why?
A: Views will definitely be configuration. Earl will have to rewrite his views export stuff, which he said is a good idea. That process will be the same for Views, except you won't have to manually export your views on either side.
Taxonomy is a question that we haven't approached yet. Vocabularies and items are entities, but there has been a lot of talk about taking Vocabularies and not making them entities anymore, and in that case it's a grey area and it's difficult to see.
In addition to vocabularies being configuration, it may make sense to make specific vocabularies where the terms can be considered configuration, so that you can choose how your vocabularies are stored depending on how you use them. I don't know if this will be possible in the next eight months, but I'd like to see it.
I think there will be lots of things where inside the entity, we will have a piece of configuration. We've been talking about roles living in an entity but the list of available roles live in configuration. I think there will be lots of things where we come up with bridge strategies like that.