 All right, well, let's start off. My name is Matthew Tift, and I work at Lullabot. I am also a configuration system co-maintenor. I've been doing work on Drupal Core since 2010 or so. I think, actually, it was at a DrupalCon like this, where I got my first core patch committed in San Francisco. And I guess I should say right now, we were having some sprints on Friday. So if you're interested in helping out, either in this initiative or any of the other initiatives with Drupal 8, be sure to stop by on Friday. I also want to mention that where I work at Lullabot, we are hiring. And you can check out the jobs we have available there at lullabot.com slash jobs. And we have a fun party going on tomorrow night. I think the sixth annual Lullabot party will be tomorrow at 7 o'clock at the handle bar. So enough about me. Let's talk a little bit about configuration management. So specifically, this session today is geared towards site builders. This isn't a deep dive into the new configuration systems, APIs, or how to build a module with the configuration system. This is geared towards site builders. And it's an overview of how things work now, as well as how we think things are going to work. I do expect that there to be some confusion with this topic. So during this talk, I will present things as simply as possible, give you some more details. And near the end, I will be doing a little demo to show how this works. I've given this talk a few times before. And I don't think I've ever actually been able to give a demo because the synchronization piece wasn't quite working. And it's still not complete by a long shot. But that is sort of the trajectory of our discussion today. So overview, more details, and then some demo. So generally speaking, configuration management. Let's talk a little bit about that first. Usually, when people describe this, they can be talking about lots of different things regarding hardware and software and that kind of thing. But there are some terms you see, like quality, configuration, consistency, control. These are words that you want associated with your website. You want to have a quality website. And that's essentially what the configuration system is trying to help with. And in the simplest use case, what we're talking about is moving your configuration from your development server to your production server. That's sort of the simplest use case. And then beyond there, there's lots of other use cases. So for example, you may be a developer who works locally. And then you have maybe a site online that you're staging. And then you have a test site or something like that in a production site. But in its simplest form, I think it helps to understand what configuration is by thinking of it moving from your configuration from development to production. Now, other people can turn this topic into a much more complex topic. But today, I think it's good to focus on what I think configuration management is. And that's a process for establishing and maintaining consistency. So the things that I talk about later in this talk should, I hope, support that assertion. So let's talk about what this is specifically with Drupal 8. So I did a little unscientific study. And I did some searching of the code base in Drupal 7. And I found that the word configuration appears 785 times. If I shorten that to config, I found that that word appears 2,400 times. Now, I did the same thing with Drupal 8. And the word configuration appears 5,500 times. And the word config appears 18,000 times. So this is my unscientific way of showing that configuration is a big part of Drupal and growing. Now, you may question my methodology. And I did look at a lot of the other words that popped up, like preconfigured and configurable. But I think that these, in most cases, had something to do with configuration. And I couldn't find any other words that didn't really have something to do with configuration. I'd say it's pretty scientific. So configuration, in the simplest way I could think of explaining it, is types of things. So in Drupal 8, what does that mean? Well, views in core. That is one example of configuration. Image styles, settings, user roles, these are all things that are like a mold that creates other things. These are types of things. And on the other hand, we have the content, which would be the things that get created from those types of things. So those examples include article basic page. So we have our content types that then create the content. So if you want to think about the simplest form of what the Drupal 8 configuration system does is it breaks the information in our database into at least two separate areas. One that's relevant for site builders, which is the config. And the other is the content, which is relevant for the site editors. Now, that's actually a really gross symbolization, although I still think that's correct if it helps for someone who's new to this topic. I would say that it's also important to know that there are two different kinds of configuration actually in Drupal 8, one of them being simple configuration and the other is something called configuration entities. You may also see this referred to variously in documentation and issue queues as configurables. And I think our official term for a while was configuration thingies. So there is some, there was lots of discussion about what to call these, but there are two kinds of configuration, one is simple, one is more complex. The simple configuration, really in most cases, it should just have information about one thing, one copy, one Boolean value, one string, something like that. So for example, JavaScript, is it enabled on your site? Yes or no, true or false? That would be simple configuration. You don't necessarily need to know about the history of that. You don't need to know much more about it other than is it enabled, is it not? Something that is a configuration entity, on the other hand, would create zero or more items. So again, you create configuration as a site builder and then your editor takes it over and there is no configuration, but there's no content at that point. So this is used to create zero or more items. I think this representation is another way that's helpful to think about this, where we have the idea of entities in Drupal 7. And now we have the idea of content entities and we've sort of split that up into configuration entities. And then so we can see kind of off on the right that we have other things that our configuration, like site info, would be simple configuration and then there's other things like path aliases. But this does a little good job, I think, of explaining that the overlap between the types of things that fall within the realm of entities that can be either content or configuration. This is another way to think about that in terms of simple configuration, sharing the word configuration and configuration entities and content entities, sharing the word entity. So I'm getting a little bit more confusing, but I think you're probably all with me because you look like a smart bunch. So why are we doing this again? Well, let's talk some more about the benefits of configuration. One benefit is that it eliminated 50 database tables or so. This is because of the one place where people can store configuration, it was no longer necessary for modules to create their own separate table to store their own separate data. So this is a big benefit in terms of how a Drupal 8 is going to work. It also is reducing the need of modules like features and strong arm. So in Drupal 7, this may be the best practice now is to use features module. Some people might say that, some might argue, and we might use strong arm to do something like export our configuration, but it's not the only way. It's not the agreed upon way. So we also have this ability now because configuration is in core, that we can translate configuration and content out of the box. If you're not familiar with the translation system in Drupal 8, it's made it so that now if you want to create a site that is not in English, you no longer need to install more than 30 modules. There are four modules in Drupal core that allow that and out of the box. That's one of the first things you do is decide what language it can be. And that is in great part due to the new configuration system. It also lets us to do in the site something like configure well which of those fields that you've created or which of your content or configuration needs to be translatable. In this example, the site information part of your site, you have your site name, your slogan, your email address, but then when you need to translate that in German, for example, you just need to translate your site name and your site slogan because email address does not need to be translatable. So we're going from three things to two things and that's because we've said, email addresses don't need to be translatable. So that is another benefit of the configuration system. So starting to get kind of exciting. You can see I'm excited. Another benefit, swapability. This is because of the way Drupal works. We can store our configuration in multiple formats for whatever your use case might be whether it be storing your configuration in files, databases, other places. You have a lot of flexibility in terms of where you store that configuration but perhaps the most important feature of the configuration system is that it is like a bunch of developers have gotten together and said let's agree on a way of storing our config so we can all deploy it in the same manner. So this is the common API. This is what all of your modules that you'll be using is the configuration system. So this is the agreed upon. This is the way to do it and it's now in Drupal core. So it's kind of a big deal. Another example of a benefit is that we can have the migrate module in Drupal core and that can include migrating your configuration. For example, when if you've used the Drupal 7 migrate module very much you know that in most cases you're just going to use it to migrate nodes and users and other types of content. You can do things like migrate blocks and variables and I've done that before but there's not a consistent way to do that for your configuration and now there is. So this is something that I think will be valuable and really though because we're building it I was thinking about this in terms of like a product. We want the configuration system to be useful and not only that to be valuable but to save you time, to save you frustration. And in the product lifestyle cycle if we think of configuration as that we've gotten to the point where we've had the idea about what it should be. We've had our mockups, our prototypes and we're currently I think in this phase where we're trying to get to a minimum viable product. Everything's not quite working. We still have a number of critical bugs. I think it's something along the lines of 15 or more in the configuration system. But once it becomes a product and we ship Drupal 8 I think this is when we'll really find out how useful it is and how value it will be to you. So my point here is that the benefits are still to some point unknown because we don't have a lot of people kicking the tires on this thing right now. But we're getting there. So how does it work? Well, this is my attempt to simplify how the configuration system works. I think in most cases there's one of three ways where you're gonna get configuration into your site. A module might provide that configuration by default. You may interact with your site like you do now and change something and or you might import configuration from another site. And all that will go into your active store. That is where your configuration is stored on your site. And then the great ability of Drupal 8 is the ability to export that configuration. So here's an example of this and I will talk a little bit about JPEG quality because it's important. Although it is somewhat controversial topic. We'll look over that for now and let's see an example in core. So in core the system module provides this configuration for JPEG quality. This is YAML format. It's the simple one line file is going to tell us that it should be 75%. And this file lives in a config slash install folder. This information is only used at install time. So this module is providing config, JPEG quality 75. When you install your site then this information now by default goes into the database in a config table. And there it is as JPEG quality 75. That's in the active storage. And then when you want to export you export it as a file out of the box. And that is how Drupal works. And this file as you will notice looks just like the other file unless you change that value which everyone probably will because that's usually the first thing you change on a new Drupal site, right? Your JPEG quality. Now, how does JPEG quality work in Drupal 7? Again, acknowledging the sensitivity to this issue. Now it does similarly come in as a file. Although you can agree that this is probably much more complex. This is a form array. This has this variable get thing. And if you're not a coder you're probably not understanding what's going on other than you're sort of recognizing there's the JPEG quality in the 75 that I know. But this is perhaps just one way that a module could provide it. This is how the system module provides it in Drupal 7. Again, this is Drupal 7. So similarly, it ends up in the database. This time currently it ends up in the variable table as JPEG quality. And there it is, JPEG quality. But then what? Let's get that information out. So we might think, oh, well that's real easy. I go to my development site and I change that number to something like 56. And then I see that that makes it work better. And then, okay, I'll go over to my production site and I'll change that to 56 there. Or did I say 54? I'll go back and check. So you have to remember. And then somebody else comes along but they don't necessarily know what you did or why you did it or that kind of thing. So there's no quality. That is just in this most simple use case. And if any of you have used Drupal for much time, you will know that this gets much more complex more quickly, especially when you're dealing with something like, say, a view. I should also acknowledge that in addition to saying that Drupal is just config and content, there are other things in there. And I think it's important as a site builder to be aware of that, that some things are not content or config, such as when Cron was last run. That's not something that you go in and configure in your site. That's not content that your site editor is adding and they're not going in there and saying, oh, let's reprogram when Cron was run. That's just something that Drupal needs to know. So we have, for example, a state system and that information is stored as a key value pair and Drupal takes care of that by itself. So this is just an attempt essentially to acknowledge that there is slightly more complexity here and if you are wondering why your JPEG quality is not right, well, there is another place where you can sort of configure things and we still have our settings.php file and we in Drupal 7 have a comp array now, or comp variable, now it's a comp fig and you can override your configuration still in settings.php. So that's the height of the confusion. It just gets easier from here on out and we can relax. The bunny, the pancake, I don't know what he's saying. Configuration, how do I use it? So I actually am gonna do this live. I have these, well, no, I'm not gonna do that. I'm gonna show you quickly what I'm gonna do in case it doesn't work live because it's never supposed to work live and you're not supposed to do it live but I've never been able to do it live. So anyway, I'm gonna show you a development site and a production site and these two sites are, this is important, cloned instances of the same site. This is, in my opinion, a difference in Drupal 8 and others that work in configuration sort of disagree with me in this but in other words, if you go and install Drupal 8 and then you install Drupal 8 again and you try to synchronize those changes, that will not work because we ran into issues very quickly that made it clear that people have all kinds of ideas of what they should be able to do with configuration so we would sort of imagine those to the extreme. For example, let's say I work on whitehouse.gov. Well, should I be able to take my configuration from whitehouse.gov, export it and then go over to this other site that I work on, thisamericanlife.org and I'm going to import that configuration and turn whitehouse.gov into this American life. That should work, right? Well, that's crazy. So we're not gonna support that out of the box in Drupal. What we're going to do is to say, if you have a site and you clone that site and you make changes on one, we're gonna say, yes, you can move your configuration between those, you can make your changes, you can install modules, you can make changes, push those to the other sites and that is the goal of the configuration system in Drupal 8. So these two sites that I'm showing you are cloned instances of the same site. And I'll talk a little bit about JPEG quality, change it to 42, use the configuration manager. I'm gonna show you the real demo so this is in case things don't work. The configuration management section of the site, you export your config as a file, a config.tar.gz, then you import it on a different screen on the production site. You click import all, you can view differences. You can click import all again. No, you don't, I doubled that slide I think. It will synchronize and then it will say it is complete. So then you can go to your production site and see that you've in fact changed that. So I will go back to my two sites here and here I have my development site and what I'm gonna do is just do a couple of things. So this here, I'll show you. Okay, so I'm gonna go into my development site here and I'm gonna add a content type, content type. I'm gonna call it DrupalCon Austin because that's the great name for a content type. And ooh, I can't scroll down, it didn't work. That's why I'm asking you to do this. Scroll, aren't you? Save and manage fields. Okay, so now I have in your structure in my content type, I have a new content type. Yay, that's what you need. Then I'm gonna go and I'm gonna click on structure again. I'm gonna click on blocks and I'm gonna do something else which is I'm going to add a block because we all wanna know who's online right now, don't we? Of course we do. Sidebar first, save block. This is that new block interface which is cool. Who's online is super important so I will push that to the top. And then, of course, I need to change my JPEG quality. Something more sane because I wanna save the planet. 42, that's much better. Now, I've made those three changes. So if I go back to my site, we can see I have my who's online block, I have a new content type, and I've changed my JPEG quality. I click on configuration. I scroll down to configuration management. I click on this full import export tab, export and export my configuration. And there it is, config.tar.gz. So if I want to go over to my other tab, which then I'll go here, production site. So I've done my changes on my development site. I've exported them. I go over to my production site. I scroll down to configuration management. I go to full import export and I choose my file which is that config.tar.gz and I click upload. Now, at this point, it is moving all of my configuration into my production site and it's giving me this opportunity to view the differences. So this is where it gets really cool because for example, we can see there's our JPEG quality has changed. I'm about to change it from 75 to 42. We can see I have this new who's online block where it's a file that's been added and there's a block. And we can go through and review all of these changes. We can see there's our new node. There's some, each of the pieces of this, we can actually go in and change the file. So now I say, yep, all that looks good. I'm gonna click import all and it's going to synchronize all of my configuration. So at this point, we are taking out all of the old configuration and putting in all new configuration. So the reason we do this is because for example, if you go to a development site and you delete something and you want to deploy that delete to your production site, it's not gonna know something's been deleted without knowing about everything there. So this is, it checks that site UUID. It checks and sees what's there. It checks and sees what's missing. And now, if I go back to my site, I can see there's my who's online block. I can go to structure and I can look at my content types. There's my new content type. There. Oh, is it? This one. I need to see what is my JPEG qualities 42. So it's all done. Three years to be able to do stuff like that. So configuration is a complex topic and that is the overview and I'm sure a lot of you have questions, but before I get to those, I just want to make a couple of other points, which is that one, that key, is there is a, you can get more information about the configuration management at Drupal8CMI.org where we occasionally post stuff and we have links to documentation. Some of that documentation I'll warn you is out of date and it's of varying quality and we have an IRC channel at poundruple-CMI. I mentioned the sprints on Friday. I'll be there as well as another, a few other configuration system maintainers and lots of other core developers and people just like you. And please evaluate this session if you have opinions and that's a little bit about me. So now I'd like to open it up for questions. If you could go to the mic, that would be great because they're recording this session. Then I don't have to repeat. Hi. Hello. So I know you said there's a lot of different workflows in mind with configuration. The first thing that came to mind was when you're deploying your configuration changes from development to production, you a lot of times in the process of coming up with all those changes, you have a lot of things that you don't want to go with that little things that you were testing around or playing with or maybe it's only done that way on dev. Do you have any thoughts for supporting that part of it or excluding some things from going up or just what that might look like? Yeah, so there are lots of ways that you could handle this and again I'm going to acknowledge that people are gonna have different workflows. A lot of people are probably going to use version control for that and they are going to for example, have a Git repository where they just push changes to a Git repository, their configuration and then just pull those changes and in all likelihood those changes that they've done will be related to an issue that somebody filed or something like that and this is the metadata part of that. So if you have a site where you want to just do some changes and you want to deploy those and you're using version control, you would do it the same way that you would deploy any other changes by pushing those to your repository and then the other sites pulling those. Is that to that end, is the file system, what does that look like just in how all these things, is it like one big file or many files or is that manageable with Git and there are lots of things? Sure, okay, I'll show you what this looks like. So when I downloaded that tar.config.tar.gz file, this is actually all of your configuration for the whole site. Now this is gonna be confusing to some of you but let's go find something that we know and love so you can see all of these different, this is all, these are all YAML files. So you could, for example, go in and see something like system.image.gd.yaml is in here and you could look at it but then also, of course there's much more complex things in here so this is kind of how YAML code works. So that is how the configuration is exported. It's these files look the same as when they were imported unless you change things on your site. Now, I don't know if it's probably not the best time to get into all the other possible ways that you could do that. One other thing that comes to mind though is that we added something that you may have noticed in the demo because a few people felt it was a regression that you could not export a view or import a view. So we do have the ability to do single imports and exports. Now, we do everything we can to make this so you will not break your site but if you do export and import a single thing there is the possibility that you will break your site because of dependency issues or something like that but it is definitely possible to use this system now and a view is probably in most cases it's going to take care of itself where you can go to the single import thing and you can export or import a view. So those are a couple of things that come to mind. I'm sure some people will export features or export, I should be careful of my terminology, features or views or other things or blocks for example and just store those as things that they use for multiple sites and that could definitely be a valid use workflow and I fully expect lots of people to do that. Thank you. Just a clarification, are nodes part of this configuration management? Node content? Yes. And what is the impact when you delete all the configuration to a production site with active users on it? When you delete all of them? Yeah, when you're doing a full import you said you delete all of the configuration and then you re-import it. What impact if any is there to a production site when you do that? It should not have any impact on that site. Okay, so I have two questions. First, when you export the modules, does it export the modules themselves as the attachment or does it download it on the other end when you import it again? Does it just export the metadata and then download the new content or? So are you saying when I go to this configuration tab and click configuration management and click export? Yeah. If you would have just before installed the module and so now there's a difference between the production and development sites, so does it actually copy the module itself as within the table or just the metadata to reach the module on the other side? When you install its own default configuration it's directory the config slash install and at install time it pulls in all of the configuration from that module but we in core out of the box, we won't ever really do anything with that again because we will assume that once that module has been installed and you change things that you want those things changed. Okay, the other question I have is since you changed the configuration that much why didn't you go all the way and take the config out of the database once for all? Because it's really confusing to have config in database. That is a good question and it has a long answer. So this is coming from somebody who's probably been paying some attention to Drupal core development over the past three years. Because for the past three years we have been in talks just like these saying configuration will be in files, content will be in the database. That was the case in Drupal core up until two months ago when we made the choice to move the configuration back into the database. There are lots of reasons for that but let me just provide a few of them. First of all, we had people that were, okay, when we did that we put configuration in a directory called an active directory. It's your active storage. You can configure your active storage to be a database or fonts. By default we had it as files and people would go in and look at that active directory and we had to say kind of like now we say don't hack core we had to say don't hack your active configuration or directory because people would change things in there and they would be surprised when those changes would not be reflected on their site. The reason they weren't reflected on their site is because we were still pulling the information from the files, caching it in the database and in most cases reading from the database cache and only reading from the files on install and writing to the files when things were changed. Now we don't have to worry about people going in and accidentally changing things in their active config directory. The second point is that we did this because of performance issues. It's a lot faster to read and write from a database than it is to read and write from files in general. So we found pretty significant speed improvements for example installing Drupal when it didn't have to read and write 167 files. So speed was another factor. Another factor was security. And again I'm probably gonna be losing some of you here now but right now the way we have it set up is when you install Drupal in your site's default files there is a config directory that is I guess I'll just show you why not. Go crazy here. Keep in touch. I'll just go to my Drupal 8 site. So there is a, you know what, I can do this, yes. I can go to sites, default files and in there there's this config directory which is config in this super long hash. So again I know this is hard to see and within this directory there are two files let's see if you can see them better here. There's an active and a staging. And if we look in these now, you know what, why don't I just do this like a normal person who doesn't use the command line all day. The command line is good for totally normal. Everyone can get over it. Yeah okay but anyway, so here this is easier to read. Sites, default, files, config. And I've been told not to show this to everyone. It's empty basically, right? So and then we have our staging and that's empty. So the way this was working before is that in your active directory all of those files would live and that's where Drupal was reading and writing. When you export then you would put those files in a staging directory and that's where they go. So that's a super long answer to your question. Everybody's wondering it so I just had to tell you that's why. So there is also, there's a long issue that on Drupal.org slash list hyphen changes. So Drupal, Drupal list changes is the way people think of it. We've, all the changes we've made from Drupal 7 to Drupal 8 we've put there. That information is all accurate and up to date and every time we fix a critical bug we also have to change those change notices in that documentation and there is one in there that talks about changing the default active storage from files to the database and it has even more reasons about why we did this, links to the issues, lots of developers butted lots of heads and I'll warn you, if you really love files we have a module that has all that code in there and you can still do it anyway. Thank you. I'm just gonna clarify, so for like dev sites we could have the full file base config and we don't have to touch the database so while we're working with a team we could have it fully file based. Okay that's half my question. Second half since we over automate things because we're Drupalers, what kind of Dresch integration does this have as far as pushing, pulling or backing up, exporting config, maybe certain configs, things like that. It's got all that so we have Dresch commands for importing config, exporting config, synchronizing you can do it all from the command line. I wanna hug you, thank you so much. Yeah I'm wondering about performance, that was great. You had like three or four changes but what happens when we've got a full website and we're looking at thousands of configurations. The performance of Drupal 8? Well the performance of importing and exporting. The performance of importing and exporting. So when you've got 3,000 configuration files what happens? I mean we used this, we tried this on the D7 version, I had to get rid of it because it didn't work. The D7 version? Yeah there's a version you can get for Drupal 7 that does this. The configuration system module. And it works similar but with a site as large and complex as ours we had to get rid of it because every time we tried to run it it crashed our site. So that is a completely different thing. Configuration now, there's a configuration API in Drupal 8 and it's baked in. So to compare the Drupal 7 and Drupal 8 versions I don't think is quite fair because in Drupal 7 essentially the same or similar, unless a lot of things have changed but similar configuration exists now in databases. It's just in more tables. So we should be able to just be just about as performant. We haven't done a lot of the performance tweaking at this point because we're still trying to get it to work. There are still, like I said, bugs and the general way of doing things in Drupal is to first make it work and then make it faster. By moving things into the database we saw the speed go up versus when we had things in the files. Some people said it was somewhere around three times slower with Drupal 8. The actual process of importing and exporting configuration does take some time but I don't think that would necessarily have to affect the performance of your site. I mean that's not... I wasn't asking about the performance of the site just the performance of this action. The performance of importing and exporting. Right. Well yeah, I mean I haven't done like strenuous load testing to see how it would work with 3,000 files. With Drupal Core it comes with 167 files. We could look but it comes with quite a few files and it took a little bit when I synchronized there but if you're installing something that would bring in 3,000 files of configuration that seems like that would be quite a lot of modules and quite a lot of extra configuration. So I'm not sure what would happen is the short answer but I think if that, I don't think we're gonna release a version of Drupal 8 that doesn't work for big sites. Thanks. Sure. Hi. I got two parts to this question. The first part is does this handle deletes in a clean way and nice way so if I delete a field I push that up, it deletes in our production? Yes. Okay and the other part was you hinted at something called a clone. What is a clone and how do you make one? So the clone would be if you create the site and at that point it creates a unique ID for that site and it creates all your configuration and files so through the UI installing Drupal it has all of your files, all of your code, all of your config and you copy that directory and put it somewhere else. You could, now if you're using Git, like the way I did this is I had a Git repository to demonstrate, I had one site that was pulling and another site that was pulling and when I was synchronizing changes I could push those changes to the Git and pull them back down. So again, there are lots of different ways that people are gonna do this. Probably it's gonna be a lot of people are gonna be using Git to do this but if you just want to create a site and then copy that directory that is a clone of the site. Thanks. Sure. I have a workflow question. So if you and I are both developing on sites and forgive me I'm gonna use the features module as an example and you finish what you've done and you've added it into the feature and I have built something on my site that is not in the feature but I want your functionality on my site I can effectively merge configuration by adding what you've done in the feature. With this new configuration management what happens if you have checked stuff into the Git repository that I have not done on my site or vice versa? I will say there are multiple ways that folks are gonna deal with this. I was talking with some, I was talking with Alex Pot from chapter three and Alex Bronstein from Acquia yesterday about this topic and they both felt like there were two different ways they were gonna handle it like Pantheon might be handling in a different way than Acquia but different sites are going to implement their own workflow. The one sort of simple way for a simple developer workflow would be to put all of your configuration in that staging directory. And I should also add the disclaimer that we might get rid of those directories because they're kind of confusing because they're empty. We might allow you to say to pick your staging directory. So I will say it could be something else but for now it would be that config underscore hash long hash staging directory. So you could make that part of your Git repository and when you are pushing a change on your local site to that Git repository you could push it to that staging folder and then pull on the other site. Another way in a more complex workflow like for Acquia or for Pantheon would be that they would for example maybe, I don't know how they're gonna do it so I'll just say this is the way someone could do it. They could deploy a branch to their production site. And the issue that maybe, I'm not sure if you're getting at this is that in some cases you'll want people to be able to change configuration in the UI on the production site. In some cases you might say we're not gonna let that happen anymore and we're just going to have developers do it. If you say I am going to let a developer push changes but I'm also going to let my users make changes to configuration, create views, things like that and you deploy a branch to your production site. Let's say we'll call it release one and then you're working on release two. You can work and work and then at some point you can say all right I'm ready to merge. I'm going to export the configuration from the release one production site. I'm going to merge that in and then I'm going to merge that branch into release two. So I have the current configuration from the site. I have all the changes I've made and you can do your conflicts at that point. So I'm not sure if that answers your question but then at that point you could, well I guess it would be better to call them like 1.0.x or 1.x or 2.x kind of thing because you could change those branches as changes are made or you could even automate that process and say every hour I'm going to check to see if something has happened. I'm going to run address command. It's going to export all my config into this file and you can get as crazy as you want. Okay, thank you very much. Sure. Hello, in one of the previous questions they asked for deletions. Right now features for example it allows you to exclude a component and it will add something to the info file for it to ignore it in future export but as a feature of the module it won't actually delete the field from the database. It will like they say that we won't torture that that we won't delete your data. So if we delete something and we export that and make a sync will that field or the information will actually be removed from the database? So you're getting into the weeds a little bit here but these are the kinds of complex problems we are trying to solve. In general, we are doing our best never to delete data that doesn't need to be deleted. So now basically everything in an entity is a field in Drupal 8. That's cool. It's like that's kind of everything is kind of fields now in entities and it is possible to say remove a module that provides a view mode for that field. And if you remove that now I think our goal is to make it so you won't remove like your whole view mode. You'll just remove that particular or you won't remove that field view mode from your entity. You will just have to revert back to the default view mode for that field but it should also not delete the data. So we have a fairly complex dependency management aspect to this that tries to avoid things like that because there is a whole process when you're enabling and disabling modules where we do a bunch of checks when you're synchronizing we have to do a separate sort of checks to make sure modules exist, the code and that kind of thing. But in general we're doing our best to have sensible defaults and make it so you won't accidentally delete your data and if you are making changes to your if there are going to be changes to your data or changes to your configuration that there will be warnings saying you are about to delete something. And I won't get into the technical details of how that works but essentially we have your active configuration we have your staging configuration which is where you stage things to deploy them to your active but then we also have snapshots of your configuration when you import so we can compare to see what has changed. Okay, thank you. You're welcome. You've touched upon some of this but right now using install profiles for new sites going back some years back everything I had a whole bunch of variable sets Drupal write record to actually put the configuration right in the database couple of years ago I started stripping that out and putting in features so now I get features that get installed at install time. So how do we do that now in Drupal 8? Yeah, okay, we just initially I thought you just would supply the ammo files but now it sounds like you can't just do that, sorry. You could, you could well let me sort of make sure I'm understanding the question correctly. Are you saying if you're writing a module how do you do that? No, well just configuration, yes our distribution is for distribution we have a lot of different modules that we bundle up and deploy with our distribution and we're configuring all of that in the install profile. So you would do that just I mean just like any other module you could provide your own default configuration and if you're saying like how do you make that? Well you could go into a view for example and create that view and export as files and put that in there much like you would with features but I do want to make the point that Drupal 8 is not necessarily trying to replicate all of the functionality of features and that features will still exist. We are trying to find the most common denominator of what function, what functionality most people want out of Drupal core and then we're providing an API that lets you change it sort of however you want. But if that install time to populate that configuration directory with the defaults will those get read in? Those will get read in from the install profile, yes. Thank you. I think that's it. Any other questions? Thank you very much for coming.