 Welcome, everyone. My name is Alex Pott. I'm going to talk to you today about configuration management in Drupal 8. First of all, who am I? Why am I here? Many of you probably know me from being a Drupal 8 committer and committing many of your patches. Thank you for your work and thank you for those who sponsored me on GitTip and supported me throughout all my time as a Drupal 8 maintainer. But also, I am the maintainer for the configuration management system within Drupal 8. So I'm going to talk to you today about what is configuration management, what is configuration, about using configuration in Drupal 8, and then I'm going to delve into what dependencies and configuration are because it's a really important topic. And then I'm going to end up with some principles about configuration management in Drupal 8. So, why did we bother doing configuration management in Drupal 8? So there are two reasons that we did it. We really wanted to have deployable configuration, and we really wanted a predictable and robust system for deploying the configuration and for managing the configuration within a single site. So, what do I mean by deployment? I'm sure that many of us who have worked on Drupal sites have found it necessary to make changes to the site in production because there's some emergency from the client, they're like, I want this change, change it now and you make the change and you forget about it and a few months later you come and you make another change to the site, but you forget about the change you made in the emergency and you break it and it's like, oh no. So that's one reason we wanted to know when changes are going to happen and to be able to inform the user when you're going to overwrite changes that you've already made. I'm sure that many of us have used the features module in Drupal 7 to try and manage a deployment from your developers to production and you have like five or six developers all working together, they're all creating features, and then you might have a staging environment where you put it all together and you go, it's going to work, it's going to work, it's going to work. And you go, okay, you enable all the features and then it breaks and you don't know why, you've got no idea about where it conflicts and then you're looking at the features you want, it's going overridden conflict, I don't know what's going on. So we wanted to solve that problem and we also wanted to solve the problem of the fact that even with features and seatles, it was actually difficult to export some of the types of things that people were creating in Drupal 7 and then have a managed workflow for them going to production. Another problem that we had in Drupal 7 is that even the simple things weren't robust, something as simple as a variable get could be problematic because everywhere you had to put that variable get and call you had to manage the default right with the variable get. So it would be like variable get, the chymod value for file settings and it was like 7.5.5 is the default and if you wanted to change that you had to go and find every place to change it and so it's difficult to maintain that especially when you're working in custom with big clients and you're like okay we're going to create a variable, it will be this default and then someone changes it in one of the modules, hard to manage. And also configuration in Drupal 7 wasn't really aware of where it was being used so if you created a view which exposed a block, another admin user went and used that block and placed it somewhere in some theme and then you decided that that view is no longer relevant for my one use case but another user had used it in a different use case, you go okay I'm going to delete that view but you go and break that use case and you had no warning that that was going to happen. You had to know to go and look in the blocks you have ordered if there were multiple themes on the site go and check where it's used and then no. That's kind of backwards so we wanted to fix these problems in Drupal 8. So that's why we have a configuration action system. So I've used the word configuration a lot there so I figure I've got to tell you what I mean by configuration and in general like a lot of things it's easier to define it by what it's not. So first off configuration is not state. State is a place to store stuff that's particular to the unique site instance. There are things that only matter to that particular instance of that site regardless of whether it's a development site or a production site or a staging site. A really good example of this is the last time Cron was run. That's not something you want to deploy from your development environment to your production environment. Configuration is not cash and this is really important. The configuration system is expensive. It's reassuringly expensive because it's going to manage things for you. So if you're using it to cash things it's going to be slow. A cash is a place to store stuff that's expensive to calculate but can be rebuilt. An example of that is something like an array containing all of the information about the entity types in your system. All the fields that are on your nodes, users and everything, that all gets cashed because you don't want to be reading all the classes which declare all that information every time you try and access that information. Another thing about data that's cashed is that it's got to be rebuildable from the data, the code that you have on your site and all the other data stores whether that be databases or any other consistent data source when the cash is cleared. Configuration is not content. This one is a bit tricky because there are blurred lines but nodes, taxonomies and users are going to be stored in the content entity API. We're not going to store them in the configuration management system because it would create situations where you're doing things that are kind of insane. Fields are a configuration because you create them in development, you can push them to production but if fields were fieldable it would be a nuts situation. Not everything is configuration. Things like nodes which you want to put fields on, any entity that is fieldable, you want users to be able to go into the UI and create fields on that. That is not configuration. So basically configuration is everything that is left. It's a place to store information that you'd want to synchronize from development to production and it's information that's often created during site build but it's not typically generated by regular users during normal site operation. Whilst we've been moving things to this API or to these APIs, to the state and cache and configuration during the build of Drupal 8, we've struggled to actually choose where things are. For example, one of the things that people are used to doing is putting their site into maintenance mode and we're like, that sounds like something that is configuration, your site is in maintenance mode, you'd want to deploy that but actually that turns out to be state because one of the things you want to do before deploying configuration is to put your site into maintenance mode and then when your configuration deployment is finished you want to take it out of maintenance mode but it's only that specific instance of the site. So it's really important when thinking about where things go to try and work out but does it apply to that particular instance or does it apply to something that I would want to be able to deploy? So in Drupal 8 there are two types of configuration. There's simple configuration which basically means there can be only one instance of that. So a classic example is your site name. There's only one site name, your site does not have multiple names, it is called what it is. So we have a configuration object called system.site and in there there's a configuration key called name and that has a value and that is your site name. The other type of configuration we have is we have configuration entities. These are things where there can be none on your site or there can be many or there can be one but that is just an instance of many. So things that are configuration entities in Drupal 8 are your node types, fields, vocabularies, filter formats, views of configuration entities and these are the things that you build during your site build and you want to deploy. Here's a helpful then diagram that tries to show the relationship between configuration and config. So as you can see the content entities that I was talking about earlier, there's nodes, there's comments, they're not stored in configuration but all the things in the lighter blue, they're all stored in configuration. So they include the configuration entities, as I said, views, vocabularies, contact categories, that's another type of config entity, menus of config entities and then they include the simple configuration which is site info, user mails and stuff like that. There are a few things that still live outside, configuration or entities and they're a bit weird. We didn't get round to partheuses basically. So now I'm going to do a quick recap on how we use configuration in Drupal 8. So the first thing that most people want to do with configuration is that they want to be able to access it and it's really simple. Using the example of the site name that I talked about earlier, you just use the config factory of which slash Drupal config is an alias to get, a more procedural type of code but we won't delve into that and then you get the configuration object name, get the key name and that would then put the site name in that variable and then you can go off and use it. Configuration entities, each configuration entity type has a class so here's how we would load a node type in Drupal 8. So the node type is the class. There's a static method, helper method on there for you just to load up the article. And then because each configuration entity has its own class, there are methods on there that help you interact with the data that that contains. So if you want to get the help text for a node type, there's a nice little method there, get help and there it is. So how do I create these types of configuration? Most of the configuration that people will be creating will be during module installation or through the UI. So we'll go through how I do it for module installation. So I have a module. Here's the file module in Drupal 8. It has two pieces of configuration. It has a simple configuration file called file.setting. So that's a single instance of configuration that configures things for the file module. It also provides a view that allows you to see where files are used. Now we have two directories there, install and optional. What this means is this is the first example of dependencies that we're going to see. I'm going to do a lot more talking about dependencies later. For the file that's in the install directory, that has to be created during the install. If for whatever reason it fails to create that, it will actually stop you installing. Obviously there can't be another file.settings configuration object before you've installed the file module because all configuration starts with the module that provides the configuration itself. So simple configuration, file.settings, that's owned by the file module. Views however, obviously that's not owned by the file module because it's a view and views only can exist. They only make sense to the system if views is installed. If you install views first, and then you install the file module, it will automatically go, hey, I can install that because the file is contained within the file module, but views is enabled so it's there. If views was not installed because it's optional, it's like, I can't install that. I won't install it. If you later go and install views, it will go and search all the optional configuration that's there. If you go, does it exist yet? Are the dependencies met by this installation and pick it up? So what goes in these files? I'm just going to show you the file settings file because a view is really complicated. This is just a very, very simple configuration file that basically says that the file description will be a text field and will allow you to put 128 characters in there when it configures where the icon directory is. So how do I create configuration through the API? So here we have, again, calling out to the config factory. Unlike before, it's not just a simple get. We have to get an editable version of it. The reason for this is that when we save configuration, we need to ensure that you're dealing with the configuration as it is actually in the configuration system. The configuration factory provides methods to override configuration at runtime. The classic case of this would be in your settings PHP where you override a configuration variable. Other examples are where you translate it, different languages. But using the get editable version means that you get the raw thing and then you can just set the key to some value and save it. And then that will allow you to change configuration and create it. So how would I create a node type? Again, using the node type class, there's a static helper to help you create such objects. You just go create and then it's a type of news, a news story. And then, again, there are methods on the config entity to help you manage what that config entity could do. So if I want to set the preview mode to Drupal optional, so when I'm saving that node type, it says, you can preview, you don't have to, then that's what that would do. And then I save it and then it exists on the system. So let's talk a bit more about configuration entities because that's why we're here. Simple configuration is pretty simple. I don't advise creating it through the API because it's provided by a module that's only supposed to be one instance. If you're creating it through an API, there might be more than one. It's just exactly as it is on the name. It is simple. But configuration entities certainly are not simple and they're really not simple when they have dependencies. So Drupal, the reason we use it is it offers us a really rich interface to build complex websites. Within a few clicks in the UI, we can create views, content entities with custom fields, and then we can go and change that view to limit it to only display content of a particular type. Then we can add a display to that view which then puts that information in a block. We can then go and place that on a page. And before we know it, we've built a complex interrelationship of entities on the site that have to be managed together. And in previous versions of Drupal, it was like, OK, we're not going to tell you about how they relate. But because we want to be able to deploy configuration, we have to know how they relate. Because without knowing how they relate, we can't decide what order to do things in. So if you have a view that depends on a node type and you just try and create that through a deployment and the deployment doesn't contain the node type, if we don't have that information to hand, then you'll create the view but it won't work. And we want stuff to work. We want it to be robust. So configuration management is the way that Drupal manages this complexity. So here's a very simple example of I've got a node type. It has a field on. That field will depend on a field storage. There will be an entity display which will say that I'm going to display that field and that field will depend on that node type. This is a way of explaining this. It's like I go into the UI, I create the content type, I add fields to it and then I configure how they are shown using that entity display. For example, I can create a news node type, I can attach an image to it called main photo. That image field will consist of two config entities which is the field expression on the node type and the field storage, how it's actually stored in the database. And then I can configure how that is formatted on the page, when it's displayed through an entity display. All those things are relating together. If I don't have the node type, I can't have the field. If I don't have the field, I can't have the entity display. So what this allows us to do is to actually inform the user when we do things. So if I went and deleted a field, now in Drupal 8, I'm able to say actually this information is going to be updated, these other things. So if I delete this field tags, obviously I'm going to affect how those displays are managed because that field is no longer going to be there. What's nice about these dependencies on the entity form display and the view display is that when you delete a field from those, it can just be removed simply. It's not that simple, obviously, when you uninstall something. So if I go and uninstall views, it now tells me, as you would expect, it's going to uninstall all the views, but it's also in this instance because I've placed the who's online block which is provided by a view, going to remove that block because that block cannot be existing on your site if you don't have views to provide the data for it. So this allows us in Drupal 8 to build up a much better picture of the potential consequences of an action. It's also going to make it significantly more robust because often configuration can't exist. If a configuration still exists and it has no meaning, then your site is broken. In Drupal 8, as long as all the config entities are declaring their dependencies correctly, that won't happen. So what can configuration entities depend on? They can depend on four types of things. They can depend on modules, themes, other configuration entities, and content. So, as I said earlier, every configuration entity has an implicit dependency on the module it provides in the file module example. The view that was there obviously depends on views. And that's because that module contains the code for actually implementing that config entity interface. So the views has a class called view which implements config entity interface. Without that, a view configuration is meaningless. Another example is roles. Roles are dependent on the user module because without the user module, the role configuration entity does not exist. Additional dependencies can be added based on the logic implemented by the configuration entity. So now I'm moving into the subject of how do these config entities get dependencies? To repeat myself, because it's well worth knowing, the first dependency that every bit of configuration has, whether it's simple or a config entity, is based on the config object name. So node settings depends on node. The view depends on a view. But they also can depend on information that's contained within them. A simple example are block config entities. Block config entities say where a block is placed. One of the keys that it has is theme. That key says which theme it's enabled in. If you uninstall the theme, that block configuration entity has no meaning. It should be deleted. But there are other ways in which dependencies can be introduced into configuration entities. I'm going to talk about two of them now, which are provided by the config entity base class. First up, third party settings. Now third party settings are the way in which all configuration entities can be altered by another module that doesn't provide it. So if you want to attach information to a node type so that it gets deployed at the same time as a node type, you can use this system to do that. An example that we have in core is that the content translation module includes third party settings to add per bundle translation settings to the content language settings. A bit of a mouthful. Multilingual is really powerful in Drupalight. Every single type thing can basically be translated in Drupalight. You can change on a per bundle level whether or not a node is translatable. In fact, it's not just nodes are translatable per bundle. Taxonomy terms are translatable per bundle. Anything is translated per bundle. We do that by having language content settings. The content translation module basically adds information to that configuration entity. For example, I can make my news node type translatable by going into the UI saying that's translatable and then that will add these dependencies to my language.contentsettings.node.use. It obviously depends on the actual bundle itself, but now it also depends on the content translation module because that's then saying that this content translation module is providing the ability to translate per bundle. The way in which we do that is by using two really simple methods that all config entities have, which is set third-party settings and get third-party settings. When you call it, you just provide the module that's adding it and a key and a value, and then you can get it in the same way. What's great about this, as opposed to Drupal 7, is that you don't have dumping grounds. The dumping ground of modules is controlled. In Drupal 7, we had a blob on the field table where just modules would put stuff, throw stuff, and go, okay, it's there, and then I know that when I'm installed, I can go to that column and get my settings. Now in Drupal 8, we have a defined way of doing that so that when that module is uninstalled, we can say, ah, we're just going to clean that up for you. You don't have settings that another module has added to a config entity that's left lying around polluting your configuration and making it confusing. The other main way that configuration gets dependencies are plugins. Plugins are Drupal 8's API for combining configurable settings with reusable code. So many of course plugins configurable settings are actually stored, obviously, in configuration. Example of plugins that we have in Drupal 8 are block plugins, filter plugins, and view display plugins. And there's lots and lots of plugins in Drupal 8. But I'm just going to take you through the example of a filter plugin. So here we have, it's very similar to Drupal 7, the UI for configuring a filter format. And this is the plain text filter format that you get with the standard profile. And it's basically, there's a load of tick boxes down there, and so the top one is saying, display any HTML as plain text. That's actually a filter plugin called filter HTML escape. That when you tick that, that says, store this in the filter format, when you process text with this filter format, use that plugin to escape the text. And then the other options that you're kind of used to, you can zoom in a bit. We also have the converting line breaks. That's a different plugin, filter auto P. We have the converting of URLs into links. That's another plugin. And plugins aren't just on or off. They can add more things to a filter format, like how long is the maximum length, the maximum text length of your URL. So that's configuration that's specific to the filter URL plugin. And that means that we can build up from all those, the plugin configuration, the filter format configuration. Plain text, as it's provided in core, has no dependencies. The reason being is that all of the plugins that it configures are also provided by the filter module. And as I said, configuration entities depend implicitly on the module that provides them. So a filter format is provided by filter. All the plugins are provided by filter. There are no more dependencies. However, there is this option on your filter screen, which is track images uploaded via a text editor. That filter plugin is provided by the editor module. And if I go in the UI and I tick that, what happens is I have a dependency in my filter format on the editor module, which means that Drupal now knows that if I remove the editor module and install it, then I have to do something with this filter format. Obviously the right thing to do here is not delete your filter format because that would make content insecure, but at least it tells you that you're using it. And this all works because filter formats, the config entity class, implements entity with plugin collection interface, which basically says to Drupal, when you save this, check which plugins it's using, the filter format, whether they come from, if they're provided by a module that's not filter, add them to the list of dependencies as we did there. Plugins can also add dynamic dependencies. So if the plugin pulls in information from elsewhere in the system, it can then go, actually, your dependent on that. And that's often how config dependencies appear in your configuration. So when your view, for example, is dependent on a role because you've said this view can only be accessed by administrators. So if you went and deleted the administrator role, that view then has no meaning anymore because it can only be accessed there. So we're able to build up a whole picture of how your configuration and plugins come together. I'm sorry, I feel that that was probably quite confusing. So in the views UI, you have a place where you can configure how your view is accessed. That's an access plugin for views, and there's a particular flavor of that access plugin that says, actually, limit it to these roles. When you go in the views UI and you say this view can only be accessed by that role, that then uses the plugin configuration to say that view then is dependent upon that role, which is a configuration entity itself. There are two other types of dependencies that come out of the box with Core. There are the ability to depend on content. An example of this in Core would be the content block module, which provides a block content entity where you can just create blocks of random text. This module, when you place one of those blocks, that block is then dependent upon that piece of content. So if you delete that content, the system's able to say, actually, I need to go and delete that block config entity. We also have the occasional requirement of an enforced dependency, which is basically where the module provides something like a node type, for example, a book, and that node type would have no meaning if the book module wasn't installed, and so you just add that to the configuration. But it's not very common. So here are some principles that we've discovered for managing configuration sanely in Drupal 8. Firstly, configuration shouldn't change unexpectedly. So if you load a node type and immediately save it, if that actually changes the underlying configuration, then something has gone wrong. Put it another way, if all the runtime dependencies of the configuration are satisfied, then regardless of any other code being available to the system, i.e. installing yet another module, the configuration shouldn't change. So if you have a module, it shouldn't just on installation go and change every other piece of configuration because you're breaking the contract that the configuration is what the user is configured, not what the module is configured. Here's one that will make people's lives a lot easier. If you are declaring a sequence in your configuration file, you need to sort the configuration in a predictable order that does not change often. What do I mean by that? I mean, if you have this type of configuration where you have a position key, this is how views arranges its displays, and you want to put where it appears, it seems that you might want to sort those configuration keys by the position. But actually if you do that, when it comes to, if someone goes and changes the position of one of those things, you get a config diff that looks a little bit like this. All that's changed here is the position of one has been moved to two and the position of two has been moved to one. What you really want is something that looks like that. It's a lot easier to tell what's gone on. You've just got to be really careful when creating lists of things in configuration that you sort by something that's predictable and when a user makes a change, the difference does not change everything. The final principle is when a dependency is removed, configuration by default is deleted. That's because, as I've said before, we want to keep the system working. The default case, if you delete a role and there are views that depend on it, is that it's going to remove the view. If you delete a field and there are views that depend on it, it's going to delete the view. If you delete a vocabulary and there are taxonomy terms that depend on it, we don't want to have a broken system because at the end of the day we want to be able to depend on configuration. Here's what I'm going to try and do now. I'm going to try and show that you can depend on configuration. I wasn't going to talk about deployment mechanisms but I'm going to show you what you can actually achieve with the Drupal 8 configuration management system. A little bit of a not a live demo of sorts. Here's a site I have which is basically minimal plus a node type. I'm logged in as admin here and I'm going to create some content stuff that everybody thought doesn't really matter what it is. I'm going to save it. My developers go away. This is my production site. It looks terrible. They go away and they're like, I'm going to theme it. I'm going to install views. I'm going to do a load of stuff in the configuration package to synchronise with this site. At the moment I have nothing in my staging directory and I'm going to copy all of the configuration that they've given me and put it in my staging directory. If I have a look at what's in my staging directory I have a lot of stuff. I have views which isn't even enabled on the site. I have search pages have more node types that I only have the page type on the site that I'm on. I've got fields for that. I've got entity displays all sorts of stuff coming in. Configuration is integrated with Drush so I could do the import through Drush. If I did that it's going to tell me what it's doing. It's going to create a load of configuration. It's going to update core extension so we're actually going to install modules and themes. It's going to remove some configuration that's because the UUIDs have changed but I won't do that through that. I'm going to show you the UI because my minimal site has the config module on. Here I'm seeing the very minimal config UI. It's telling me it's going to create a configuration that's basically the same list but one difference is that I'm able to view the differences here so I can see that I'm going to install all these modules, I'm going to install block content, I'm going to install editor all of these things are going to be installed during this. Let's do it. Minimal, as you can see comes with Stark and Stark is a very Stark theme these days. So it's telling you what it's doing it's installing views it's installing Classy which is a theme it's deleting stuff it's creating content entities creating views, creating fields seven. Nice. Come back to my content a nice view which to manage my content with and I can see that my content is still there. Still there with its actual body I haven't deleted that I've preserved that field now it's all there I can come to my site structure I can see that I have a load of views views wasn't even installed before and that's all been done in a way that's completely reliable and repeatable and that is configuration management in Drupal 8 now you're going to see my keynote skills which are really bad. Last up a few people who helped me write some of the text behind this that's like XJM the big Venn Diagram was from Gabor and he's done a lot of work on configuration as well Catch and Matthew Tift and Susan McCormack all helped me prepare text so thanks to them here are some links resources so if you come back to the presentation notes they'll be there I'll add these links to the page on the conference site last but not least there's a sprint on Friday as you've probably been told 100 times please come we've still got criticals to do on Drupal 8 and I really want to see it out as soon as possible and I'm really excited for October 7 so let's get it done and yeah thank you Any questions? I was interested to see that taxonomy vocabularies and taxonomy terms are split in terms of where you put them in terms of configuration or content and also menus that the menu itself and the menu items so two questions why were they split like that and the second question is kind of a developer what I often find is like I want to put up a whole menu that for me a menu is usually kind of a developer thing so how would I do that? So the first question was why are some things content and why are some things config with specific reference to taxonomy terms and vocabularies taxonomy term is one of the more difficult ones but in general we've erd on the side of content when people want something to be fieldable so there are use cases in call where people want to add additional fields to taxonomies and so in order to do that we need the full content entity system the other thing about taxonomies is that they're often user created whilst entering content when there's something difficult to choose between we've erd on the side which gives the user the most power one of the things that everyone is finding with configuration management in Drupal is that it exposes the lack of content deployment and there are at least three or four efforts that I know of to introduce reliable content deployment as well in Drupal 8 so I'm looking forward to them bearing fruit I think with menu links there are I think three ways in core in which we can provide them and one of them is actually backed onto config so it is possible to deploy menu links using config so it's not as simple as all menu links are content so that Venn diagram might be a little out of date that's what I'm trying to say so the answer to the how was that there are initiatives to do it there are so for content deployment there are modules that people are developing so the author of deploy for Drupal 7 Dixon is hard at work on a content deployment stuff for Drupal 8 there's something called entity pilot which is a service developed by Lee Rowlands that allows you to kind of package up your content and deploy it along with configuration and in fact in core we've left the question a little bit open and we've allowed missing content dependencies to be calculated during that config import that you just saw and if there is stuff to do it's stubbed out so there's an event that these modules can look into and create content at the right point so we've tried to prepare it but some things have to still be done in contract ok thank you so first up I want to say this all looks amazing thank you for your hard work and everyone else's I have a question about something that came up in another related session and I tested it out afterwards which was that it doesn't seem possible to site install create a brand new site configure the site in some way run another site install and import that configuration and this would be very important and valuable among other places in automated testing so I'm curious about your thoughts on if it's possible to implement something like that or what's the thinking of why it would not be possible ok so the question was like I've got this set of configuration why can't I just do a site install from it more or less I mean why is it not repeatable in that way so I actually did create a critical issue for that and I was told that it was a feature too far so there are two contraband ways of currently sorting it there's the config installer module which I maintain and is currently broken because I've been busy with other things but basically what that allows you to do is during the install actually in the install form it says get configuration from somewhere and you can just point it to a directory and it'll just pull in all that and it'll override the install profile and just do that what's also intriguing is what features has become in Drupal 8 Mike Potter has done some awesome work to basically make features a config packageer so it packages configuration into modules and modules become the way of deploying for packaging a feature and a feature is just a configuration but they also, apart from just a module builder, they have an install profile builder which basically says okay I'm going to export all of this configuration from this site into an install profile and make that repeatable so there's at least two ways to potentially solve that problem and what was the name of the module you said you were maintaining but it's currently broken config installer thank you I want to say again just thank you so much because I've just seen every major obstacle with Drupal development just solved magically before my eyes I just think it's fantastic so thank you very much for that and it's just amazing how all of your site configuration is just sort of defined with dependencies like that I mean has there been any work done to sort of offer a visualization of your Drupal site and show that that graph show that tree yep there is there is a config graph module maintained by myself it's really experimental does it work maybe it doesn't have any tests it was like it was written in a weekend of like oh this should be possible now I've added all this dependencies and behind all the dependencies when you uninstall or delete configuration it builds up an acyclic graph of that and there are tools just to dump acyclic graphs into PDF so it's really simple it relies on something from PHP documenter has a PHP component that does that so it's like the simplest code I could try and find it or the output if you want to come up and see it later any other questions Bertie you said you had a hard one cool I just have a question because I was playing with features and very basic but stupid example so in features I exported like the basic article standard profile installation YAML file and of course I wasn't able to import it so if I was using it on another site that already had an article YAML file or article definition I wasn't able to install it because there were conflicts so is there any smooth way of resolving this yes it's to be so what you've done there is you've done a Drupal standard install in two different places and the moment that you do that those are two different site instances if you had done a Drupal site install copied your database moved that then it would have worked and the reason being is that when you create configuration entities is that we can't know just because it has the same name that it really is the same thing and in order to help us manage those conflicts before they occur we assign a UUID to every single configuration entity in core so if they conflict then the system can't it can't know that that is actually the same article type so that's the way around the way around is to build your sites in repeatable and predictable ways which is exactly why that first question about how to build a site from a known configuration is so important and why install profiles through features or using the config installer will become recommended ways of working with config to build multiple instances of the same site ok, thank you, I was aware of that but if I would export a certain module in features that would be maybe not installable as a certain feature module if it conflicts and it totally just stops it doesn't say where it conflicts it doesn't help me to resolve this conflict and that's the point and that has to be built in features features needs to tell you exactly where it conflicts and then what are the likely resolutions in the instance where I think features is going to have the ability to rename your configuration on import and then change all the names of all the dependencies of its package so that the name is something fluid in the feature so that when it gets into your site if there is a conflict it automatically handles that but it has to be built features is only in beta in LA so it's young code I wanted to first ask a question like how would you first develop a site and then deploy it because with core you can do that at the moment but you answer that question already so now I want to ask another question you kind of set yourself up because you said when the manager wants to have like this emergency fix and then you fix it on the live site and then you develop something else then it would get forgotten now it doesn't get forgotten but you see that it's getting deleted when you synchronize the configuration like what would your recommended way be to keep that but yet somehow merge the state so if I was managing a site which had lots of people with the ability to change stuff on production and I had lots of developers working on that site as well I would be looking to set up a daily job that exports configuration from production and compares it against my known staging merged environment and would then notify me if there was any differences so that I would then become immediately aware when someone's done something on production and there are modules around this already I think there's a like a config log module which logs everything but that stuff is going to be possible auditing is because each configuration object is stored through a predictable API there are events that occur and every time that a config is saved you just create a listener to that and then you could on that just save that configuration and just notify people you could even just have a module that was like email me any time that configuration has changed which wasn't possible in Drupal 7 because you'd have to implement every single hook everywhere in the system to do that now you have one place to do that Hi, just a simple question where does the rules come into content or configuration I have not looked at rules in Drupal 8 but if that's not configuration I don't know what is actually it's more of a follow up the previous question sorry I don't remember the name asked about so you say to get a job to notify always about configuration changes but some configuration changes I think are not meant to be lived in a configuration file like for example the slide slogan such thing can probably always live in a database maybe is there a kind of an option to just say this property only the slide slogan or site name just live in a database all the time without any so that the configuration doesn't even touch it no well okay it's Drupal so you can, you could create a module that provided a configuration override stored certain things outside of the configuration system but in doing that you would make your site harder to maintain because it would be so left field to other developers who would then come and work on your project there's no harm in storing something in configuration that would change as rarely as a slide slogan but it's possible in Drupal you can always do anything there's always an alter hook or an event or a hook that will let you do something hi thanks for everything you have done in this group and I have two questions first is maybe silly would it be possible to have a configuration files in the file structure we want or we are forced to use a file pattern like mymodule.settings.yam again so where do you want your module has a particular structure and so your config slash install directory is where it looks for configuration during the installation changing that would be it would be possible but like again it's like you're making something non-standard if you're talking about where you store your staged configuration that's just a setting in your settings PHP by default we put it in some created directory inside your sites files directory because that's the only place where we can create create files but it's totally up to you that goes and if you want to do a completely secure Drupal that would be outside your work group just configure and also you're coming back to something that I should have said when I started talking that during the Drupal 8 cycle on configuration there was a lot of talk about configuration being stored in files where your active store is that's no longer the case in your active configuration is actually stored in the database it's only when you export it do you get it in a file format and since we are now using third-party libraries from PHP especially can we store configuration there in the same system I'm not entirely sure what that means since we have dependencies for a module or for a with composer or anything so but that's code that's not configuration say I mean it would be possible to write an alternative config storage that used a PHP library to put it somewhere else if you wanted to get really complicated but in terms of like the relationship between composer dependencies and configuration dependencies they're just separate things including third-party libraries is about providing a code to code to depend on it's not about providing expressions of configuration that's an expression of the application it's not the same thing okay I just wanted to ask for or just wanted to give a slight answer as well as ask something like the situation of a multi-site so on a multi-site of course the side name would always vary and I think in the previous talk about configuration there was the answer so that you can always go and overwrite the configuration in the settings PHP but this would mean that if I have my side name or for example a twitter key or something like that not being editable in the CMS backend but always would rely on manually updating the settings PHP right? no other way around well there are other ways around but if you put it in your settings PHP that's the value that it is I really don't like that way of working with configuration because it tends to be something that people forget about and it then creates like instances in your UI because you go to a page where you can configure your side name and it says it's one thing but you see up there it's another thing because I can also imagine the very same thing so I would go and make this field for example only readable read it out of the settings PHP in the case of the twitter API would be the configuration that gets the value somewhere it's kind of I don't know I didn't get the question there so you really don't see any way around that around what am I trying to get around writing it only encode configuration encode by overwriting the database ymol based configuration sometimes I really ask this I know no you don't see any way around besides from writing it into the settings PHP of the various multicides right there are I mean the configuration factory is what integrates the configuration system with the rest of the application the configuration the architecture of that is that it gets the storage injected and it reads from the storage it then asks it then says do I have any overwriters and by default there is only one overwriter in standard profile and that's the overwriter that comes from settings PHP so any overwriters in there are applied you can add custom overwriters the only one we have in corey's language because we want to be able to translate configuration but modules can add overwriters to the config factory there are crazy things in there it can go and get your configuration from somewhere completely different but if you were going to do that for everything then you would replace the config storage but if you're going to do it in one specific instance this was the same answer that I just gave that you can actually do that there whether that's recommended practice I wouldn't say so but because it starts to make everything a little bit unpredictable and one of the great advantages of the configuration system is that because everything statically stored in files it doesn't change Hi, two questions first is there any democratic way to say this is content and this is configuration for instance by default you decide this is configurations and this is content but for instance in the future I want to have this is actually configuration for our specific purpose is it possible to override that not without a little work ok so it's possible but it's a hassle basically second question since we are removing the variable set and variable get is there a way to I don't know I haven't checked but is there a way to upgrade from Drupal 7 and Drupal 8 and then just magically transform the variable set and variable get into the config I don't know what the Drupal module upgrade does with variable get and variable set but that might offer you a path there's a piece of code called the Drupal module upgrade which doesn't it's not part of core but it's in contrib that takes a Drupal 7 module and tries to update the code to Drupal 8 it probably makes recommend if it sees variable set it probably says think about how you store this in configuration ok so if I don't use that model I can't do more every variable set and get and replace that so it's more or less like building new set rather than upgrading the Drupal 7 ok thank you so for the previous question about site specific overrides and the example of having say a twitter API key and the concern about having to hard code that in the settings.php file there's two things that I would mention one is that settings.php doesn't actually have to be a monolithic you can have specific settings.environment.php and your settings.php can also load other specific files so you can have one standard settings.php that loads from whatever somehow in php because it's php whatever else you want and another thing about the something like a twitter API key is there's actually a security case for not storing that in a get repository that's off with all of the other configuration permissions because that's a specific piece of private data that's specific to that site so it's I don't think it's actually quite as ornerous as having to manually edit a settings.php file for all of your 200 multi-site sites you can automate that in a different way still using it so your main settings.php site for the specific multi-site instance goes off and loads a separate file that contains that information if necessary and that doesn't have to be done manually thanks actually Dan any more questions? we're actually at time so thank you very much for coming