 Almost the last session of DrupalCon. My name is Greg Dunlap, moving my initiative. And this session will be to tell you all about that. It's actually really heartening to see this room full of people that's interested in what's to come in Drupal8, which, you know, we still have a while before we get to see, you know, the certainly good crowd. So I'm going to services and website consulting company. We build sites, we do consulting, awesome things. We do it for some of the largest, for some of the largest media and it's an exciting place to work. What we do is we run a site called Drupalize. I mean, interested, almost half price. It comes down to, these videos are created by some of the most first site building for setting up development for all sorts of things. Those are really amazing resources. So, onto configuration management. So a brief history of this is that in past versions of Drupal, it's been very difficult to stage, configuring one site to another. So, one of the reasons that that was difficult is because in both versions of Drupal, we kept all of the content and the configuration in the same database, sometimes in the same tables, all mushed together. So it was really difficult to separate it out and only push your configuration and not your content. And if you push all your content, then you're going to overwrite stuff that's on your live site, including and especially for sites that have a large amount of user-generated content, like comments and forms and ratings and all of these things that make modern sites great. And no centralized way to manage configuration, all of the pieces of core modules did it their own way towards the middle or the beginning of the Drupal 7 cycle. Some of that started coming together. SeaTools and exports started to become modular, started to become a little more mature, but there was still a lot of problems. And so, we needed to provide a centralized and common functionality for everybody to use so that we could make building sites. And so, at Drupal in Chicago, Trees asked me to be in this initiative. I've been working in this sphere since I started using Drupal six years ago, and it's pretty much been the only thing that I've spoken or meant. So, I was really happy to sort of be able to run this initiative and put it down by myself when it's finished. So, first, a word of warning. This is Drupal 8. It's still in progress, freeze or beta at this point. So, all of, and here are all of the information that I'm about to forward towards the user testing in bug fix mode. Some of this, the general concept is critical. So, what is configuration? Configuration is basically all of the stuff that makes your site what it is, but that isn't the stuff that your editors and your users want. So, that includes things like views, image styles, your users and permissions and roles, your content types and fields. Basically, your settings, anything that isn't your site's content is configuration. These are the kinds of things that you, as a site builder or a developer, editors take those things. So, again, in the past this has been a big difference. So, what is configuration management? It's the ability to take that conviction site. What is CMI? CMI is, as I said before, it's the initiative for, it's the configuration management initiative. So, let's get down to business. How does it work? The first of all is that configuration is now stored in files. It's been taken out of the database. The database, I think the CMI initiative has eliminated something of the order of 50p. Every time one of those patches lacks and removes something from Hook's schema, my heart soars. A lot of the tables will actually remain because they may be needed by country modules for upgrade path purposes, but they won't be actively used. So, your configuration is stored in files. That means that not only is it just stored in files, the files are the canonical location for the condom. So, if you were to sit there and make a change in the, this is what those, as an example of what one of those files looks like, it's in a very popular machine-readable format called the HEML. It's reasonably easy to write and read. As you can see, it's not, it's not like reading an XML file. It's not filled with all sorts of things. It's very straightforward to be moving this configuration out. And so, when you install Drupal now, there's quite a few of these files. They, they're both installed. You get 175. That's a lot of files. But on the other hand, it's really great because it means that you can stage stuff very crannily. You have a file per set of settings, like a settings form, an instance of a piece of configuration. Like, there's a file from each view for these files, and they live. I'm always really happy. So, you've got all these files. What do you do with them? So, as you work from site to site, of course, it's interesting when I started putting this, this, when I started putting this presentation together, I felt really shat. I was like, well, but it makes sense, it's really straightforward. So, what happens is that when your site is installed, a directory is created in that files area where all of your public files are stored. It's named config underscore and then a bunch of garbage letters. The garbage letters are required so that random people from the outside world can't surf into that and what is called staging. Configuration that is currently live on your site, the configuration that's being written discussing, the staging directory contains configuration that's new, that configuration from your source site, from your sources active directory to your destinations staging that and so that's sort of the configuration from your sources active directory to your destination staging. How does that work with automated deployment and version control systems? Because usually what you want to be able to do is just sort of pull from one directory into the other and have it go live. You can set which directory is active and staging in your settings.php and so your active directory on your dense site in version control is actually your staging directory on your live site and vice versa. And so when you pull, so are you live site and because you've swung those in your settings. So php is actually your staging directory on your live site at first but because this is a more advanced use case I didn't really mind adding the extra complexity so that the simple situations where you do this two directory system because when you have canonical files that are being written we have to just move files from one site to another while those files are actually still live because you've got this potential for the stuff that you're uploading originally and when we first developed the system we only had one directory and even just in testing we started running into that but I would move my live stuff from my dev to my live server and then I would realize my live server was messed up in some way and I'd go change a setting and I realized I had a problem so we had to do this two directory system. So once you've got the files moved from one site to another what do you do? Well you have to go there's an administration screen in your plate that does this if you look here it shows the changes that are about to be imported to your site out of defenses between about this is that you cannot do imports piecemeal or cherry pick and you've got staged works for this so that we can make it also makes our life a little easier from the UI and trying to sort of met with this was that we can make a basic UI that's function for core but we fully expect addressing more complex use cases so if you're configuring you can see the differences and what you do. It's that straight forward. I was going to do a demo today but one of the types seems silly to do a demo without that because it's the first thing getting this to see this in place it's really it still blows my mind. So on some of the more advanced features of this we've worked with or this ties into the internationalization initiative that Gebel Gromsey has been running and so there's a lot of really cool features that are coming. It's not quite sure how many of these are going to live in your core but I thought I'd show them to you. Here is for example the site information and it'll show you the so in this case we've got Hungarian installed and if you click the edit button it'll show you the translatable pieces of configuration that you can translate and save back to you. One of the interesting things to note is that there are three pieces of data on the site information form here. The site name, the slogan and the go to translate there are only two strings there to translate because of course the email address is not translatable it's not a translatable string and that's one of the things that we added into the configuration system was the ability to flag which pieces of can translate but just because a piece of configuration is not translatable you can still use the address based on the language that your site is. You can still do that. There's another system that is an edit system and it basically allows you to contextually change configuration based on a wide variety of things not just language but domain name or phase of the moon and so it allows you to contextually change things based on all this information and I think we're going to see a lot of cool use cases for that. So anyways back to this here are the two things that I wanted to mention and then those translations are saved and when you use them Gary you'll have those translations available for you. Additionally in cases where we have listings like this it adds a translate to it so you'd be able to do it that way too. This integration is really core because again we've never had a centralized system that makes settings.php and control modules that are very complicated or have this level of integration. So what else the configuration management system has some stuff that's still to land. The thing that's to come is that if you're used to using for instance views this sync warning it creates snapshots of differences between your active and staging directory so that you can see not only the differences between what you just uploaded but also the differences between what was there the last time you uploaded and what recently is this idea I've done is add a view and I should be able to use a very natural and the system. If you try to deploy an instance of a field to exist or the field definition doesn't exist it's very difficult to make that stuff work and in fact in the field system because it does a lot of room messing around with database tables it can really screw up your site bed. It's also unreasonable to expect site builders to understand work through something architectural. If your site's configured easier is the ability to do one click that uploads of your entire site's configuration. This patch was written to Australia so we're really looking at some pleading edge stuff here but basically what you would do is you would go to a page. You can see that very useful description that he has in his patch there. You would go to this page and you would click a button of GZ and get a tar ball of your configuration and then on your remote site you would have an upload. You choose the file you'll upload lose the ability for this and you would still be able to do it. It means that people don't find your strangely named transfer to the curriculum which is something that we've been kind of concerned about being too confusing for users. Abstracted away so that users because those tools that I just described would also be there in the back and if you want to do fancy deployment or if you're in a trip and you want to do other things you still could use and easy to understand way for this to happen but I wanted to talk a little bit about how the initiative system has been really new this year and triple Pointeries asked me to meet this initiative so that was 20 of us. That's true of our core developments and son, right? And so for the first year or so I supplied my time and struggled trying to make that work and so I did a fundraising drive. Worked full time on going. That was really amazing. It would also of course be really interesting to do and we're still working on it. If you're interested in getting involved in core and you've never had before there's a Springtime Friday that's being run by the core mentors. They're a great team of people well experienced and interested and highly encouraged. It's really cool. Dries will do Dries and Alex and though if you're interested in getting involved that's happening Friday. I highly recommend it if you're interested in getting involved in projects and all sorts of things. That's all I've got. If you guys have questions then there's a microphone and the things that you can do is then the ability to override your settings using the confere which is the same thing that you've been able to do in Drupal 7 and versions of Drupal before will still exist and the ability to create civic settings that way will still exist but I also predict that very, very quickly after Drupal 8 will be released in the text system somebody will create a series of context plugins which allow you to read out of settings what your settings based on that context. So both of those I would, I mean the one I definitely know will be existing. The other I assume will exist very soon after we launch if nobody else does it out for me. I just wanted to say thank you so much and for all the work that you've done on this and congratulations and I think especially navigating the community and everything some of the hardest work as well so I just wanted to say thank you for that. But also definitely have a lot of questions and they all seem like they just kind of keep going. So I'll just take a couple of them and see if I can not just evolve into a spiral of crazy questions. But I'm okay. So I actually had a similar question to her about the Sykes.php. So is that basically mean that every all configuration is now a part of the conf array or is there still that global conf variable or something that's the global conf variable is still there. I mean basically the way that the system works right now is it just to see if something exists in conf and if it is it uses it, period. So that global conf override still exists. We did add a new system as well to the just lost by trying to thought there. We did add a new system to Drupal this development cycle. It's called this is the most intuitive title invert. It's called the setting system. And what it is is it contains so state information differs from configuration in that it's environment specific. So for instance, the last time Cron was that stuff that's specific to your environment. It doesn't need to be employee. So that system exists as well for a lot of that kind of stuff because the variable system is you won't have the variable system to use for any of that stuff. But we needed something else and so you've got the setting system. Also is the state of modules enabled or disabled stored in configuration? Yes. And it will be deployed and the actual files the actual writing to the files when modules are enabled and disabled is all done and the system table is gone if anybody is interested in that and state. And yes, you will be one final question. It sounded like the config directory is actually world readable. Is that correct? It is correct. It actually has to be because it has to be writeable by the web server and the files directory is the only place that we have in a file install to do that. Ever in settings.php you can place that directory anywhere you want including outside of work. Let's see myself and I'm sure a lot of people in this room have come to rely on the future module for deployment management. So I'm hoping you can just talk briefly about what you see in the future sort of speak a little bit about your thoughts on the future. Yes, sure. I've talked about this already. Basically like 75% of the code in features module is one-off code. Two moves basically throw away like three quarters which everybody is always happy to be able to do. And then I think what's going to happen is that features is just going to become an advanced UI on top of CMock and focus on that and to spend all this time managing. I should point out that when I say earlier I said that you would have two files at once. There will be ways to how you're set up to partially deploy config for instance, if your staging directory on your own site already has a full set of config then you only need to deploy the stuff that teachers will still be able to ask things that they already do because they write modules that will be able to add on a bunch of additional functionality on top of CMI. So I fully believe that their future set will continually answer my question. I think I just saw like three people get out of line so that's great. I'm sorry it didn't answer mine. So I'm assuming that when people write modules that are being set then for example using news about its own dependencies so why not be able to just deploy view because you wouldn't get into that kind of a situation maybe with custom modules you might but with something like views. There are a few scenarios in which that becomes problematic. The original system we specified that if a piece of configuration was missing that meant that it was deleted but if you're not deploying your entire configuration tree then what is and isn't missing is an unknown quantity. In the system as it exists now I created the concept of manifest. It's one problem. Another problem is that views knows about its own dependencies but it doesn't know one so it's very easy to probably see in that case when we're using views and it says broken or missing handler and that's the exact problem that being said while the use cases where many parts of core are simpler the system is extremely complicated and I was very reluctant to design a system where I had to say to people you can deploy but in this other 10% if you do it your whole site will explode. Okay, I'll buy it. A lot of these functionalities off the record will still exist. A lot of them will still work if you know what you're doing. Have you given thought to a lot of stuff in table structures and the data? It was a very similar situation very early in CMI. One of the things that we talked about was the ability to provide feedback in a situation where in some cases the undue would rise if a trip module wants to provide it then it's their problem. So it's going to be my problems which you're saying? Yeah, exactly. So configuration can be rolled so it's a similar situation in 90% of the cases configuration can be easily rolled back but there are some things that Drupal core won't allow rolling back. So how does CMI do release if this patch that requires the presence of the full tree or to import lands then it will go back to doing the leaks by indicating the means that it should be the listing setting systems that stores things like when the problem was last week. Is that so much of the variables type or like a key value pair type? Yes, that's pretty much exactly what it is. Everything in Drupal has pluggable storage at this point. Even CMI has pluggable storage so if you're putting your configuration in DevNol is totally web scale. Does the secret part of it, does that change or is that set once in a while? It's different per installation so if you do anyone who doesn't installation gets it. So if you do an installation on two sites the key will be different unless you're also using two sites more and do what's more common which is that you simply so if that's set once per installation if that gets leaks then all the settings can be accessed by the web or is that protected via HD access? It is protected by HD access but even though it's the same on both places it's still randomized to begin with. I think that as a security measure we're going to recommend as best product that string is a 32 character randomized case sensitive string so guessing it is going to be. There are situations where it's very easy to forget to deploy your HD access I know that the most common one You didn't change the name of that directory after the fact? Yeah you can change it to whatever you want to and it's managed in settings.php The file system is enabled It was like 3 months ago and I don't have a quick answer for you right as I'm sorry. My last one is more of a request I just want to get away from this. Yeah I'm a writer and I've been truffles set of documenting for this I've also been hundering a multi-site Is it going to be a different configuration per site or is there going to be a possibility of a shared configuration between all sites and if there was a shared configuration would there be the possibility of doing just specific overrides per site? Because if I remember correctly you've kind of default all into the site specific files and they all have their own file directories So by that measure it would work with the same hierarchy that it does now and anything that's all would take prevent specifically tested this although I know we didn't run through it at one point but it should work under the same concepts that it is So I guess just to clarify for myself if just say you have a in-sites all you have your configuration directory and that gets shared across all your multi-sites would there be the possibility of having just like one email file for a specific site if you needed to just override Yeah I'd rather have an extra than that but on the other hand the assumption of this system as it stands now is that the full set of config that exists there is what's canonical of similar which is that for instance there's a big problem doing things like I've got a view that I'm using on 10 multi-sites and in one of them they want to have the settings for the master view cascaded down topics to it we don't have anything specific to mouse things that we talked about but it's not anything that So this probably exposes some of my lack of knowledge about Triple 8 but in 7 there are a number of things that are kind of our employee configuration in some cases I mean the content and others are seeing this shakedown where do you see these kind of like edge pieces My general rule that said a lot of things in Triple 8 have become entities so for instance many links to the one that you create Gileasing is something which is like 98% of what Path 8 uses are is content 5% of it is really tricky because there's another situation that I know we had problems with was the like list is in general you know this question of what's configuration features you can package views until little modules so since views is going to be configured modules that are installed across all the sites so then as far as the cascade goes you are able to override features on a per site basis those settings like an individual setting like the slideshow one that you mentioned and then the system in a multi site which site you are on BX for the system which I failed someone miserably had was to keep it extremely simple supports a lot of use cases and content system came out of that and so you do all sorts of things based on domain or somebody must write a module to do it and I can sort of say that's not my problem I mean these are tough questions that we only have so much time Just one quick I'm wondering about validation of some of the vitals the things that happens is at the time that you import if your file is invalid it's not added yet but it's going to happen a validation step the process of what happens in what order is extremely complicated so for instance you always need to enable modules before you do anything else then when it comes to validation you need to validate everything before you even start importing because there are various things that go wrong in the middle of an import and leaving your so it's like we have to do all of them all of the modules and then we have to do any import in the correct order so that the dependency so we've been talking a lot about how to get this validation done and make sure it's done right so that's not messed up but basically what we're going to be modules can go out and say I'm going to look at my configuration module's responsibility to do that aside for stuff that's really global like for instance I guess I want to say that first of all thanks a lot for getting to this point because we constantly have this problem of trying to obviously the more of this it's in some kind of text format that we can see the time stamps for changes this is just huge so again we can do whatever it takes to get it in to get and then use get the questions about performance and I'm kind of curious if you see this way of pulling configuration performance neutral as opposed to having the database and being able to there is caching in front of it the caching is pluggable just like everything else so mostly that's a problem that we've been discussing and don't have a lot of excellent answers to that may be something we just have to live in groups of configuration based on the path similar to the way that they do JNC JavaScript and CSS aggregation this would allow us to get all of the configuration for a path in one query instead of six that it's not performance neutral and always quiescent performance it's just the way life is abstraction and flexibility always paying performance I'll also point out that it's really a simple measure while the triple site is that when the triple site gets loaded the entire year the variables table is installed that's easily a lot of this stuff is just trade-ons I think what you just said was that you don't want to give some kind of a number at this point just to be feeling there's a yes you're correct and we're still in development and so it would be inappropriate for me to but then to say there's no doubt some percentage for the triple 7 the box is not a comparison to the triple 7 we didn't have views and we didn't have blah blah blah and so it's all it has to develop the context system and you were saying how can it be that it's pretty mature if there's a reason why I'm hesitant to make definitive comments on it is because it was largely written as a part of the multi-legal initiative and I'm not enormously familiar with the code and it's code Bejose, Raiero, and Gamerholtzy who are so if I'm hesitant it's only because I personally can't see that code path in my head but these are exactly the kind of use cases that we design the context system to be around so that's exactly what the kind of stuff that I would expect it to be it looks like that's it so thanks a lot for coming enjoy the rest of your day