 Oh, thank you. Thank you, of course, for coming after the lunch session. I know the lunch sort of gets the energy down. And unlike Drupal Camp, Costa Rica, where I had a lunch session, everybody had a red bull on their chair when they came back. We're going to have to bring our own energy here, but I feel that should be fine for talking about one of the more interesting topics in the Drupal 8, and that would be the CMI on a managed workflow. My name's Matt Cheney. I work at Pantheon, doing a lot of Drupal 8 stuff that otherwise helping to have the bestest hosting development platform on the planet. David Strauss, also Pantheon, and one of the original architects of CMI going back a couple years when we were kind of originally conceiving some of the big features that we wanted to put into Drupal 8. And the point of this talk, honestly, in the next, like, 57 minutes, is to give everybody an overview of sort of CMI, what it is, why it is, how it works, some of the problems it solves. And then, because we're sort of, you know, a little bit rolling loose, we're going to do a live demo for you, trying to show you how to use some get feature branches to push some configuration to, like, move it into a testing site and then get that all sort of situated. Using, of course, the latest beta for Drupal 8, because that just came out, because why not present that in front of a room of all of you. So, let's get started. And we have a couple questions. We've preloaded, but we'll obviously take a few questions at the end and then be around to chat about all of those things. So let's start, obviously, with the sort of two pillars of the CMS world. And this is really where I think CMI as a solution and a technology is really important. That in the world of CMS, we have two different pillars of information. On one hand, we have the configuration, and on the other, we have the content. In the world of Drupal configuration, we have these are the things, these are all the feeds and the speeds that the site has. These are things like views, settings, content types, and fields. These are the kind of things as developers a lot of you are making and developing. And then in the world of content, we have the nodes and the user accounts and the comments and the menus people add and the taxonomy terms that people add. And these as a developer, maybe you'll add a few of these, but these are primarily being added by the users of the site, the administrators and stuff like this. And that sort of within a Drupal site, these are sort of mixed together. And for simple sites, this isn't actually that huge a deal, although a case could be made that it is, because you're sort of having one or two people working on the site. But what becomes really tricky with this kind of the difference between the different stuff that Drupal has is that when you're working on big sites and when you're working with managed workflows, you care a great deal about making sure that configuration is the same, that it's versionable, it's rollbackable, and that you can work and develop against it. But the content is something you're not necessarily dealing with in the same way. And this is sort of an issue, and this division is really important. The problem is Drupal doesn't really care about that for you. That Drupal just has a bunch of database tables, some of which contain content, some of which can configuration, some of which might contain both. And that these are different values, some of these tables are created on the fly as you do stuff. And that makes Drupal sort of hard to work with if what you're trying to do is develop a bunch of configuration and put it up without interfering with the content. Because you just can't push the whole database because you'll lose stuff, and pushing individual tables is sort of a little bit of a nightmare. So that's sort of the problem. Luckily, we have Features Module. Features Module was created in the spring of 2009, and it's basically a solution to try to make some sense of these database tables so we can actually have some separation. And Features Module is really great, honestly. I like the solution. I know some of you might have different opinions on it, but I think it helps to solve or try to start solving a really, really important problem. And that's for folks who have used it. I assume most of those in the room have used Features. It provides a UI that looks like this. You can specify various pieces of configuration. It'll export that out to code. And then you can actually use that code on another site or roll it through a version control repository and deploy it. And that's really great. It solves problems. I don't want to put it down. But, you know, much like a lot of things that solve problems, like the House of Duras, that you can have some lovable things but also recognize some of their problems. That Features Module wasn't built to be a sort of catch-all way to store configuration and code. That it was legitimately designed to work with Drupal distributions, OpenHRN distribution, and others to package a common feature, a functionality, a feature to be able to share that across sites. And like some of that's obviously going to include putting configuration into code. And that's what it's used about sort of today. But, you know, I think sort of like Worf's father at Kittimer. I mean, you get blamed for a lot of stuff. That might not be your fault. And I think Features has taken a little bit of that heat. So there's limits. And there's limits also just to what Features can do. It's a contrived project. It doesn't, it can't modify Drupal Core. It has to sort of be bolted on to a bunch of other contrived solutions that might, you know, implement this kind of stuff. That it's constantly trying to keep up with, you know, the various changes that contrived modules and Core has. And it's, you know, that's a hard problem. And it's a hard problem to do from contrived for sure. And it's also a hard problem to do with some of Drupal's sort of architectural decisions. Things like auto-incrementing IDs, for example, creates real problems if you're trying to merge stuff together and stuff like this. So it's certainly dishonored some developers who have had to work with it, which is unfortunate. But luckily, like the dishonor the Klingons would have, it only lasts for seven generations. Features have been around for about seven years. We've got seven versions of Drupal without it. So now we have Drupal 8. We actually have a solution that can sort of work. And I'll turn it over to David to sort of, you know, take this story from starting with the pinball wizard thinking about the problem to some sort of solution. Okay. So back when we started initial development on Drupal 8, there was a lot of brainstorming in the community around exactly what big features would make the difference. That would be worth waiting for for years of development that would take that. And we would be proud of launching when we actually published Drupal 8. And we started off this initiative actually in Denver before the Denver Drupal con. And I had the privilege of working with Greg Dunlap on kind of pushing this along in the forests of the Drupal issue queues on Drupal.org. And he was one of the primary folks that definitely agreed. And this is a little bit of a paraphrase because we couldn't find the original post, but he was definitely a key person. And we definitely need a shout out to him for all the work that he did getting this into core and in the form that it is today. So a lot of what CMI is about is maximizing our ability to take things that are proudly invented elsewhere. What we want to have is we want to use things that are tested and familiar and not just Drupalisms that are in our code. And the key to doing that is that we have to look for every single thing that we're doing and need in core and figure out what can we take from the community, what's already been written, what's already been tested. Who else has tried to solve this problem? So when we started building CMI, we looked at, we basically trashed as kind of foundations for it, anything that was kind of already a Drupalism. We didn't want to use any info files, we didn't want to use a new parser that we would write for it. What we did is we looked at how projects like different Java frameworks maintain configuration, how Jenkins maintains configuration, how Symphony maintains configuration even before we were doing the Symphony transition. And what we did is we came to kind of a conclusion of what we would be able to take from the community and what we couldn't. Before we ever did any Symphony stuff in Drupal 8, we decided that we were not going to have our own parser. Initially, we chose XML because a parser that's high performance and standardized is built into the PHP runtime in many cases. And we wanted to support full I18N for things and we wanted to support comments in the configuration files because one of the key goals that we have is that configuration gets reviewed just like code gets reviewed in these kind of managed workflows. So being able to comment what you put in the configuration can be valuable to development teams that are collaborating. Now, XML gets kind of a bad name because it's very verbose and it can be kind of annoying to work with. And so once we got Symphony into a lot of parts of core and had full access to that library set, we immediately started looking at things like the YAML parser that Symphony uses, which is ultimately the direction we went for Drupal 8. But there was one caveat to the support that Symphony had. While Symphony has a configuration management tool that's back in support YAML, it doesn't support the kind of configuration we need for Drupal. One of the fundamental things that Drupal can do is allow you to configure your site from the GUI and then do advanced things like creating new content types, creating new fields, creating views. You can build a large portion of the functionality of a Drupal site just by clicking around the interface. And Symphony's configuration language was nice, but it required you to write out the configuration on disk by hand, which made it inaccessible to people building more basic sites or even people who are building advanced sites who just like using the GUI to be able to quickly build sites. So we took what we could and we knew where we had to innovate. We had to figure out the right way to meld the on disk configuration that would work with workflows with the kind of ability to configure from a GUI. So the main inspiration for the configuration in Drupal 8 goes back to Jenkins, because it does a really interesting thing as a project that I didn't see anywhere else, which is it has a GUI, and then every time you make a change in the Jenkins GUI, it writes out an updated file on disk that you can commit, you can change, you can reload, you can back up. And it provided this bridge of functionality where you had that kind of really nice GUI configuration, but also a way to track that. And Jenkins does use XML, which is part of the reason why we initially chose that as the format on disk. But one of our other goals that we had to balance this out with was minimal impact on basic users, which is there's always been a goal on Drupal that you can install Drupal to a basic lamp stack and still get all the functionality and don't have a lot of corners cut. So how do you design a configuration management system where people writing basic modules don't have to learn a ton of things if they have easy use cases and people building sites don't have to learn a ton of things if they have easy use cases. So what we did is we built something where if you only have a single environment, you have one install of Drupal, you can make changes in the GUI, they write out to the database, and that's pretty much all you have to do. You don't need to use any of the workflow tools, and none of the way that you work with Drupal has to change if that's your entire world. But underlying all of this in this kind of database and active store is the fact that we have this configuration management API that's intercepting all of the changes you're making to configuration and ensuring that they're in a uniform format that we can integrate complex workflows onto. And so it goes under the kind of software philosophy of make simple things possible or make simple things easy and make complex things possible. So, but we're here to talk about more of the complex workflow case, which is where when you have multiple environments, when you have development environments, you have test environments, you have multiple developers with local working copies and they're doing work on the code. And what we needed is something where we would be able to have the configuration flow with the code. So what we're doing and why that's necessary is that code can rely on configuration in Drupal. You can write code that relies on reading fields that are in content types that you create. And in the same way, the reverse is true as well. So you could configure a view that relies on a theme function that's implemented in your code base. So you can't really disentangle configuration from code in Drupal. You have to deploy them together, you have to review them together. And so what we did is we created something where you could store them together alongside the code. You could create, say, a pull request that contained both the new view and the theme functions that the view would need. And the way that that works is we have this ability to export the configuration from the active store in the database, which is this kind of tree-structured storage of configuration onto disk as YAML, and that goes into the staging directory that you set up. And then that goes alongside your code. And so when you do a commit in Git, you can see the configuration changes you've made and the code changes that you've made. And then when you need to deploy to another environment like Test, what you can do is you can deploy your code just as you normally do, and then there's one extra deployment step which is importing the configuration, which you can do with Drush. And that it's no harder than the current deployment step of doing UpdateDB after deploying your code to a test or a live environment. And then this allows you to do completely automated deployment of the configuration to test environments and staging environments. And then by doing that, you're able to test exactly what will happen in your live site once you deploy there, which means your dry run deployments are much more reliable than if you're manually clicking through the site to apply certain configuration changes or you're writing configuration into things like update hooks that only run once and are not declarative about what you actually want in your configuration. And I wanted to kind of justify why we didn't use some of the other models of configuration, like why there are some Drupalisms to the configuration management API. And I can do that by kind of comparing it against what Jenkins has, what Drupal 7 has, what Drupal 8 has, and what Symphony has. And this deck will be online if you want to go over it in detail for this kind of table. But one of the key selling points of the Drupal 8 CMI is consistency, that no matter whether the change is to something simple like the site title or whether it's something complicated, like creating a content type, adding a field, reorganizing that, creating views that rely on it, you work with that data exactly the same way. You'll notice that with Symphony's configuration and Drupal 7's, when you're doing kind of entity affecting configuration that alters the database, you handle it a completely different way than if you're doing simple configuration with things like variables. And that's gone with CMI. Every time you deploy a CMI, it's kind of a mantra of export, commit, deploy, import. And it doesn't matter what change you've made to the site, it goes through that flow for review, for deployment, for testing. So how do we feel? Is that good? Good direction? All right. So to bring it back into getting into a demo and showing you how that works, that background is really great. This was a long process several years to actually build and design and get this system into sort of the Drupal core. And the sort of heart of the CMI is the YAML file, as David mentioned. And this is the YAML file. There are many like it. This one's for the system site settings. Oh, yes. And that this is basically how the settings and the different configuration gets exported out. So this is what that looks like. In terms of the actual interface, this is what CMI looks like in Drupal 8. We'll show you all this as well. But the idea is that you have some abilities to single import or export values fully for all your whole site import, export values, and then synchronize sort of between that, that's sort of active in the config stores. And one of the things that we wanted with the implementation and core of the interface is we wanted it to be extremely basic because we see this as an area of experimentation and new kind of new development in Contrib where these APIs are available to any Contrib module that wants to work with configuration data to show, to visualize that information, to provide more powerful tools for merging the information, for knowing that what modules are getting affected by that change. This is a very simple one that just kind of tells you what files are changing and what lines are being diffed versus the active configuration. And by leaving that open, we've actually already seen a couple modules spring up in Contrib that you can install on Drupal 8 to work with a more rich interface for this. Keep it simple. It's good for a core philosophy. Let people do the basic stuff. We can extend basic stuff here. We can export a single value. This is again that system site sort of settings. And you can just go in, hit the button, export, pick what you want, and then you actually get the YAML file right there in the browser. If you actually want to go import it, of course, you've got an import function. You can actually go in, select it again, type your name, hit paste, and then hit import. And this will actually bring it into your site. That's pretty cool. That's sort of the base of what we're talking about. The synchronize option gives us a bit more. So if you were to throw it into your sort of staging store, bring it in and have Drupal look at it, it'll give you this kind of diff and say, hey, how do you feel about that? If you like it, go ahead and import. And that's really cool. Like that's the kind of thing that will make, like the extendable and will really make Drupal, I think, a really great CMS going forward that solves a lot of our problems. And to sort of, you know, talk about it in the context of, you know, sort of comparing to features and how you sort of might use this for something more than just the site title, you know, common use case, you want to actually make a blog. We'll talk a bit about this today. But, you know, code until yesterday here for features, if you make a blog type and export it out, you're getting a bunch of different files with a long set of arrays that are sort of managing those settings and all the different information. And the diffs may not even be clean because some arrays may get renumbered and you may compare it against your existing code and it'll look like a ton of lines change when in reality there might have been only a tiny change to the configuration. So one of our other goals with CMI was it should look beautiful in your diffs. If you changed one tiny configuration item, you should see one tiny change in your diff. It's always deterministic how it writes out the configuration files so that it will minimize the number of changes you see. Because if anyone's ever tried to diff features, you get into that sort of feature, StovoCore, where there's like legitimate conflicts and it's hard to manage. This is D8. It's a lot more straightforward. We've got very diffable kind of information. We've cleaned up a lot of the sort of cruft from what the arrays would sort of do. And it's obviously sort of Lexus. You know, just display, hey, we just have the blog, we just have the field for the body. And to actually, to be fair for the comparison, there's definitely going to be some stuff features as doing sort of as well. Like you'll still need to write some additional code to import this sort of in or at least copy it over. But this is the basic idea. This is sort of what you use to push stuff. And here's basically how the straightforward workflow works. You are doing development on your dev site. You're making some different changes. You're kicking out those changes through some XML, or through some YAML file out of either the export or using some Drush commands we'll show. That obviously can go into, this is the file right here, and you can throw it out into an import function, bring it into your live site, and then click a button to import, and you're super happy. Because you've now imported that kind of thing. And this is the basic workflow. It's going to look a lot like your other code, and that's the point. And there's a lot of rejoicing. So without further ado, we'll try to see this thing in action. With the caveats, we have conference Wi-Fi. We have our own platform. We have Drupal 8 Beta, and we have a few other things. But you guys deserve to see the very coolest and newest stuff. So let's talk about it right here. Do you want to try the Beta 1 and the Pantheon, by the way? You can go to getpantheon.com. It'll bring you to a page like this, and you can actually just go ahead and spin up a site. My great site for AMS. And it'll sort of go ahead and make your site. So you'll go and make the site over here. Here's my site. And now we'll go to the oven, where it's already done. And we're now fully deployed. Sorry, it takes a few minutes, and there's a lot to show. So we have the Beta ready. If I jump to the Pantheon dashboard that actually has this, this is the CMI experience. This is the Beta. The only thing I've done here is, obviously, instantiated the Pantheon environments and installed Drupal. I've also exported out all the initial code in the site's default config for having that kind of stuff there. So here's the kind of stuff that becomes really interesting. Also, just sort of quick FY. For Pantheon, we have Dev. We have Test. We have Live. There's sort of a workflow to this. And we also have the ability to support multiple feature branches through Git, but also have their own environments. This is sort of part of the process. So one of the things that you're going to be very interested in doing as a developer is you're going to want to sort of start to make these config changes. And we can sort of jump in and sort of take a specific feature branch. We'll start with that basic case for site name. So we'll go over here to the site name and then go look at that site. And it'll have my Drupal site. It says welcome to the CMS experience. That was what I started with. If I actually want to go ahead and sort of do some changes to actually change that name, I'll do just a normal config change to actually imply that now we're doing this with a managed workflow. So the managed workflow, CMI experience. We'll go ahead and save that. And now what's really cool is this has been saved. We can still go out back to do other stuff in the interface to actually do more comerc figuration. But we actually want to go ahead and push this out. Push this out to code. So what's really excellent also is that all of this kind of stuff actually has the ability within site of Drush to be used as well. And we have site aliases set up to particularly find that particular environment. So we can actually go access using Drush 7. That environment and just to show you there's nothing too crazy going on. We can run status. This will actually just bring up Drush. But the command we want to use for CMI is config-export. And what that's actually going to do is that's going to go out and tell that Drupal 8 site that it should export out the config to sites to fall config. We'll go ahead and hit yes. And that'll actually go right here to this environment. So we'll go ahead and refresh it and you'll actually see right here that we have the system site YAML file that's been exported. That's the only thing that's different. So that's the only reason it's telling us so we can say change the site name. And we'll go ahead and commit that. So that's now actually going to be in a branch of our project called site-name. And it's going to actually have that particular YAML file change. That's the only change that's done. So that's available in that get and you can go ahead and pull that down. So that's sort of fall so far. Makes sense. All right, cool. But now what we want to do is we actually want to go ahead and we want to start testing that change, right? We want to actually see what that's going to look like. I guess that's going to look like on the different environments. So we'll go ahead and see. We have that site name. It has one commit ahead of the master branch. So let's go ahead. We can merge that into our dev site. This is just going to run a standard get merge branch, merge operation to actually bring in our dev site and successfully merge. That's great. And we can go back. And we'll then go to our testing site, which is what we actually want to look on this kind of thing on. And so I'll bring up the testing site here. You'll see this has the old site name title here. But if we are to go, you'll see in the test that we can actually bring in that changing the site name YAML file. And we can go ahead and do a pull on that. And that'll actually deploy that change to test. So we've taken that YAML file. We've generated it through Drush on the feature branch side. We've pushed it through dev. And now it's actually on the test site. And it'll go ahead and deploy. And so we'll see it here in the log change the site name. Which is pretty cool. And now with inside of the CMI, we can actually go in to that same configuration management section that I showed you a picture of before. And we can actually start to see with inside of that that we actually have under the synchronize option, since we've pushed something to the config directory, that there's this system site file that actually has some differences. And we can actually do a quick diff to see those differences and see, okay, we're updating the site name. That's pretty cool. We'll go ahead and import that to actually accept that change into the site. It'll go ahead and do a little bit of an operation. And then we can actually go back to the site. And assuming that all worked, we'll actually be able to see that change sort of there. And that this is basically the kind of, I should say the managed workflow CMI experience. Okay, perfect. So this is... So like, and this is the kind of thing, honestly, that I think both of us expect D8 developers to do on a regular basis. That as you do configurations and other kinds of things that are necessary to make Drupal 8 the amazing, awesome sort of sites that you all want, that you're gonna be making these kinds of settings. You're gonna be committing them, and then you're gonna be pushing them forward and getting that kind of thing. And because all this is tracked and get, you can have multiple developers making different changes to the settings that then get merged together. If there are conflicts, you handle them exactly the same way as you would handle a code conflict. You can review them the same way as you review the code that's going out. And the power of the system really becomes obvious when you start working with the content types and fields and things like that. Because this site name change, we could have thrown that into settings.php before and deployed it that way, although it would have required editing the file and altering the variables array. But this is just a nicer workflow for that. But for the blog system, this is all kind of brand new. Yeah, set different feature branch, different site, and this is actually, you know, still has the old title because we haven't updated that yet. But, you know, this is something that we could use to say, you know, say I was changing the title and David was working on setting up a content type. He could go in doing the kind of stuff that you would do and say, okay, we're going to go create a content type for this new blog. We'll call it blog. We'll say a piece of news for our fans and followers. And we'll go ahead and save that. And we could add additional fields to this. We could add additional information. No big deal. And that's actually going to go and... Let's add a field, actually. Oh, sure. What kind of field do you want to add? Okay. Awesome. Or not. So, you know, you write a lot of blog posts if you're a blogger. Some of them are going to be, you know they're awesome. Some of you don't know, of course. But, like, and some of you know it or not. But this is the field you can have if you want to have it awesome or not. And then after saving it, let's actually drag it up because you can reorganize the fields too and that all goes through CMI as well. Oh, great. So we've awesome or not. We have it and... So you're going to manage form display? You're going to manage the editing display and the view display of all of these different content types as well. So we're going to see a bunch of different configuration things come out of this. We'll see the original field. We will see a configuration file that relates the field to the content type. And then we will see updates to the two configuration files for the content type that specify the field order for editing and for viewing. So the kind of changes we're making here will be affected and you can view them all as a diff to see exactly what's happening. Yeah. Cannot do this with Dress 5. It'll actually work because it doesn't... It'll just send the command to the server. Dress 7, though, works fine. Okay. So I did the same thing we did with the site information. I did it for the blog. And so we actually go back to that. We go back to the blog system environment. We'll see a few changes that have happened. There are different YAML files that we had talked about before for the different fields, for our Boolean field, for our body, for the configuration order, as well as the node type itself. And I can actually go ahead and commit that as the sort of full-on blog system. And this could also include, as this commit, this obviously is the YAML files, but this would also presumably include some CSS that might go in with the blog system, maybe some additional modules that you're using to build additional fields and help function code to do additional stuff. The idea is that you can actually have a full feature branch with an entire blogging system from the design to the functionality that's all sitting there in a series of commits. And that you're able, as a sort of lead developer, to look and say, okay, how's that blog system working? David's working on it, getting it all squared away. And once it's sort of ready to go, then you can look at it and say, okay, that blog system's great. It's sufficient enough to actually go and merge into our sort of main development system for testing, and you can actually then go through that workflow. And now you'll be able to preview real pieces of functionality instead of saying, okay, well, here's the code you'd have to use to look at it, but also here's a list of config changes you have to make in the database sort of in a list, or here's a feature that you have to install on Reaver that this is a little more straightforward. So we'll go ahead and get that up to the dev, and we'll again throw this into the testing environment. So what's cool here is I'm not going to show you the course the same thing, because that would be sort of boring, but if you're not interested in sort of using that UI to do the synchronizing, like, you know, hey, we just looked at this, this is pretty cool. It's also possible on the Dress side to actually, like we had the config export, we can also do the config import. So I'll jump over to the sort of alias for the test environment, and I'll do the config import, and as soon as this gets deployed, this will actually sort of run that same kind of command that you would run on the UI to actually do the synchronizing or the import, but instead it's actually going to be able to run through Drush, which is quite excellent. Just as you saw before, if you're going to do this with Drupal 8, you're going to need to use Drush 7, which requires Composer and some other stuff to do it, which there's pretty good directions to get that all set up, but you can run a config import, which you see down here, and this is actually going to go ahead, and you can run those different files and say, hey, do we want to actually create this node type? Add these fields and put them in this way, and obviously we do, so we'll go ahead and say yes to that. And then what's really neat is that sort of, that'll go through and that'll do all the different sort of config and importation we need, we know it's successful, and now we can, with a fair bit of confidence, go out to that testing site and now that we're inspired from this talk and the rest of the talks at DrupalCon, we'll say, hey, let's go talk about this kind of stuff, we'll go ahead and we'll start adding content, and we're obviously going to give a blog to do that. So, that sort of is pretty nice as a way to sort of actually get up and running, and we'll obviously make it awesome and go for there. And that's really cool because we've tested those things, they look good, and then if we actually wanted to deploy those to the live site, we'll just go ahead and hit, you know, pull code from testing, and then we would just run the import on the live site, and then we would be able to change, now at the same time, the site name, and add the blog system at once, and I think that's pretty cool. So, hopefully that was cool. Apologies to any one direction fans in the room, that was not approximate cause of the fall of the Roman Empire, but okay. So, let's get back to the crazy. Okay, so that's basically the, that's basically the sort of demo of how it works, that's the kind of stuff that you can check out. Other managed workflows can use it the same way, we show that in Pantheon cause we know that pretty well, but the idea is that it runs through version control, you can use it to deploy and if you have cool ways to make feature branches and cool ways to have test environments, you can basically get all of this kind of stuff. So, I'll turn it over to David to talk about some of the more fancy stuff, including some of the Drush integration and the actual, some of the config and state APIs. So, we showed off a couple of the commands for this, but there's a whole suite of commands that are now available in Drush for setting individual configuration items. Just as Matt showed in the interface for pulling down an individual configuration item, you can do that with Drush as well. All of that makes it scriptable. You can even use the config edit, which will pull down the configuration, open up an editor, you can hack on it, you can save it, it'll actually load it into the site and perform all the kind of necessary operations to update the config of the site and then do that as part of your kind of working copy, get workflow. But, we didn't just want a great end user experience, we wanted to have a great developer experience, which also goes with that philosophy of simple things should be simple and complex things should be possible. So, when it comes to basic configuration, variables are dead. Variable set, variable get, done. The way you do it now is with the configuration API, which is actually still extremely simple to use, the main difference is you basically have to scope the configuration, you have to either use your module name as the kind of scope of the configuration or some object that your module is working for, or working with. So, for example, for views you might want to have at least one configuration file for each view so that there's a logical unit to be reviewing and moving around. So, the way you do that, just to get a piece of configuration is Drupal config and then you give it the scope you want so that would be, say, system.site which is the exact same name you're going to see on disk, so there's a very clear relationship between the API and the files that you eventually see on disk. And then you can just use that object directly if you want to and do something like debt name which is going to get you, the configuration management site name. And you can also use that configuration object that you instantiate through that factory and use that to set configuration and save configuration as well which is like this. It's a fluent API so you can have nice easy to read code for saving values and in this case it's saving to the system.site configuration a new name and then saving it. And the reason why save is important is because you might want to make multiple changes at once and have those all coherently go into the active state and not have just one thing change and then one thing change and one thing change which might break the site. So the state API allows you to set kind of environment specific things for say your development environment or a specific feature branch and this allows you to override specific configuration items so that if you want to use something like a testing API key for a service and then you have a live API key, configuration management allows you to have one apply to one environment and one apply to another without having to resort to the traditional kind of if statements in your settings.php file that make the variables be different. You can also override settings using the confere still so there's sort of a way to get back that kind of settings interface that you might have liked with variables if you want to set specific things or use a more complex algorithm for what values you're setting them to other than just kind of the environment that they're in. And this is of course again a case of simple things, simple basic environment testing live things and if you have harder use cases we still support them. So that's sort of the meta overview. We know there's going to be a few questions by default so we'll sort of start with those but we're also we have maybe another 15 minutes or so less so we can run through some people's questions here. I did want to go over one other thing in the API before we open it for questions. Another case of kind of supporting complex things and how we work for things like fields and entities and content types is that you can also write hooks that trap the events of configuration getting loaded in and then notice a certain events happening and then respond accordingly and that's how you can do things like add new database tables if configuration gets loaded that requires them and that's part of why we have the export import workflow because there's some kind of configurations like fields that you can't just kind of make it so by having a new value in the configuration you have to do some events to respond. Gotcha. So let's start off talking about some things, things like features in D8, things like using this now, other country models people might be interested in obviously most important who dances in our video is Chris Ruple so I think he's talking about picture flow, fill or something but anyway manage workflow and see what I'm going to be excited about. For people so obviously this is in D8 and this is something you'll use for D8 for most of your development. If you're interested in trying some of these concepts not the exact same but some of these concepts like having an active and a sort of staging data store there is a module Drupal or project configuration that tries to do some of this kind of stuff. It's still like suffering for some of the limitations you have in Drupal where like you're a contrived project you can only do so much but this is something if you sort of want to play around with some of these ideas now it's a really good way to deal with that so that's something we sort of recommend people check out for sort of D7-ish kind of stuff with all of this. Next question is so like when you have like settings and stuff you're like adding like the site name but how do you handle multi-lingual stuff? So we're Americans we don't really know different languages sorry sorry that would be more interesting. But with inside the YAML file like although there's really nice multi-lingual support CLC there's actually like individual language codes right here that can be used so the same kind of YAML files that you would do to like specify a site name you could actually start doing language you know sort of different versions of that kind of stuff and there's probably going to be and there are sort of already additional tools to help you generate these files manage them and help with the translation kind of stuff. And just like the other features in terms of simple simple complex possible you don't have to learn anything about the multi-lingual support unless you actually need it for your site. Yeah so that's really cool and I think this will also help to sort of level up a lot of people's sites with some of the multi-lingual stuff can be sort of tricky this helps to help to do a little bit about it. With respect to features for Drupal 8 so like we talked about the beginning like features module helps to do a lot of stuff right now a lot of people use it sort of what is this going to look like in Drupal 8 and I think Mike Potter said this but this is sort of the sort of current vision ish on features which is like there will be a Drupal 8 version of features that there's going to be a 3x branch and it'll sort of be set up to sort of do honestly what it originally was supposed to do which is create a set of package functionality that you can use to like sort of migrate between sites and actually have a blog system or an image gallery or this kind of stuff and except they're not going to have to write this version to do the forensic extraction and then application of configuration which was most of their code from before and that you know those you know yeah that like it'll be a much smaller you know sort of easier to use library it'll focus a little more on UI and on you know sort of trying to create sort of the interfaces to actually work with these features but they won't have to do all the crud which I think is really important and it's something that you know you know I think the maintainers of features will be very happy to sort of get rid of but that's something if you are using features and you have sort of other use cases or features and just like you know having config and loading config a lot of that stuff will be there check the 3x branch for information about that in terms of sort of some of the D8 config modules these are only a few of the ones that we're aware of there are other ones for sure being developed but you know as we talked about D8s can CMI core system it tries to be sort of simple it handles the important cases but it leaves a lot of room to be extended and modified by other stuff and so we'll increasingly see other projects that work with it integrate with other managed workflow kind of tack integrates with other kind of stuff and other projects if you have a D8 site and are looking to sort of play around you can check out these are obviously being developed along with D8 so you know don't expect super polished but it's something if you're looking to do some cooler stuff with CMI this is a good place to start so the configuration read only mode module is really cool because this basically is going to lock down your live or production site from having the ability to change any of the configuration that if you were to like install a live site and then you try to change the site name it won't let you do that and the importance there is that that's actually going to force legitimate developer sort of adheres to this best practice of any config changes we want need to be in version control before they can deploy it out to production sites and this will actually in the UI sort of force that to happen and that's something that I could see certain projects or certain development firms or organizations adopting as part of a sorted best practice for using CMI with D8 also we have the config inspector module that actually helps to sort of do a deeper dive into some of the different you know configuration and some of the schemas that come with it you know we obviously have that cool diff in the new sort of core product but having additional ways to visualize and inspect that's really helpful and that's something that I think if you're sort of looking especially to debug some CMI stuff for sort of seeing you know sort of all of how it works this is a good place to sort of get in there other modules is there's a configuration log module that actually will sort of you know hook into some of those sort of CMI systems and actually kick out just a record of what's being changed in the site so maybe a production site and you you're not locking it down but you're interested in sort of seeing what was changed or as a developer you're sort of you know hey I'm trying to keep a log of the different stuff that actually has to be you know exported out and such like this that log will actually sort of help make that happen which is pretty cool and then there's the configuration tools module as well that has sort of two different functions in it that are both pretty relevant to CMI and Drupal 8 you have one option that actually will just kick out as you sort of make those changes instead of just logging it it's actually going to push it out to a specific directory so if you'd like you know didn't want to sort of go through that Drush 7 config export process you could just point your stuff at your sort of staging store and you could sort of throw it in and then you could sort of commit it and get as you like it and that's a sort of cool way to say hey I'm you know developing a config really well I'm just going to have it sort of auto export all the time which is pretty cool and that also sort of with inside of the sort of second function is this get configuration it also allows you to actually push off those configs into a separate repository where you can actually commit those and I think for the purposes of how we're sort of thinking about this I think that the code in the commit the code in the config should probably belong in the same repository just for sort of you know the ease of use but if you had a separate repository and this is sort of the idea here to actually use the same tags for both so that you can have a situation where if you're like rolling out a release and it's got this tag for the code in the config that you're then able to roll back because that's one thing that features can be can be a little bit tricky with terms of rolling back because you sort of have to do a bunch of reverts and other stuff to actually move backwards CMI makes that makes that a lot cleaner and a lot easier to use so those are some ideas I don't there are probably other modules that people in this room are aware of that we'd be happy to chat about as well but that's sort of the general overview with some of the high points we have and I think we're sort of at this point open for some questions people have about how CMI works and how best to use it for your projects going forward there's a microphone if people could line up there that way everyone can hear the questions we can also repeat as well so you showed how to add a field into a blog post in the configuration but if you wanted to take the field back out in your development how easy is that would it deploy the deletion how would that work what you would do is you would delete the field you would re-export configuration I think it deletes any files in that directory that aren't part of the current exported configuration and then because it's declarative when you deploy it to the next site that that configuration would be gone and it should remove the field I don't know if it actually deletes the database tables that's the prerogative of the actual fields implementation but you can respond to configuration events like that and delete things just as much as you can create ones okay thanks earlier slide earlier on you made the distinction between configuration and content and I noticed that taxonomy is over on the content side probably the most debatable one of that slide so then you can imagine a case where there's some taxonomy that's user generated and some taxonomy that's actually more like configuration how does CMI handle that well since taxonomy is treated entirely as content not configuration one option you have is that you can create fields that have fixed sets of options on them and then you can the actual options are going to deploy as part of configuration and those will be totally managed that way they'll be visible in tools like views for filtering the items were well past the era of Drupal where the only way you could kind of filter and sort things was taxonomy so I would just advise using taxonomy if you need to have kind of iron clad control over the options that need to be available for something so this paradigm that we're looking at here is pretty much the way that CMI is handling the distinction okay great thanks I would like to ask if this thing is bulletproof so if I take the most complicated Drupal site in the world copy its modules it's thin and do a full export can I import that into a clean installation and have the exact copy that's the goal anything short of that is a bug nice and now beta obviously stands for bulletproof so yeah and that's I mean that's the reason to bring it into core is that you when you put it in core you can then manage all of the different config all in the same way and so as long as you're the complicated theory of building is implementing on top of those sort of standard API's like you should be fine there'll be edge cases this is new we're all sort of working through this so but that is absolutely as David said the goal of getting it right what do users on the live site see while it's importing the configuration like can they get it in a half deployed state or do they get a maintenance page or what I'd say there's about as much risk updating the configuration as running update db where you could see schema changes from that there could be new columns created there could be things that lock up a table in general it's probably a little bit safer because at least with configuration we have a model where it kind of understands the dependencies of various pieces of configuration applies the parts that need to be applied earlier earlier and the parts that need to be applied later later so each configuration change it makes should have as much interruption to your site as if you are going through the interface and clicking through and making all those changes yourself it just does it a lot faster in the configuration exports in the YAML files I see the UU IDs and how does that work when you export and use it in another site or write your own YAML files which don't have UU IDs yet and how do you work with that if you wanted to write your own ones that had UU IDs I would actually generate UU IDs and put them in because they're a field that needs to get filled in the the human editability and creation of these files was not really the primary design goal they're designed to be very readable and auditable in terms of reviewing changes but I don't know that I would go from scratch and write configuration for a module unless I was very familiar with it or automating that in some other way but UU IDs are great because it means that instead of using things like arbitrary indexes in the database where we have an incrementing key and developer A may create the third field on something and developer B may also create a third field and you want to merge their changes it means they actually can be merged without a conflict instead of having a kind of fake conflict on just the ordering of the items so that's kind of a goal going forward with a lot of things in Drupal 8 is determining like when is the actual ordering important and when are we just trying to come up with a unique identifier if I take your blog example it's a a future for a website like a recite for a future can we imagine to have like a central repository for these kind of futures when I can just who will put it in my Drupal that is features 3.x that's exactly what it will be is provide a tool for taking sets of configuration creating repositories for those kind of features being able to pull them onto sites and apply them packaging subsets of the configuration and making them available in libraries and then making them deployable is something that is designed to support but not actually do themselves but as you remember at the beginning of future there was this thing called the future server future repository I never found one of these it really works everyone turned out to use features more for doing what CMI is designed to do than for creating features repositories hopefully features can have a chance with this to go more back to basics instead of trying to sort this use case I think features you had to fight with it a lot to get it to do the basic crud operations for this config that you would need that because the CMI stuff is much more robust you can put out a sort of blog feature or something of that nature you can support and have people work with and you're not going to be dealing with weird diffs or like reversion problems or stuff like that I mean it's still going to need to be sort of impudest to actually create these things and share them but the actual sort of work work to not only create them is going to be much less but the actual work of maintaining and having people use them and not have problems will be less and I think that will help a lot just from getting all this kind of stuff stuff rolling and so hopefully we will see folks who are like publishing their recipes like this because it really won't be, it will be as hard as going in and clicking and setting up the kind of site you want and exporting it and then you know all the config is going to go not some event you have to sort of work with it you can also do kind of quick and dirty features by taking some of the ammo files and then committing them to a module and then what we do when you install the modules we copy over the ammo files that are packaged with the module as the defaults for the module so that's how we handle defaults in CMI is that you can ship those files with it and I think you could ship any set of the ammo files with your module and then have those install when you install the module and I think you'd right have an almost empty module and just have the ammo files in it and that solves a huge problem with features which is sometimes you want to set config and let people change it and not have it overwritten sometimes you don't want them to change it and CMI provides some of the better options for that so we got to help futures model push it absolutely, if it's stuff you're interested in check out that 3x branch as it sort of gets developed and worked on and then makes some CMI configs and share them post them on the blogs, post them in Drupal Oregon, hopefully we'll have some cool servers I am really hoping for a features in Drupal 8 that is focused on providing features that you can use in Drupal thank you about configuration that you still want to edit on the production site and what the workflow around that is because with features now you can select what you want to be as part of features and you can leave other configuration elements alone and you can do that with config management the active store for the kind of configuration running the site right now which is what changes when you go into the GUI is managed in the database as kind of a store of what is active configuration, your yaml files on the production site may not be writable you can still alter the configuration on a production if you want to allow it depending on the modules you have installed or you can even write a module that didn't lock down configuration for everything but lock down configuration for certain parts of the namespace and then once that configuration changes you can use tools like the sync tool or drush to find out how the live site configuration differs from the one you deployed to the live site and you can reintegrate that back into your development workflow so that if someone created a new view on the live site you can pull that back commit it back to master and then have that be part of your future deployments so not everything needs to be in a yaml file correct in fact if you have a single Drupal website and no workflow you will probably never touch yaml files maybe one more question I just had two quick comments one on the UUIDs so one way to think about them is to carry that config forward because of the UUIDs you have to be starting from basically the descendants of a single site or single install so it's not trivial you can't sync config across two different sites that's basically what you have to use that features before so just to think about UUIDs basically mean these are the descendants of my original install the auto generated UUID and I can sync in that hierarchy of descendants sites but not across sites the other thing menu links Daniel wainer actually wrote a config backed user configurable menu link module so if you want things like menu links to be a part of your configuration you can actually do that already yeah and if someone really wanted to do that for taxonomy they could of course do that as well awesome well that thanks everyone for paying it oh one more okay we'll do one more question sorry last question I'm not sure if it's possible I hope so if you develop a custom module a new module can I tell arbitrary tables that I have installed with the module to get into the configuration so the you wouldn't do it that way what you want to use is the configuration management API which we had it had in the deck if you want to I think it's a little forward from where we are right now so you'll use the API which is like this so you'll basically do Drupal colon colon config and then you'll have kind of module dot my module and then you want to do get and set on that and then if you do it with that it will just work with configuration management awesome cool well thanks everyone for paying attention have a fabulous Drupal con