 I have young daughters, so I can start off by asking if anyone knows why people like bananas. It's because they have appeal. Yeah, I can do this all day long. But I won't, it's 215. So that segues into, I guess, me introducing myself. We should probably do that. Any slides for that. My name is Matthew Tift, and I work at Lollabot, and I am one of the core maintainers of the Drupal 8 configuration system. And this... And I'm Alex Pott, I'm one of the Drupal 8 core maintainers. I'm also a maintainer for configuration management, and most of it is my fault. So, feel free to apportion credit and blame, as you feel free. I'm really lucky that Chapter 3 pays for me basically to spend 99% of my time working on core, because they believe in Drupal 8. Cool. So, we're here to talk about the configuration system. And we can start off by saying that you may have heard this referred to as CMI, the configuration management initiative. And that was a thing, but now that initiative is over. And now we have the configuration system. So, if you want to be, you know, all technical about it, we're not here to talk about CMI. We're here to talk about the configuration system. And in Drupal 8, and we're going to just talk today briefly about what it is, some of the benefits, how it works, and some continuous integration. So, what we're here today is to get into a little bit of the technical details. Build this as an advanced session for developers. So, we will get into some of the meteor aspects of the configuration system, but we are going to start off with talking about some of the main sort of principles, because a lot of the people I've been talking with that have been trying to do things with the configuration system. Sometimes it helps just to sort of conceptualize what it is for, why we built it, what was the problem we're trying to solve. So, in general configuration management is a way to try and manage consistency to have control over your code base, to be able to move your metadata around and have a way to deploy to your production server. So, these are some of the key aspects of configuration management, generally speaking. But really the use case that we tried to solve in Drupal 8 was this one. So, if you remember nothing else from today, think about the configuration management as a system that moves configuration from your development server to your production server. We're not trying to be able to say, hey, I'm working on WhiteHouse.gov and I'm going to go and export my configuration and then I'm going to go over to NBC.com and import it and have it look just like WhiteHouse.gov. It doesn't work that way. The idea is that we're moving between the same instances of the same site or different instances of the same site. Now, the way we built the system, we allow you to do that but actually that's just some random drawing of configuration management and the point here is that you can do all kinds of crazy stuff. We tried to make this really flexible but the main use case that we're solving in core is development to production. And so the main way that we made it flexible is by having absolutely no opinion about how you manage your configuration once you've exported it from Drupal. It's up to you to design your own processes but that said, we all want to be able to build sites and deploy that configuration in a reliable way. So at the end of this presentation, I'm going to recommend a way in Drupal 8 of just simply building a site and managing its configuration and I'll show you how to do that. So if you wanted to have a one sentence definition of what configuration management is this is one way I think of reducing it to one sentence. So we do have our own unique approach for Drupal 8 and how we're handling configuration management. So I'm going to say a little bit about how that works and this is going to go from sort of simple to slightly more complex but at the very basic configuration in Drupal 8 is types of things. So these are some of the types of things that configuration management is. A view is configuration, a user role is configuration and these are different from the things. So the things in Drupal 8 would be the article something like a user. These are the things that you create. So the configuration in a way is like the mold and then the content is what you get from that mold. And another way that you can think about it that sort of maps these two ideas of things and type of things is site builder versus site editor. So the person who is building the site is creating configuration and then the site editor is creating the content. So that is one of the things that can become tricky right now in Drupal 7 is that configuration and content coexist in the database and they exist in lots of different places. But we try and make a clear distinction between these two. So getting slightly more complicated though is that there are really two kinds of configuration in Drupal 8. One is simple configuration and one is the other is configuration entities. So a configuration entity when you're building a site and you're trying to figure out how I should develop a particular thing if you need exactly one copy or one version that is simple configuration. So an example of this would be something like your site name. You probably don't need 13 or 14 site names. You just need one. And that is stored as a simple key value pair. So that's what a simple configuration is. The configuration entity, again sort of a general concept to keep in mind is that this is zero or more. So if you're creating a view, you might have lots of views or you might create a view but it doesn't have anything. It's like having a SQL query that returns null results. So that's what I mean when I say a configuration entity is zero or more items. So there are other types of data in Drupal 8 and these aren't part of the purview of the configuration system. So for example, the last time you ran Cron, that's not really configuration. It's also not really content. So that is something that we store in the state system. And another example would be like session management information where that too is not really configuration. It's not really content. But for the sake of understanding the configuration system it's often helpful to think about that in terms of your site builder, site editor, content, lots of sort of ways to divide that into two. Now the benefits of having a configuration system are many but let me just touch on a few of them. The first is that between from Drupal 7 to Drupal 8 we have 50 fewer database tables. And that's because in Drupal 7 storing configuration you could do it in lots of different ways. So lots of modules implemented their own ways to manage configuration because there wasn't a single API for developers. In Drupal 8 now that's what the configuration provides is a single way to access. So whether you're trying to access something in the field system or something through views or something in your module, use the same API to store configuration, save configuration, delete configuration and that's what the configuration system provides. It reduces the need for modules like features and strong arm. It doesn't eliminate them and that's kind of a different use case but that is one of the benefits that a lot of people think about with the configuration system. I mean Mike put us at the back and he will add more in a buff that will follow this session. But features now in Drupal 8 is about packaging configuration to share between different sites. It's not about a deployment mechanism for a single site instance. So it's really focusing on its original use case and the use case that a lot of us used it for in Drupal 7 to manage deployment between Dev and prod it's not trying to solve anymore. That's solved by the configuration system. Another key benefit of the configuration system and something that we dealt with a lot while building it was making it translatable. So I have a little quick example here of translating something in Drupal 8. So for example what I mean by that is like say you have this form with your site details and you have your site name and your slogan and your email address. The configuration system allows us to track what kind of data goes in each of those fields so we know that when you go to translate them the email address is not something you need translated so this is the type of problem that the configuration system is solving and it's allowing to have a site that can be translated fairly easy and we know that an email address for example is not translated. Another key benefit of the configuration system is that it's highly swappable if you want to use MongoDB or if you want to use SQL Server or if you want to use files we tried to make it very flexible and I know that's a question I get a lot is people say well what's the best way to do this? Well there are lots of different use cases depending on the kind of sites you're building and it is highly swappable but it is a sort of a feature that a lot of people can take advantage of but maybe not lots of sites will need to and I will say even some sites some smaller sites or basic sites like if you're just building a site where you don't really even need to have a development server you don't even need to use the configuration system it's really set up so it can even just work on its own in the background without needing to swap it or even know it's there but that's not why you people are here So a big sort of mental change in my opinion between Drupal 7 and Drupal 8 is that the configuration system now assumes that the site owns its configuration and to me this seems different from how I thought about Drupal 7 where I thought about it as a module owning its configuration so when the module maintainer changed something with the module I sort of kind of expected that sometimes that might change with my site one of the assumptions we made building the Drupal 8 configuration system is that the site owns the data or the configuration so that's something else to keep in mind as you're building sites as you're thinking about the different more complicated use cases and the reason we did that is because we are focusing on the idea that you're going to want to deploy from development to production so that you've got to move your configuration there the modules don't play any part in that move so at what point are you validating? so if you go in and a module makes a change to a view that you've already queued and you like that old name and they change the name of that view on you like well you've queued that that's not the purview of the module yes if the module like changes a plugin and needs to change the configuration then it's going to go and update the view to make it work but cosmetic things should be owned by the site and you should have full control and the module should just get out of your way so we're going to talk a little bit briefly about how it works before we jump into a demo but in general the sort of life cycle of configuration in Drupal 8 is that frequently it will start with a module providing configuration in a file and when that module is installed the configuration goes from is read from the file and goes into the database and when you need to deploy that configuration from one instance of the site to another you export it as a file and then you import it on your production server so in my mind I have this mental image of going from files to database to files and the other way you can of course get configuration in your site is if you allow your site editors to change configuration in the UI that of course is another way to put configuration into the database that can be exported as files so what's an example of that well let's talk about JPEG quality something that I am sure many of you are concerned very much with on your Drupal sites it's usually the first thing I check is to see what we have that set well the default number for that is 75% so that is provided in the system module in system.image.gd.yaml and that's what this file looks like and when you install Drupal it imports that and here you have that same number on your UI the JPEG quality so what happens when that module is installed then is that number and that key get imported into the databases here I've selected everything from the config table where the name is system.image.gd and that's where it exists so this is the going from files to the database and then when I export my configuration one of the files that I'm exporting is system.image.gd.yaml and that has the JPEG quality again so this is like the most basic example and I haven't changed it now if we did change it in the UI to 85 or something like that then of course that would be reflected in your files this is the mindset that I think helps some people understand the configuration is going from the files that the module installs to the database to files so I have this conversation all the time yes files now a couple of years we were going around saying configuration is stored in files and for a while that's how it was working where it wasn't in the database by default now I did say it's swappable so there are all kinds of ways to do this we chose to switch back to using the database for a number of reasons one was we felt it was more secure that we were using a sort of security by obscurity principle so when you would import your configuration it would go from that module file into your active directory and then the Drupal site would read from that but then people were worried that you could somehow hack that file and you could go in and you could hack a site that way but so we think it's more secure to have that configuration in the database it's also faster in many cases again I'm sort of generalizing but in many cases it's faster to read and write to the database than it is to files this also eliminates the temptation to hack your active config which if you're storing configuration in files what you can do it's tempting just to go in there and change that but you shouldn't do that and by storing in the database it makes it so you can't just go into the files and change that obviously for something like jpeg quality if you went in and changed it in the file it was being read immediately into the site to 85 it's not going to matter say you went and actually which modules are installed on your site it's stored in a configuration object called core.extension if you just went in there and added a module then suddenly that modules code would be loaded during the request and the module has not actually been installed properly because there would be no ability to react to it whereas if you don't store you don't make it easy to change those configuration objects but you make it so that people have to export the files then make changes to them by hand and then run the import again then we can do validation and check that the modules there we can then go and install and react to configuration changes that's one of the main reasons to be moved out of the active configuration out of files another benefit is that for some sites again like the ones that might not even need the configuration it can be convenient if the database basically contains everything that's our main model now with Drupal 7 you take your code you take your database in some cases you also take a big files directory and from there you can work on your own site and do your development that way and by storing configurations separately that did create a sort of extra thing that you needed to become useful as a developer right away so by having that still in the database it does allow in certain instances to make it so you can be more productive quickly or you can again do those simpler use cases where you might not have a complex continuous integration or something like that so if we compare how we're doing things in Drupal 8 then where I talked about files to database to files in Drupal 7 sometimes configuration was provided by files and sometimes it went into the database but then getting the configuration out of your site was not always a consistent process so I have a question mark there to represent that so what do I mean by that so for example in this form array here we have the variable git and that is grabbing jpeg quality so in this particular instance we have that it's kind of it's kind of mixed in there with the other information about the form so this is one way to store the information and something again as simple as jpeg quality we can find ways around but as many of us who know it's a tricky thing in Drupal 7 to consistently pull your configuration information out so this is again the problem we're trying to solve so another really big advantage that Drupal 8 has there is that you only define your default in one place so in Drupal 7 every time you added your variable git for your image jpeg quality you would have to say if it's not set use 75 and so if you made a change maybe you changed the default in one place in the form to 85 but you forgot to change it where it actually was being used then it would still be 75 so as a module maintainer you have to always go okay I'm going to change the default and then I'm going to have to change it everywhere not miss it and then if another module was depending on you they would have to know the default as well but now you know because it's only ever set in one place that the default is going to be the same for everyone it's actually it's a stupidly small thing but it is so much easier at least one guy is excited it's being bitten by the pain once you've been bitten by the pain once you never forget so it doesn't take you don't have to be an advanced developer to tell that this is complicated than this so that's the difference sort of in a nutshell how I like to explain the difference so in Drupal 7 we have the variable table well that is gone in Drupal 8 we still have a similar sort of thing we still have our key value pair stored in here with our jpeg quality that we're very concerned about but the difference is when we want to take that number whether you change it in the user interface or you want to change all your other configuration from your site it's difficult to consistently export that to identify problems and this is I mean no offense Mike but this is the thing so many of us struggle with is making features do this awesome work in a way that maybe it wasn't designed to do but it's the thing we've been using so this is a developer session we know that this using features is the way to handle your configuration in Drupal 8 but it does make some of these issues more difficult to handle now how do I use this fancy new configuration system you're wondering here's another key thing there are two things you remember from this session this is the second one that you can only synchronize configuration between cloned instances of a site I mentioned that before and I'll mention it again but this has to do going back with dev to prod because when you try to export configuration from one site and import it into another site that has a different UUID then it won't work just won't work because that's not the use case we're trying to solve so how do you use it will you make sure first that you have two instances of the same site and then you use this new module this configuration manager module which we'll see and it's a new little section on configuration management and we have the ability now to import and export do full imports and exports and I will say that in general we recommend that you'll be much safer doing full imports and exports because that is how the configuration system can best do its work to check for dependencies when you're moving from one instance of the site to another is by doing a full import and a full export I thought you were going to say something you're just drinking you want to say something so one of the another big change in Drupal 8 is that configuration entities things like node types are often dependent on by lots of things so the simple example would be a field if you add a field to a node then obviously if you remove that node type you expect it to clean up the fields and it does in Drupal 7 it has special code and it goes and deletes the fields but actually when you build out a Drupal site you're building up a web of dependencies all your configuration you might add a view that filters on that node type if you delete that node type in Drupal 7 that view is just broken in Drupal 8 because we have an understanding of the dependencies between everything like when you add that the filter to the view on the node type it goes okay that means this view is dependent on that node type and we store that information in the configuration entity so when you delete the node type it goes actually we're also going to have to do something about this view and that's really powerful it's much harder to break your site which are related but you've forgotten about because you did that six months ago one of the nice things is when you are exporting and importing your configuration we do in the UI give you a way to view differences and here's a simple example of changing the name from site install to new site which is probably something you do a lot not really okay but this is the example we always show up here but when you go to develop your first module then well there is a new paradigm with the configuration system and there are at least three directories that you want to be aware of and understand how they work so the first one that you should know about is config slash install so we at one point changed the name of this to config.install to make it very obvious that when you install a module that has configuration in its directory that's config slash install that this happens at install time so that means don't try and go in and change the configuration in your module that's already been installed that has configuration in the install directory because it's only read at install time the other directory is config slash optional now this one is a little bit more complex it solves a number of problems but for example if you are creating a module and then you install it you're working along locally but then you uninstall it the configuration stays with the site because as we said the site owns a configuration so we had some lots of discussions about how we can handle this but basically we said well we should assume that if someone uninstalls a module that we should leave the configuration there in some cases and that's why we created the config optional directory so you can reinstall a module and it will simply say oh that file already exists I'm not going to reinstall it and then the other problem it fixes is you wanted to say it didn't you I'll let you say it the node module has integration with views but the node module doesn't want to depend on views you don't want to have to have views to use node so any optional integration like a front page view which this nodes isn't required by that module you can put in which means that when you install node it goes okay is views installed not it's going to ignore it but the flip side of that is when views is installed it looks through all the installed modules optional directories and goes hey does any of these have any views for me and can all those views dependencies be satisfied and it will create them so it's a really nice way of like providing optional integration with your module without actually having a dependency on that so say you want to provide a rich UI in your module but you want to also provide a richer UI built with views but you don't want to have a dependency just stick it in there and then if the site installs views then they'll get the nice rich UI or if they don't it will fall back to your so you'll have to decide then again in your particular use case with your particular module you'll have to say is this configuration absolutely necessary for the module to function and so you should put it in your install directory and then you should also perhaps clean it up after you uninstall otherwise you'll have problems reinstalling or you should say oh I want to put this configuration in my optional directory because it's not necessary for the module to function and when I reinstall it I just want that configuration to stay there now we also have to get into this issue of if you were the kind of person that was frequently doing something like disabling a module in Drupal 7 just temporarily we don't have disabling in Drupal 8 now it's only installing and uninstalling so this provides another mechanism of solving some of those issues where before we might have disabled the module now we can say oh I'm going to uninstall it but I want the configuration to stay there put it in the optional directory and then finally the third directory that you want to be aware of is the schema directory or the config slash schema directory and this one is also very important because it describes your configuration so earlier when I showed that in the translation system we want to identify something like email is not being translatable we do that in a schema file so you have schema files in your module that describe the configuration and they will say things like is this translatable yes or no is this a string yes or no is this an integer and not force everything to be stored as a string so those are three directories that you want to make sure you're very aware of when you're doing module development so just a little bit more on schema and we can actually talk about the image quality example that we have like one of the things that people used to do in Drupal 7 is set variables from the command line so like a bit of a drush variable set and you might set that to like whatever 85 but when you do that it can't know what the module expected that variable type to be so every single variable set will be a string what Drupal 8 does is it's able to enforce the type so it knows that if you go and change that through the similar command in Drupal 8 drush config set it will actually save it as the expected integer so this gives us a strictness and robustness that means it's much more difficult to get weird errors when you set like zero or an empty string like it will behave in a predictable way because the actual variable type is strict so the module can depend on the fact that it knows that its configuration is going to be an integer, a float or a string which kind of solves like those really hard to repeat bugs when someone comes into your module issue queue and goes I've done something weird and it's broken like this and you're like how did you ever do that and the reason is like PHP's duck typing is like whoa weird but now that doesn't happen and that's awesome so we have now reached the demo portion of their show and up next is Alex Pop so before I start I was just wondering how many people in the room have actually used the Drupal 8 configuration export import in anger whoa that's cool righty so I'm going to show you something that I've been working on since before Drupal 8 was launched and I'm now working at getting into Core and hopefully will be available in 8.2 but it's a kind of recommended way of working to solve the simple case of like I want to build a site for a client and I'm one of end developers who are working on it and we want to manage our configuration and deploy it to that site when it's in production so build in a local environment on some production so I just would like to emphasize that what he's showing you now I don't think any of you have ever seen before it seemed pretty clever to me so this is new this is like news are there reporters in the room pay attention so here I just have a site which I've installed standard and I've done I've uninstalled a few things like node I've changed it to use my own install profile I've basically just said I'm going to create an install profile of my profile and I've dumped all the configuration into that install profile so quite simply here I have like I'm going to have to move this up you're not going to see that I'll make it bigger so so this is like my own install profile all it contains is like an info.yaml file which says install profile a very tiny install file and it contains a lot of configuration but it's not in one of those three directories that we were talking about it's in a different directory which I've just called sync and that's like containing the whole site and the way that this works is basically I'm going to work on my site I'm going to install some stuff and then I'm going to export my configuration so here I am I'm going to go okay what I really want is a better site name to extend it there is node called I don't have views let's see let's go for views let's have a view thank you quickly come in here whatever yeah I'll create a view I'll create a node type that's what we'll do because they are really simple I don't have any let's just create a log fields I can now come here and use drush drush has got some nice config integration as a command we add drush config export drush sex and what that's telling me is it's going to create these these views it's going to create the views settings file it's going to create some display modes for my new content type it's going to create a body fill for it and it's going to actually add some extension stuff that's going on here it's going to install views and it's going to change my site name and that's just going to put that in my profile config sync directory which is great so I've done that and now it's files and it's a module so I just manage it like a module because it is so I can just add it to git I can have a look and go oh yeah nice it's changing all that it's changing my site name great so I'll commit that version 2 whatever we want to do and then I can come to my other site which was the previous version and I can see a kind of structure and I go okay it's called site install does it have any content types certainly doesn't have any views we can't see that because it doesn't enable views your eye and I can just pull and no I don't need to just whatever so yeah and so I can pull in my changes I can review them before I do anything that all looks good and then I can come to my site and I can just come into configuration put a config sync and as Matt showed you before here is everything that's going on I can see what it's creating I can see what it's changing come in here and do a diff and go oh yeah views is going to be enabled nice and then I can just click import all so what's cool about that is that it gives us a way to manage the whole the site configuration as an install profile so we all know how to manage module versions you know how to push modules to production it's just the same way but what's really great is this new developer comes and they just get the code and they don't have the database setup come to the site now at the moment this doesn't work as well as it could but once certain stuff moves into core this will be seamless but I can come here and I can just choose that profile because it is just an install profile I can go okay install and what this does at the moment is it just all it does is install the required modules and the configuration manager this doesn't matter because it's going to change obviously in an ideal world we wouldn't be filling in the user because all of this stuff is already decided by the profile that looks terrible but quite simply there is everything to synchronize I import everything and as a developer I'm ready to go I can now make changes on this site export them back to my install profile commit so what's happening now what's happening now is it's installing all the modules and then it goes through and it creates all the config entities and then it is finished and now we have the same stuff structure back to exactly where we were there's my blog content type site name and it just works so yeah and the code that is necessary just to make that work just to show you how simple this is so I just wanted to add that when I first saw this what I realized is that this workflow kind of allows that directory to do double duty one it's the install profile but two it's also your staging directory so it allows it allows you to have fewer steps in the process when you're starting up on a new site it allows you to not have to worry about making sure you're getting all your UUIDs and what not correct when you do same instances of the same site which is something that trips people up and to me it reminds me a little bit of like I'm working on a site and you often have like site underscore custom to put all your custom code in and that's kind of the function that this is serving as this one place where you're gonna put most of your your custom configuration for the site so I think based on having thought about this for a few hours that this could be a good recommended workflow that's slightly different from a couple of the other workflows that we've mentioned in the past and so yeah all this all the install profile does is just change the UUID that it generates during install to be the one that's in your config sync directory and it just sets the directory where it's gonna get configuration from to the profiles directory and that's it and it just works and so actually those two steps will go away in the future and all that should happen is what I want to see is just people having to write config install true in their profile and then there'll be a tool so you go and create your site the first time and you're going to drush make me a profile and I'll just create this for you just this and dump your config to that directory and share it with the other developers and everyone can just work on the same site and production uses the same install profile make changes sync where you go those things don't currently exist by the way that's not a thing right now not yet yeah exactly and so right now what you can do the easiest way of working around it is to use something called the config installer module which is another install profile that allows you to take a tarball or a directory and do that but there's already an issue to try and bring that work into core and this is just like a little addition to that work that will actually make it completely simple it just works questions come on up so we can have those for should I go now so in terms of managing like modules that are enabled I've been running the issues with having like views UI turned on on dev and then turned off in prod do you have recommendation workflows for that so there is something in drush that can help like remove modules during the export but we don't have a solution for that at this moment not a recommended one other than just having some process that when you do your config export like actually just manipulating the configuration on that what would be nice is if like some hookfired or eventfired that you could then go and just manipulate and say actually I don't want that module but it's not hard it just hasn't been written yet yes right now it's a little more time consuming to make sure you handle that stuff thank you you mentioned the MongoDB that that would be an option or alternate option is that built in or is that just available if you write it all it's available if you write it like the MongoDB driver got quite far for Drupal 8 but then I think funding dried up but I'm pretty sure that the config table was already handled because it's just a key value store there are no it behaves exactly like a key value store so it's not difficult for Mongo it's not difficult to put it in any key value store like it's simple it's one of the easier things louder sorry so no one of the things in progress is like content deployment tools on the other side I've run into things where it's parts of the site that the end user might want to change like contact forms where they might want to create a new contact form on the production site is there anything that would help to make sure that when we're developing and we're deploying our development changes to the production site that we can avoid overwriting some of those things that we might want to make available so the question was our site administrators are creating contact forms on the live site how do we manage like live change so the simple answer to that is actually when you do an import if there's been differences since the last import so if there's been changes to the configuration there's a warning there so it tells you you might overwrite changes so if you see that warning then the thing to do is to export the configuration from live and merge it into your install profile into wherever you're storing your shared config and then review those changes and go we want those or we don't want those we're happy to get rid of that but that's you have to manage if you allow people to make changes on live you have to manage the process of bringing it back into your development workflow I'll just add too that some people now in Drupal 8 are configuring their sites so that nobody is making changes in the UI to configuration that it's only done by developers in code and pushed up so that is another workflow that could that will probably work for a lot of sites where you actually don't ever want people to change the configuration on the site in the UI only have it done in code so you can manage it you can do your QA that way and there are there's a config read only module that that does that so yeah my questions related to that I mean we have use cases performance config as I could use case but we come across it with module config where we need to change it per environment and we're having constant issues where oh shoot we want to be enabled we need to deploy it so we update the config and now caching is enabled on dev but we don't want it enabled on dev and so we're having problems with that so the traditional way of trying to manage that is to make your active configuration what you expect in live and then do overrides in your settings PHP for your development because you don't generally move your settings PHP that's the way of doing it and so another another big advantage of Drupal is that we've made sure that when you actually edit configuration in the UI those overrides from your settings PHP don't get into the form so that you don't bleed your development overrides up into your production by mistakenly saving some form that has one of those overrides in it's a bit of a head it's good but it's a bit of a headache because sometimes you see you're looking and saying oh this is saying caching is on but it's actually off but it's hard to have what we have before was difficult what we have now is difficult in a different way but it's in a way that's probably better for people we try to discuss about how we could actually tell people that there's an override that is in settings PHP but we haven't yet come to an agreement because of the dynamic nature of how overrides can apply hey thank you for a session I have a question in case if we have a distribution that needs to be installed on the multiple instances what is the best way to approach UUID each year so the question was I've got a distribution how am I going to manage UUIDs I think best practices there are being worked out it really depends on the nature of your distribution if your distribution and you've created like a blog and it is actually the same blog on all these different sites then you want them to have the same UUID but if you're creating something like commerce kickstart and every site is actually a really different thing it's a proper distribution then you don't want them to have the same UUIDs and yeah it's tricky it's up to the distribution to decide so like if it's an internal distribution like power I don't know different faculties at a university you might choose to have the same UUIDs because then it makes it really simple to know that that's actually the one that you've deployed with your distribution but if you're creating something for like general global usage then everyone having exactly the same blog even after they've gone and customized it that doesn't really make sense yeah that's first our is the first case so is it something done in install profile where you said the UUID for all sites I mean is it something said during installation like the same UUID for all sites or it's done so in your instance if you want like it actually to be the same configuration everywhere but you want a different site UUID on each different install then what you could do is you could you could generate that UUID on install for just the system site so do the opposite of what I was doing so that would stop them syncing to each other but it would allow you to push configuration change to your distribution alright thank you that reminded me too that we should at 345 there's going to be a BOF where we're going to talk mic potters here and we're going to talk about ways where you can use the configuration system with features and what the features module has to offer and cases where you actually do want to package up individual configuration which is not quite what you're talking about but that's something that the features modules have are handling but I think Alex and I are both I'm going to be there we're going to both be there and tell us what you think about the session 2 I should say that so which which room is that boffin I've got it here okay it is in 289 next two questions one this place is packed and one line of questions is hopefully this will help address is this like I've I've looked for documentation on the configuration I've never seen optional or sync anywhere documented is this documented anywhere I think so I'm hoping that'll be helpful you know let's see we have a we have a site that we were using it's not documented there it's got to be documented on I know but I have links that might be down okay yeah that's down Drupal 8CMI sounds good yeah we can try and look that great second question is you mentioned preventing people from hacking active configuration I'm a Drupal 8 module developer I don't have any experience in 7 so but I've been having found it pretty much impossible to edit the configuration if there's an active configuration the only way not just the re-amofiles but the import any sort of single thing this configuration is already big so there's a module for you the config develop module allows you to basically always sync between your module and the active configuration whilst you're in development okay thank you a lot of my questions were actually already answered thanks guys but we're really trying to work out kind of a multi-site sort of thing some of the UID collisions complicated and then the updating stuff one thing that we're kind of weaning towards is you know we have some certain things that might be shared amongst multiple modules might rely on say one entity bundle so we're kind of going the route of creating really specific like this module will only call this one thing and it's starting to feel like it might be overkill all these things depend on one thing is there any sort of alternative not really the way in which you make your packages and so that they can be shipped around the different bits of functionality you want that's what features is trying to help you do and work out features at the moment tries to use the dependency graph to make some sensible suggestions around those packages because basically in Drupal 8 features as a module builder and in building modules what it's trying to do is group bits of related configuration and put them together and then let those modules depend on each other in a way that makes sense so it depends on like you have to do some design there and sit down and go okay well what really makes sense what functionality is common for everything shall we build a common module that's going to fall off and then if you find that you're getting one module per YAML file there's probably something that's a little bit weird about how you're trying to deploy those features it is pretty complicated so we're trying to work all that out right now thank you on one project we were working on we found that occasionally we'd have issues with conflicts where multiple developers were working on the same project configurations would get overwritten if you affected the same like configuration file or like say a developer did a full configuration export and accidentally committed things to like the sync folder that weren't necessary do you have like any workflow recommendations for like minimizing those conflicts when you've got multiple developers yep I do two recommendations one use get because it will detect conflicts when things have been changed by two different people so treating your configuration like code and extending from using get as the way to store and manage conflict is a proper code review treat your configuration like code and have people review it so the reason we chose YAML is that it's very easy for humans to read and work out what that's doing so you should be able to look at a change set and expect to changes or that doesn't because that's the whole point it's about taking the care of the quality that you would over code and treating it the same way hi we're currently building a Drupal 8 install profile for university installation so basically it's sort of distribution all sites will start from the same footprint that will evolve into the future the question I have is many sites won't need to use config management or the configuration system as far as workflow goes they'll be in dev, they'll go live and then their site will continue to evolve there but we will have some custom ones that will want to use a get workflow to deploy configuration I'm just wondering if there's any recommendations on how to do that is it a custom module that's particular for each site that loads its own configuration what would be our best way to tackle that it depends on whether you want to share that feature between different sites if you do then maybe the features module and using that to package up the configuration is one option for you or another option is just in those instances let those sites have their own install profile and manage it the way that I demoed here today and just have a specific install profile for those sites which are custom and have a generic one for the common use case that's what I was wondering is it possible to have them just have a I guess it's the same thing just a custom module that also contains other site overrides and configurations and code that also loads their own overridden configuration or override configuration it's possible I was wondering if the CM management I guess that's redundant uses drushmake is drushmake still a thing in Drupal 8? so drushmake is solving a different problem it's composing your code and the kind of the hint and the answer I'm about to give is in the word that I just chose basically in Drupal 8 drushmakers will be replaced by composer so you will create a composer.json file that says that I want Drupal and I want these modules to be installed and that will go and get all the code for you and then you will run Drupal and stuff I know people have mentioned using different modules and different instances so a composer can say grab certain things and modules in certain instances and other things and not and then the configuration can be on top of that yeah well that's just the standard like code management so you could do it that way if you wanted to have a different composer file for all your different projects but that's getting into it it's a custom build right I heard you mentioned build but this is sort of configuration not actually configuration for builds that's out of scope a bit yeah that's out of scope great thank you I just wanted to answer a previous question about finding documentation for this I'll put a little plug in here for a website called drupal.org web page slash list hyphen changes and this is not documentation per se but it's where we have tried to always document things that have changed from Drupal 7 to Drupal 8 so I just looked up config slash install on config slash optional and I found information here where like here is where a change record for when we added config slash optional which links to the issue where we added it that's not the best place to look but right now that is one of the best places to get documentation so that's one place to look but we do have information on the configuration API page so api.drupal.org configuration and it talks about like the optional module in the folder structure and that kind of thing here so yeah and if you find missing documentation all docs pages on drupal.org are editable if you're logged in please feel free to contribute so another kind of thing that I've been kind of trying to work out is when the line between content and config is a little blurred you know we saw like the modules for being able to import content but there are benefits to an example is taxonomy where traditionally a lot of times terms would be a lot closer to configuration than content and you know we're looking at it and it's like well this would actually benefit a lot from being considered configuration rather than being used in this content way so that we can have machine names and all this sort of nice stuff the whole configuration system I guess should we just try to say okay if it's as content in drupal then we should treat that as content and try to figure out some different way to manage that the more configurative taxonomy terms or is there like an alternative to that I mean it's it's hard because like once you start to like go okay we're gonna swap out taxonomies and try and like back them onto config entities you're going kind of off-piste with the way that taxonomies are designed to work so you might break like you might say in this one time oh I want to use this nice taxonomy access module and suddenly that's broken because it makes assumptions about taxonomies that it can no longer make because you've changed how they work so generally I would advise trying to not do that so either consider like is it really a taxonomy you want or is it just like a field with a list of options and then that's all configurable but if you really do want taxonomies and you want to deploy it then it's like look at like modules like default content and use that to like deploy to create taxonomy terms when you're doing like module install or in your install profile and hopefully in Drupal 8 sometime we will get to explore the possibility of adding like content deployment or default content to core because it's needed so it's a common problem I feel your pain and we haven't answered that question apart from the fact the only answer we've had is that taxonomies are content for the use case that we've decided to solve in core I mean one thing that I've kind of thought of was just having my own kind of taxonomy or term config entity what do you think about that like just saying well this is close enough to being its own thing even though it's like taxonomy so I'm going to call it config that way it works better with that but seems like you're losing a lot at that point yeah well that's exactly what I was trying to say you then like block yourself from being able to use like taxonomy based modules in the future to solve that new use case that's like your highest priority because your client's going like I want this and you've got a contrary module that would solve it if you just not made that decision six months ago thank you we're over time thank you all for coming thank you