 All right. All right. Welcome. Everyone try to get the energy up. Hello. My name is Matt Cheney. I work at Pantheon Systems making awesome development and hosting platform for Drupal sites. Hola. Me llamo Emily Burns. Yo trabajo por Face2 con muchos de las clientes en los estados Unidos y eso es mi 6 evento en América del Sur y Centroamérica. Yeah. I'm super excited to be here. We were chatting earlier. I think between us we've been to almost every Latin American country. We've been down to Latin America 15, 20 times between us and are excited to bring some energy to Bogota and teach you all a little bit about one of my favorite topics, which is the Drupal 8 CMI system. So we're going to give you sort of an overview from Molly about sort of some of the problem spaces that she's seen in terms of using configuration in the UI and how that can get messed up when you deploy it to a production site. And then I'm going to talk about some of the explicit interfaces and other kinds of screens and technologies to actually use this yourself. We'll conclude with a live demonstration using the conference Wi-Fi and the latest Drupal 8 Beta. So cross your fingers. Do you have a tether rack up? And we'll be tethering off a phone. But we did it earlier. It was pretty awesome. So hopefully all joy. Then we'll do some wrap up questions and some other stuff. But the hope is you leave here in the next 50 minutes with an understanding of how CMI works in Drupal 8, some of the reasons you'd want to use it, and a really clear demonstration about how you can sort of take this stuff for yourself and have a really good time with it. Bueno, es un placer estar aquí. Yo me voy a tratar de hablar poquito en español y poquito en inglés. No estoy segura de si puedo hablar totalmente en español y porque la orienta es poquito mixo también. Bueno, me voy a hablar poquito de mi experiencia en Drupal in relationship to configuration management. This is basically about keeping the chaos out of the code base. And when I've worked in Drupal through being a content editor, being a project manager, and now running sort of large accounts with many different sites. And one of the big themes that I've seen over the years is that when you have a system like Drupal and you have a lot of different people doing a lot of different things, there can be a tendency towards things that you can't always control. And so configuration management as it's been built out in Drupal 8 is an amazing solution to a lot of the problem spaces that we've seen in previous versions of Drupal. And I've, coming from sort of the business side and the content side, I'm really excited to see kind of how this all plays out when people start to use it more. So to sort of talk through kind of the past experiences, I'm going to kind of talk a little bit about what it was like before configuration management, modern configuration management. So this is sort of the, you know, we're getting ready to launch. We have our stuff on the dev site. And we also have our stuff. We want to push it up to the live. Como puedo mover la código allá allá? Well, there is a mixture of things. You could push up some of the code, but there were certain things in the configuration that would have to be switched manually. So communication process and documentation, and actually people working together was a big part of making some of the changes from a dev site in Drupal to go all the way up to the live site. And this worked well for many people and people had their systems and their ways of doing things, but at times it was definitely, you know, could have some issues. So I don't know if anyone's ever had the experience of putting their site in maintenance mode and making a whole bunch of changes on the live site after they've seen it on dev. Has anyone ever had this experience in Drupal? No, hands. It's a real race against the clock. You're trying to get everything done. You're going sort of, cada uno en su lista para ver si pueden hacer todo, hace el tiempo de lanzamiento de su sitio o su feature. So it's very, very stressful and it's funny if you guys know and sort of hard to always get everything right. So what were we doing detrás de la cortina de la maintenance window? Well, there were a lot of text files. TXT, all of the configurations from views, people would export them, save little, you know, zip folders of what the configurations were to do. That was a big part of it. Views, obviously, familiar with views? Yeah, see, okay, bueno. So many amazing options in the views module, but if you're changing a feature on, you want to push up the view, you really have to get those exports. Another one that I remember a lot was taking screenshots of the block window. So we would go to the blocks page and just take a big screenshot of what all the settings were and make sure that that was emailed to the whole team before we would go ahead and do launches. So these were all tactics of managing configuration on sites and platforms prior to where we are now and we'll be seeing some of the magic coming up in the demo. So this is obviously from my perspective, I was managing close to 300 sites at one point and so this was a huge pain point for me. So when I started to hear the inklings of configuration management coming out, it was extremely, extremely exciting. So what were some of the things that could go wrong? You know, there's a lot of boxes to check in Drupal and as many of you guys know, modules put boxes in different places in the admin interface. So there could be a box in, you know, settings and not a box in, you know, another section of the site. And if you don't know where that box is or you check the wrong box, that could be an issue for your site and for the stability. So like that elephant, elefante que están en el edificio se puede causar muchos problemas y no es necesario arreglarlo, si, me voy a continuar en inglés. So yeah, there could definitely be a lot of collision. I'm going to tell a little story about one of my favorite collisions that I had with a configuration issue. So does anyone familiar with this setting and views or this type of a query? Anyone? Okay. Well, for those of you who aren't familiar, what this does is essentially makes a query to search everything on the site in a particular value and then randomize which thing you're going to pull up and show in the view. Now, as many of you guys may know, that is a very expensive or carro query for the database. So we had a site launch and someone was, you know, setting up a view and thought it would be really nice if it randomly showed a message from a music fan. Except the site had something like 200,000 users and the messages were upwards of, I don't know, several hundred thousand and so every time the page was loading it was going and picking up a global random and it actually caused the site to go down. No one knew what was going on and then we went and audited all the configuration in real time, chased down the queries and solved this. Now, we were able to, you know, put some cache settings on the individual block but the sort of moral of this story and the configuration is it only takes one check box of something that sounds like a good idea in your system that someone makes on the live site that could actually cause your site to be unstable. So it's definitely about governance but it's also about systems that make it easy for you to stabilize your configuration and propagate them through different environments. So what is kind of the overall shift that's happened here? We've moved sort of in the internet from a bunch of static sites and now we're in this much more dynamic system where one check box can, you know, dynamically generate a list from a database as opposed to just a static list that we're putting up on the site. And so with these kind of larger systems with many more variables, many more levers, many more check boxes, it's really, really important to have processes and things in place that can help us kind of stabilize and track all of these different variables. And just to sort of kind of speak a little bit about this shift, you know, Dries talked about the shift from pull to push, which I think is a shift that's coming in the future. The shift that we've kind of been through in the last 10 years is sort of shifting from a truly static web where, you know, people are updating their files with FTP. It's the same HTML over and over again to a dynamic web where actually the markup is being generated and coming through the dynamic databases. So this big shift has definitely led to an increase in a lot of the sort of potential energy, well, kinetic energy in the system. So if you guys look at sort of this example from physics, we sort of gone from, you know, a system that, you know, has lower kinetic energy to, like, much, much higher kinetic energy with all of the different variations. So that's definitely, I think, a big part of why it's important to learn and understand that configuration management because, again, we are trying to launch and create more stable sites. So I'm just going to walk through a little bit about kind of how I've seen the evolution of Drupal through these different phases because I think that there's been so much, so many baselines that have kind of come out of the different versions that have sort of led us to where we are now. So I think Drupal 4 and Drupal 5 was really about kind of finding these dynamic systems and understanding how they work together. There's a lot of work done on views, a lot of work done on some of the underpinnings of the configuration that we all know today as part of Drupal. And then as we got into Drupal 6, there was larger sites that were using it, a lot of distributions. There were platforms that centrally managed sites, sort of techniques for managing install profiles so that you could have configurations that could be spun up in multiple places. We had tools like Agur come out where you could kind of spin up different sites. So people were starting to think about ways in which you could make the configuration more standard across different versions or different instances of Drupal. And then, of course, a big focus on sort of process of management. So DevShops all working together, how do we launch our sites, getting our lists together, getting our text files. So the real business process was also sort of a big part of that. And then moving on to Drupal 7, we definitely have a pretty robust way of managing configuration. There's kind of been some integrations with some other tool sets, things like Jenkins, which I think we'll touch on a little bit later, as well as kind of automation of pushing code up through the environments. But we still have sort of the central issue of kind of the fact that some of the modules, like features, which we'll talk through later, are kind of bolted onto Drupal 7 kind of almost after the fact as opposed to being built in from the ground up, which, as we're going to see a little bit later, the Drupal 8 CMI really is integrated into the core of Drupal. And so that's Drupal 7. And then now we have Drupal 8. And so I've actually been working on a Drupal 8 project. We're doing some work on beta. And then I was talking to the developer and I was like, do you have any thoughts on how it's going with CMI and what that process has been like? And he said, it just works. It's just great. It's been, and I was like, really? Okay, great. And it's true. I mean, having these systems baked into the core has made a big impact in sort of our ability to tackle and manage this migration from Drupal 6 to D8 with Memorial Stone Kettering. So we're really excited to kind of see that through in the coming months. And it's been amazing to just see how the system that everyone's worked so hard on is actually kind of coming out into the world. So this is definitely really exciting. And then lastly, I feel like we're, like, again, it's just working for developers. We're starting to see the CMI architecture that's now under Drupal 8, I think, empowering and improving the developer experience and being able to bring in developers from other programming groups. Like, you know, the larger PHP community can kind of come in with some of the standardizations and some of the processes they already know. And we're seeing really great tools for module development, like Drupal Console that was developed by David and Jesus. So I think we're really seeing a lot of that as well. So hopefully that is a good kind of background of some introductions of why configuration management is really important, especially from the sort of non-developer side of things. And I will turn it over to Mr. Cheney over here to talk through the ins and outs. Awesome. Thank you, Molly. So sort of to take a step back and talk about what sort of the technical problem is that Molly's talking about with her work, that there's sort of in Drupal, there's two pillars of the CMS. There's the configuration, which is the content types, the image styles, fields, views. It's the settings that you sort of configure to make the site function the way that you want. And then there's also the content. These are the blog posts and the user accounts and the comments and the things that are being added on a regular basis by users. And what's really difficult about this is that the configuration is something that you usually do in development because you're trying out things and you want them to work correctly. The content is something that usually you do in production because your editors are adding content, your users are commenting. And that these are two really different things in Drupal, but they sort of function together. And the problem here is that Drupal doesn't really care about those two differences on a data level. These are all the tables in a Drupal site or my particular Drupal site. Some of these tables, as you can see, are content tables. Some are configuration tables. But there's no real way to identify which one is configuration and which one is content. And this makes it really difficult to do the kind of process that Molly and I have been talking about with being able to use something like CMI, to put configuration into code and have it work in production. Because an easy solution you might think is you could just copy the database, but doing that, of course, loses your blog posts and your user accounts. And trying to copy just specific tables within the database while maybe possible gets to be really difficult and is something that typically isn't done. So this is the problem. Luckily for a lot of us in this room, we have the Features module. This was created in 2009 for Drupal 6. And it was basically designed to do a few different things. But the thing I think that it gets the most used for is to actually try to export configuration to code. So I assume a lot of us in the room have used Features. I've used a lot. It gets a little bit of a bad rap because it can get a little complicated. But I think it's really helpful for a lot of people because it solves this problem of having configuration in dev and needing to reliably put it to production. But here it is. It was a game changer for Drupal. This is the UI for it. And this really ushered in a world of what's called feature-driven development where developers who were disciplined enough were able to only configure on dev and push all of their stuff up with feature. And it generally works. I mean, I've seen it work on big projects. It has some problems, but it is a good solution for what it was. The problem here is that Features module wasn't intended for a sole purpose disoring configuration. That's something that it does. But it was really used to package up a feature, like a blog system or an image gallery. And it was developed initially for Open Atrium, which is a very excellent Drupal distribution, and found its life with configuration storage. And that because it's a contributed project, it can only do so much stuff to Drupal. There's a lot of hooks it can use and stuff it can integrate with, but it's limited. It's not core. It can't enforce standards that everyone follows. And so if you see and work with Features module, it has to treat individual other Contrib modules, like views, differently than it might treat other kinds of stuff. And that creates inconsistencies because not only do you have different kinds of code doing the configuration export, but as Contrib changes in different ways, how it exports its config, Features has to try to keep up and it gets a little crazy. Plus Drupal 7 also has some just straight up limitations with how it's structured, including not having unique identifiers for a lot of things that you might want to use unique identifiers for, and so Features has to work around it. Oh, I've got my Star Trek picture. I love Star Trek. This is Commander Worf. He's in front of the Klingon High Council, apologizing for some actions at Kittimer. But I think what's really interesting about Klingons is that Klingons, when they get dishonored, they, that dishonor will extend for seven generations. And I feel now with Drupal and Drupal 8, we can be free of some of these assumptions. And we can have it. So this was sort of the world that we lived in and now we get to a point where we want to, we want to remove that sins, get that honor. And we have this pinball wizard named Grave Dunlap, who was the lead architect for the CMI system. And that in March of 2011, Drupal 8 was sort of getting specked out, people starting to work. Greg was like really passionate about doing this configuration management stuff, worked with David Strauss and a number of other really brains in the Drupal community, got Dries to bless the process as a full-fledged initiative. And this was one of the first initiatives to actually get done, where they actually built CMI, got it into core, and then everybody else got to use it. So it's been several years where CMI has been worked on and improved, and that's been really great. But I think the design decisions here were also really important. That one of the really important mantras for Drupal 8 is to try to use code that's invented elsewhere that's really good, and try to look at systems beyond just Drupal to solve problems. So one of the things that was very important in Drupal 8 is to use a standard kind of file. We ended up with the animal files, which are used by Symphony, which will work really well, obviously, in our Drupal 8 world, and that we can sort of take that approach in a very similar way to have configuration. We also took a lot of inspiration from the Jenkins system, which is a really great computer integration workflow management tool, and one of the great things that Jenkins has, it's one of the few projects it does, is that you can do configuration in Jenkins in the GUI as an end user to make some decisions, and then it will write that configuration out to code in a way that can be saved and versioned and deployed. And that is really the key process of CMI. You don't want it to be a developer-only tool. You want it to be something that end users, who are just admins of a site, can do config changes, but still use the power of version control, and that's what Jenkins does. It also takes this concept of declarative, the declarative configuration, where instead of how features works, where it sort of tries to push in a data type that could have some overrides or some issues with what's in the database, and it tries to sort of reconcile those two, Drupalite CMI has very specific. It has a YAML file. It says, this is the setting that we will use, very straightforward. So if we look at one of these files for CMI, we can see exactly what I'm talking about. This is the YAML file for the system site settings. It contains the name of the site, email of the site, front page, and some other settings. And that when you have this YAML file and you tell Drupalite, use this for configuration, it'll just say, let's use this name, this email. There's no reconciling overrides. There's no dealing with that kind of stuff. It's very clean and very, very, very easy. So in order to actually use configuration management, and I'll do a demo of it, but the really basic starting point is there's a module in Drupal called configuration management, lives at admin config development configuration. It's something you can all try now, if you have a Drupalite site in your laptop or one of your servers. If you want, we at Pantheon have free Drupalite, get panthea.com slash Drupalite, you could try it there. But it's really straightforward. You just go to the configuration management interface and you get something that looks like this. And what you can do with this is sort of some really basic options. You can import, you can export, and you can synchronize. And you can do it for all the config or a single value, but the process is the same. Basically, you go to your development site, make a config change, like changing the site name, and you can then go to the single value export. And you can say, export me that system site information. So you'll see here, we have that YAML file we just got. And it kicks it out as a bunch of text. You can do this with Drush and some other stuff we'll show as well. But the idea is that Drupal will give you this configuration file. And then you go to your live server and go to the same kind of screen, but using the import function. And then you actually go ahead and import that config. You paste it in, hit import, and it will actually go and import that to your site. So you'll get this kind of synchronization screen where you have the old version and the new version of what's happening. So you'll see here the name of the site is changing from endpoint law to this CMI demo, which is really great. And that's something that works for single settings like the name of the site. But it also can work for larger configuration sets like a whole like blogging system on your site. A lot of us might make sites where we have publishing, we make blog posts, and we want to export the content type for the blog, let's say. And we can do this in Drupal 7 using features module. It looks like this. A lot of different code. Got five different files to make that work. And there's a lot of white space and a lot of different arrays that Drupal loves. Drupal 7 loves. And it's not particularly readable. It's prone to a lot of issues with white space that might cause weird diffs and version control. It's something that if you look at it, can be a little bit sort of different. It's not crazy, I mean it works, but it's still a lot to deal with. And this is just for a simple blog, or building out a larger system, you start getting a lot of code really quickly. Drupal 8 makes this a lot better. We just have these two files for the node type and then the blog field. These are pretty straight for Yamro files where you can see those same kind of values and that this is something that you can then just import into the UI or embed your module code. Obviously, this will get a little more crazy as you do more expansive stuff, but the process is the same. Take your dev site, do all the development you want, export that development into Yamro files, do it with the rush as I mentioned, then take that with the Yamro file and dump it in to an import function on your live site, and then you can have a happy dance party. Because we should dance for CFI. So let's watch this happen. So I'll do a demo so we can all see the magic. So what I've done here is I've actually set up a Drupal 8 site on my Pantheon instance. I haven't done anything but install it, export the config, and add the trusted header information to it. So it's pretty much a fresh install and I've got a dev version, which is right here. I also have a test version and a live version as well. So to show you the, to get actually into the configuration management, you go into your admin side of things and you jump into the configuration management section, which is right down here. And you get to that same kind of screen that you wanted to see. This is a little bit of craziness, so just ignore that. But so what we can do is we can do really interesting stuff, like I showed you before, we can go in and if we wanted to make, say a change to the site information, we could say my updated demo, we can go ahead and hit save to that and then back on that export screen, we can do the export from the system settings. That's basically what I showed you before. Not terribly crazy, but you know. And you can do this between different environments. You can do it from your local laptop to like our integration server. You can do it from dev to production. You can do pretty much whatever you want. And then Drupal will sort of take that real configuration, do a little bit of generation on the backend and then we can go and paste that like before, which is pretty cool. But that's sort of cool, but let's do some more really awesome stuff. So one of the things we promised as part of this talk is to show you how you can do this with a managed workflow. Hopefully you see sort of the basic idea import export. One of the things that I'm really hot on these days is actually using feature branches in version control to deal with different features. It's a very, I think pro way to do development and it's something that Drupal 8 makes actually really real. The idea is that for every feature you wanna build on your site, you can create another copy of your site on a different branch and you can do that configuration. So I've set up two branches on this site. One is for the site name and the other is for the blog. So what I'll do is I'll just go in and show you the blog thing, because that's the coolest. So we'll go visit the blog site and this is basically a copy of the dev site that I just showed you, but it's based off of a different feature branch. And what becomes really awesome is that I can go to this site, see it's got a different URL, blog, my awesome Bogota D8 demo. I'm doing this with Pantheon's multi-dev tool, but you can do this with any kind of Git repository that deals with feature branches. And so what I can do is just as a developer I have a task to create a blog for my site so I can go in and make a pretty straightforward blog and call it blog post, my genius blog post. And go ahead and save that. And that's just gonna create a standard content type with a body field, nothing too crazy. And now what I can do is I can go into my configuration management interface, same as before, and instead of just getting that little piece of site system settings I could actually go ahead and get the, you can see some of the different blog stuff that's changed that tells you, hey, you've made some changes, maybe you should go and export them. So I can go to this export list and one by one I can go grab the content field and the content type. This of course is a lot of clicking in Drupal's UI as a developer, this can be a little bit crazy. So one thing that's really awesome is that all of the CMI stuff works with Drush and so you can do all of these kinds of commands that I'm showing you using Drush instead. You need to use Drush version seven, which is what works with Drupal eight. And I've got a few different sites here. So I'll run Drush seven on this site and I'll show you the different options that you can do. So you can basically have, I think there's five or six different options you can do. They're right down here. I'll cover these a bit more in just a minute, but the idea is that you can use the sort of import and export stuff on the command line, which is really awesome. One thing that's also really awesome is that you can also do full exports of your configuration. So if you're doing a blog system, for example, and you have a content type and multiple fields and an image style and some other settings, instead of having to export each one individually, you can just run this config export and that'll actually go and dump all of the configuration into your specific configuration directory. Drupal eight, when you set it up, will give you a directory for your configuration. By default, it lives in the file system, but to do really cool stuff at the managed workflow, you need to put it in the actual get root. So that you can do the export. And what happens with this, is it sort of chugs through and says, dump all of those types of things to the system. Sorry, the internet had a little bit of craziness. So it'll actually prompt you to say, yes, I do want to export all my configuration and you'll see here, configuration successfully exported to site's default config, which is what I want. So I can go back on my site and this is a cool little feature, it'll actually show me that there's these files that have been changed on that branch and I can actually go ahead and commit this. So, you know, my great blog system and I can actually go ahead and in a single commit put into version control all of that config that I have been working on and that's something that then other developers can look at because it's in the get history it's something that can be automatically tested by continuous integration systems and it's something that can be easily rolled back if there's a problem. One of the things that Molly mentioned is when you're doing a lot of clicking of buttons from screenshots, if you click the wrong button the site will go down. The only way to undo it is to unclick that button. With inversion control, you can roll back to the previous version. That's very powerful. So what becomes really great is now I'm back on my development site and I have an ability to merge, merge my changes back into the dev branch. The idea here is that I'm done with my blog feature branch, it looks good, I've showed it to my friends, they think it looks good. So now we actually want to put it to the dev branch and then put it live. So I can go to a quick merge operation to basically say take that commit that I have right here and pull that from the blog feature branch to the master branch and it'll actually go and successfully merge it to master if there's conflicts it'll resolve them as it does and now if you go back to dev you'll actually see that configuration line that's right there so that you can do it which is really cool. So you'll see in just a second. So my great blog system was brought in today and everyone working on my project can see that. So if I actually now want to go and get this into my site I need to use the last option that I was showing you which is that synchronize option because right now that configuration just lives in the data it lives on the just lives on the in that file system need to actually tell Drupal that you want to put it into the system and there's two ways that you can do this and I'll show both of them. The first way is you can go into the UI and you can run that synchronize operation. That's something that it gives you some visual feedback as you'll see and makes it pretty easy for to actually do it. So you'll see under synchronize it's detected that I have these different field changes or the different values and if I go ahead and hit import it's actually gonna go and tell my Drupal site let's go take all that configuration let's put it into the Drupal database and let's have that ability to actually use that functionality on my live site. So it runs through that kind of work and remember I'm making a blog content type so our hope is that once it's finished we'll be able to actually allow users who want to use the blog system to be able under shortcuts to add content and they now will have the ability on this Dev site to add a blog post with no configuration on Dev. Is that cool? Good. And this is a legitimate game changer for development that my prediction is that most of you in this room will end up doing this kind of process for most of your deployments and this will make Drupal more reliable, more testable, more scalable and will allow more people to work on projects. What also is really cool is that you can also do this with Drush. So I'll go ahead and move my code from Dev to the test environment because I now wanna have a really good test of what's going on. I could even pull in the files and database from my live environment so I get that really good. This is what it's gonna look like. And then what you can do is within Drush there's another option to actually do the config import which will actually do that same synchronization process but instead it'll actually do the import instead of the export. And that way for folks that are really used to Drush driven kind of development you can just go ahead and do those imports. So I'll wait for that to be offered. And then you just run that config import command which is the one at the very bottom here. And what that's gonna do is it's gonna say take everything in my file system that's configuration and go ahead and synchronize it all up. It may prompt us for a little bit, a little bit of confirmation before it does it similar to what it just happens if the internet holds out on us. But this makes this really powerful is this is something that you can script, this is something you can write tests against and this is something that you can quickly do because like Dries said in his keynote that the user experience of products are going to drive their adoption and ultimately success. And I assure you with Drupal the developer experience is gonna make the difference between people who are successful and use Drupal and people who give up. And Drupal is already hard enough so having stuff like this that makes it really easy to just work on a blog system, do the configuration, then import it is really excellent. So, some, I'll start fingers, this is the last one. Show you. And then you can actually do it. And there's some other options you can do with Drush as well. So there's a lot of power and there's some stuff I'll talk about in just a second where this is a system, what I'm showing you right now is just how Drupal Core does CMI. There are a number of contributed modules that I'll show that actually extend CMI further. I think the CMI system was well designed. I think the people who designed it had a lot of experience and so I feel we're in a good place but people are just starting to use CMI for their sites and there'll be a lot of additional use cases and additional kinds of things that people will build. And so if you see someone give a presentation like this next year or the following year, there'll be even more cool stuff to see which I think is really awesome. So you'll see here doing the import, we have all of those items and we can actually go ahead and do that configuration and it'll do exactly the same kind of synchronization we just did. So if I was to go after this finishes to my test site, I'd be able to see that blog as well. And of course I would repeat that and I'm gonna live to actually deploy that. And this is the future from my view of how Drupal development will be done on managed workflow and big sites. So that's sort of cool. I 100% recommend people try this out. If you find issues, you put them in the issue queue. If you have a good experience with it, write a blog post about it. I feel getting the word out about how CMI works is gonna be really important for people and everything like that. So all right, so that was the crazy demo. I have a really cool slide in right after this. Yeah, so I think we'll do about 10 more minutes. The stuff I really wanna show is to do, there's a cool fancy things you can do that goes beyond the demo and then there's some contrib modules and then we can do some questions. But we're here all week also and are happy to chat with this kind of stuff or sit down with you if you're building something to actually try out. So hopefully that was cool of a demo. Otherwise I can blame the conference by fire. Sorry for One Direction fans, I put that in sort of really weird. Okay, so let's talk about really sort of fancy things that you can do with CMI. So I talked about the Drush commands that you can use. Here are the six commands that are existing right now. They may be more in the future. Again, you need to use Drush 7. So if you're using Drush 6 and it doesn't work, you need to use Drush 7. And this is from drushcommands.com so you can sort of see what's happening. The import and export are the most helpful because they sort of do the CMI stuff, but you can do setting and getting of information and that kind of stuff. You also have an API to do those kinds of get and sets of CMI values within side of Drupal. So this is the basic syntax to get a particular value. This is the kind of thing that will replace variable get, variable set. So if you're updating your modules or writing new modules for Drupal 8, the configuration API is what you're gonna use to access a lot of that data that you will want to be storing in CMI. That's the get operation, of course. As you might imagine, there's also a set and a save operation where you can actually go ahead and update those values. There also are some values that you may not want to have in the CMI. Drupal has a few things like the last time cron is run or the private key of the site that maybe you want different, maybe not. And that you can actually create the sort of state options that uses the same kind of API but isn't governed by the export. So if you were to export all the settings of your site, you wouldn't get the last time cron is run because that's not something that makes sense to push to dev or test. So you can use the state API to handle that kind of stuff. You also have the ability to override specific configuration items in settings.php. So if you have API keys that you wanna switch out for a dev or a test instance, you can do that. If you wanna just change something for system maintenance or the site name or any option you want, you can just in the settings array do some overrides there. And that's really great. Other than that, there's a questions potentially so start thinking about them. There's a few, I think we preemptively know people care about. So we're interested in, aside from us earlier who's actually dancing to CMI, there's the answer right there. If you're wondering, hey, Drupal, this sounds really awesome in Drupal 8, but I have to work on Drupal 7 where that's where my experience is. If you want to know about how to get this in Drupal 7, there is a version of it that I call configuration management that works in a similar way. Drupal 7 has some differences, obviously. So it's not exactly the same but it has some of the same approaches. And it's worth checking out if you live in a Drupal 7 version. Also, as you might guess, when I'm just setting the site name as the site name, that doesn't necessarily reflect a multilingual environment, which is very relevant for Drupal sites. And one thing that you can sort of see with the YAML files is when you're dealing with a multilingual site, the YAML files actually do the language prefects up here. So you can have different settings for different language types as well. And they'll probably be more contrib kind of work to make this even easier. But CMI is aware of the different languages your sites have and you can have different configuration for different languages in pretty much the same way, which is awesome. If you're wondering about features and what that's gonna look like in Drupal 8, here's the quote, it's a little washed out but it's from Mike Potter, who's the features maintainer. Features will exist for Drupal 8 but it'll really revert back to more of what it was trying to do in the first place, which is be a way to package functionality like image galleries and blogging systems instead of being a sort of crud CRUD operation for different Drupal configuration. So a lot of the features code is gonna go away, the UI will get a refresh and you'll be able to use features with CMI to actually package up the kinds of grouped functionality that features promise. And my hope, especially in the Drupal distribution space, which is very near and dear to my heart, that features on Drupal 8 with CMI will give a lot of power and make a lot of reusable stuff because we've probably all made an image gallery or a blog post before, it would be great to reuse that kind of stuff. Also, as I mentioned, there's some really great contrib modules. If you're like, hey, CMI is good, what can I do to extend? There's a few modules here and more coming, obviously, all the time. There's an option called configuration read-only mode, which is really awesome to basically say, okay, if I can put my configuration in dev, push it to test and then live, I want that to be the way I do my site development. So let me, on the live site, lock down the ability to make any changes. So if you install this reconfiguration read-only module and you try to change the site name on the live site, it'll say no, no, you need to change it on the dev site and that enforces a kind of best practice and that's pretty awesome. There's also config inspector that lets you do a deeper dive into the different config files so you can have some visualizations and how all that works. Configuration log that'll actually push out the different config changes that are happening so you can see that kind of development pattern and then configuration tools which is getting a lot of development that actually allows you to push out those configuration changes to an external Git repository and sort of auto-commit each change so that you don't even have to do the export side of the equation. You just configure your site and every time you hit save of a setting, it'll automatically export and push out that change to a Git repository. And that's really awesome because this creates a very accountable track history of what's done and this creates a situation where you can sort of roll back stuff easily. And then these are just four modules. There's others on Drupal at work. There'll be more in the future and so if this CMI system is something that's interesting to you, maybe during the code sprint, check out some of these modules, look at some of the issue cues and sort of see for where help is because more of this stuff we build the better CMI will be. Other than that, we're happy to take a few questions from people but we absolutely appreciate your attention to our very important presentation. Muchísimas gracias a todos para estar aquí. Does anyone have a quick question or two? So the question is, how does Drupal 8 treat the content staging problem? So this is a problem that's similar to configuration in that maybe when you're writing a blog post, you don't want to have it on your live site. You want to have it on the test site so that you can push all of the content at once. Say, CMI isn't that same system. There may be some kinds of solutions for that that could look like that but I don't know a ton about it. Maybe someone in the room would be more helpful. That's a really good question because I think people could sometimes get confused whether CMI or content staging are the same thing and they're not the same thing. So yeah, there. And I think that as D8 becomes more mature, we'll see more people that look at some of these patterns and try to figure that out. But content staging is a super hard problem for sure. There's some work that can be done on content staging by using some of the workflow modules. So you can actually stage your content on the live site through different states, like different drafts or unpublished states. And I've seen that handled a lot on Drupal 7 sites. I think you could do similar things in Drupal 8 to handle that. So I was just going to clarify quickly if that's okay. Drupal 8 Core does have, UUIDs as Matt mentioned for all of its both content and configuration entities. So while Drupal 8 Core itself does not provide content staging, the functionality is there in core for contrib to build out sophisticated, fully featured content staging solutions. And a lot of work is already being done on that in contrib projects, even though Drupal 8 is not out yet. Thank you. Next question, here in the front. I see that this is a huge step for our Drupal content and configuration management. And this is really cool. And I'd like to question something related to rolling back changes. Because I see that CMI is intelligent enough to see that just like features, you have a new YAML file with new configuration and that doesn't match what is on the database and it just start creating stuff. If I roll back changes on version control, is it likewise intelligent to remove all this stuff from the database once I synchronize that stuff again? So the question is like sort of rolling back changes, what's the best practice for my roll back changes dealing with, you know, sort of updating my site to where it should be. I would say that the straightforward way to roll back changes is to, you can just use git and for example, if I wanted to roll back this change, I would just git revert this particular value. And after I do the git revert, I then rerun my drush command to do a config import. And then Drupal will look at the config as it is once it's reverted and it will then import that particular state. So any of the database and those kind of things are gonna be handled automatically by Drupal because when you do the code import off the reverted state, it shows you the config that was just there. And that becomes sort of the process you go through because the YAML files are declarative configuration. If I revert this commit, I'll see the config version that existed before and then Drupal can easily update that. Does that seem like a good answer? Awesome. On the, hello? Yeah. On the company I currently work for, we use features because we are still on Drupal 7 and our deployment workflow use Jenkins and it reverts all our features on the moment of the deploy and that works perfectly. So do you see any way I could do that with config import but without having problems with the questions they made about losing configuration or something? Yeah, so the question is, if we're working in an environment where we're using Jenkins to do deploys and in Drupal 7 we can do a features revert, one thing that I can absolutely see is when you do a deployment, there's some options that you'd probably do like running update.php and clearing the caches. I could easily see a third option here for Drupal 8 that says run config import as well and that'd be the kind of thing you could put into a Jenkins installation, especially with the Drush support, it's pretty straightforward and I think a lot of people will do that and that's awesome you're doing that right now. Aside from settings.php, is there any way to do environment specific settings like say this API key in test and a different one in live, that sort of thing? Yeah, so depends a little bit on how you architect it, the settings.php as you mentioned allows you to do sort of different kinds of versions. You could also store those values as different values in CMI. You could have a dev API, API key value and a live API key value and then you can switch. There's a few different solutions for understanding if you're on the live environment or not. There's a Habitat module, it's pretty neat. Pantheon will pass you a PHP variable you can check but really it can just come down to detect if I'm on live or not and then switch but I could see some config stuff that could integrate with a module like Habitat or environment where you could sort of be able to quickly do the kind of stuff you might do in Drupal 7 like disable UI modules in production. You could also switch to using public API keys and that could be a great kind of solution. Oh, yes. So the client zero months after says I don't want this field type anymore. So we have the product that features doesn't remove field types. We have to do with update hooks and that stuff. I don't know if with the new configuration management we have these problem solved in a standard way or we have to do the same thing. Yeah, so the question is if it looks good to add stuff if I'm trying to remove configuration like a field type features makes it a little difficult. The answer is Drupal 8 actually makes that really easy. The field type is gone, it can remove it and then you won't have to worry about that which will hopefully make your process of updating a little easier. I think something else to the Carlos question is that sometimes we need to edit check boxes or select lists which has content that has these options. So is there a way to edit the feature without modifying all the content? So we got some warnings when we needed to edit. For example, an option that will not belong anymore to the content. I don't know if I'm clear with that question. I mean, so the question here, you're looking to change settings that are related to pieces of content like some options on a node or something like that and that you want those settings to be able to propagate. I would say there's definitely a little bit of a blurry line there between content and configuration. Like if the node is published or not it's something that's currently stored as a content item but sort of looks like configuration and I think it's gonna depend on the specific, the way the modules are implemented, how they store that kind of stuff and that there's definitely ways you can use CMI to do settings for pieces of content individually because one of the things that Jess and I had said was each piece of content has a UUID associated with it. So you could have some settings that say for this UUID of content have this kind of configuration and that's some stuff that could exist in configuration management and would use the kind of process that I showed. All right, this question here. So there's this very ugly thing in features where it needs review, right? This ugly state. I haven't wrapped my head around it in full to exactly understand what the case is. What I kind of know is that there are like three things that are compared there and depending on how they differ that can be the state that draws features command will report for a new feature. Now, my question is will this new system get us rid of that ugly place? Yeah, so the question is features has a needs review and an overridden state that is definitely the bane of people using features. The answer is that CMI will make that problem go away. That because we're using declarative information, there's really no ability to have an overridden feature. I mean, you can change stuff in the database and then you'd have to sync it. But the kind of conflicts that features gives is are not as much of an issue because you have a very explicit definition. This is the name of the site. It's gonna be this and only this. And so the idea of needing review wouldn't really exist because it's only this config that you're explicitly telling it to do. And that's one of the reasons why when the CII got architected it took the approach that Jenkins did to have declarative configuration. So there only is this one kind of configuration. You can get stuff where you change it in the database but the code is still different and that's where it shows up in yellow to say it sort of needs to be synced or dealt with. But it's not gonna have the same kind of craziness you're used to. So hopefully it'll be a lot better. Yeah, maybe two more questions. One of the problems that we've run into with features was how to organize them and what structure to organize them in because a lot of times we found that the same or two different features would be trying to control the same bit of configuration like the same field used across content types, for example. That sort of a thing. So this YAML style configuration will it help to move away from that? Yeah, I would say the question is dealing with how do packaging features configuration in multiple modules create some conflicts. A lot of that's gonna be much easier in Drupal way. Part of it is that all of the configuration lives at a standard path. You can specify it like sites default config so that as you config into that it's gonna go right into that one directory. So it all lives in one place which is very helpful. You can however, when you create modules you can provide configuration files that default for those modules but you shouldn't have to have the same kind of competition. I mean if you're dealing with two features in the same way you can definitely have a conflict but because it's all stored in one place it won't give you that sort of needs review or in crazy mode kind of thing. It'll be a little cleaner. And it's also something that you can audit because you can look at that config files and see what actually is there when you do the export. And that becomes really awesome. I would just add one thing that I think the base system of D8CMI configuration has been rearchitected obviously as Matt said but it's not gonna solve team workflow, architecture level problems. So it's not gonna be a cure-all, you still have to go in there and figure out how you're architecting your site and how you're building your functionality and who's owning what in part of your team. So this is definitely gonna make it easier but that other stuff still obviously has to happen. Last question. Hi, my question is, I know that this is not very related with the configuration management but is there a way in Drupal 8 to synchronize from production the contents created back to test or dev environments? Gotcha, so the question is, is there a way to take content from Drupal 8 and dump that back to dev or test? The answer here is gonna depend a little bit on the content but one thing that CMI makes really easy is because CMI stores all the configuration in code, you can just do a straight database dump from your live site to your dev site and then run a config import after that so it will take your dev config, push it into your site against your live data and that's something that makes, that workflow I think will be very common that if I wanna refresh my dev site I can just pull the database from live, copy the files and then do an import so I'll have my current config and my production data and that's something I think a lot of us will do and it will solve the problem of work done dev but not on production and that will be the better world in which we all want to live. Other than that, Molly and I are here all week, we're happy to keep chatting about this, there's some coffee and other stuff before more sessions, we wanna be respectful but thank you all again for coming to listen and check out CMI. The music's crazy.