 So hi everybody Well, this was meant to be config 1 to 100 hi Justin waving to me from the back It's meant to be config one site to 100 sites But it's kind of one to infinity if you will because once you get past one you're running with everything, right? Unfortunately, I probably should have gone for a longer session in 20 minutes because it's kind of hard to squeeze all this in So I'm gonna go at a reasonable pace and if you have questions at the end I'm around and you can pick pick me out on Twitter or something and I'm happy to answer some I also come from somewhere where they speak very fast So if I start speaking too fast, then you want me slow down, please just like wave at me and I will So my name is Ashley Hazel. I'm head of digital technology from Hogarth Roblox That's my slack and sorry my stack or flow my Drupal.org names pretty easy to find just minute And we jump straight in and we talked about what is config and why do we want to use it and in Simple terms, we're just capturing site settings into code The great thing about this of course is it makes your settings versionable Portable and of course shareable which is where we're going to get to this in a minute In the end, it's just a bunch of YAML files YAML files that roughly represent our database dump, but Being separated out into files into YAML files. We can break them up and package them up in different ways Cool, so they are versionable shareable, portable, dividable, reusable and really able so generally config is great and it allows us to really Expand on the way that we're moving our content around our sorry our settings around But where do we start with our one site? It seems kind of confusing when you start getting into documentation and the way we generate all this is simple Sex of course mean sex One simple trash command and we're off and we're running One simple trash command, there we go and then to complete the cycle Drops it in and we're flying we've got our config export and our config import everything truly. This is it This is you up and running with config But the next question becomes Where does it all go? Right now by default it's going to go into your files directory Under sites default files config underscore a random hash Which is great? It gets us up and running, but it's not where we want our config to be because our config generally can contain some Sense of information, maybe it's an API keys or something in there Maybe you don't want them to be there, but they can be there So we add to our settings PHP this line at the bottom of config directories Conflict sync directory and we tell it where we want to put it and generally we want to put it outside of our Dock proof in order to keep that prediction and most importantly actually and maybe not most importantly But most usefully most of us are probably excluding our default files. They're actually from kits We don't want all of that in there So by removing config and putting it in a more central location. It becomes easier for us to manage it Cool So if we take a step back and look at this in a more conceptual way This is basically what config is right? We have two things we have our active configuration that exists in our database And we have our file system configuration with all of our yaml But there are things that we want to be specific to our environments We don't want to have everything in there and there's two ways to go about creating these sort of local overrides This I think is how most people perceive local overrides you have your settings PHP you put some overrides in there And then when you do your import it's going to somehow be overridden, but this isn't actually the way that it works The way it works is more like this that You have runtime overrides Runtime overrides being that when you do your config import you're getting what's in your yaml files And what you have in your settings directory is only Use that runtime so when you look in your yaml you're doing you export or something You're still going to get the old settings. You're not going to get what you've got in your settings file and of course we can use local settings files and Dev setting file or environmental based setting files to do those overrides as we go But there are some things that you can and can't do with this method You can't create you or completely remove any config that already exists because you're only altering config That is already in your existing yaml files Well, you can only overwrite stuff that already exists. I sort of said that one already Because of that there there's also some strange limitations you can't override some theme settings for some reason and Really weirdly you don't see your changes reflects in the UI So whatever you have in your config yaml is what you're going to see in your UI Which can become really confusing particularly if you're trying to debug things using examples an API key or something if you've got your Sandbox API key in there and you're seeing your production one. It's it's very confusing So maybe not the most sustainable way to work with overwriting things So how do we handle that you know what I jumped ahead with myself. I apologize We'll come back to a better way to handle local overrides in a moment first off There is obviously a place of where config isn't config and what I'm talking about here is the overlap between content and config I'm not sure there's a word for that something like content fake Tenturation, I don't know Principal thing that I'm referring to here obviously is webforms They're great. They're almost certainly part of our settings, you know, we want to essentially manage our Contact forms or some special form that we've done a bunch of work to modify and have some overrides on But they're also definitely not config We sell Drupal one of the big selling points to Drupal is that we have this great form builder And then our clients go and they set up their forms or they alter their forms And we gonna do deployment and we delete everything that they've done before So of course There's a module for that In fact when we start looking there is a bunch of modules for this Config ignore is the one that comes out the box straight away allows us to ignore whole swaths of Configuration on a module by module basis as well. If you guys were in the config management 2.0 presentation yesterday, you know, this is becoming somewhat redundant But at the moment, this is definitely the way that you do it very quickly from config ignore We find that we have webform config ignore, which is even better It just does some of the niceties around handling webforms You get to ignore them, but at the same time include them. It's it's a really nice motion I had are going to get a little bit But looking at both of them straight away We see that using something called config filter and when we discover config filter We realize that maybe there's a bit more in the way of modules that can help us with config and very quickly We find ourselves coming to config splits, which we'll come back to in just a moment finding that there is more in the way of Modules than we thought there might be you go and have a quick search you search for config and boom you're just overloaded with Hundreds of modules the fact those 1200 modules come up in search I don't think all of them are actually related to config obviously, but just in the first public pages you know you get a bit of a migraine and going through some of this you find modules that are either redundant or They're similar to one of the other modules and you get a bit lost in where you're going So definitely a bit of a model minefield on the go here and generally you can ignore most of these There are some interesting concepts, but you have things like Can I see them on the screen here? Maybe not there There's a couple of modules here that allow you to create pool requests So when you've got your editors or your client making changes on your production site You can create a pool request to get those conflicts back into your Systems and then on the other hand you've got things like config ignore Which is or reconfigure it only which is there to stop your clients from being able to do that So these really depending your workflow, but for the most part you don't need them of course You can't look at this without coming across features So I have one slide on features and It's a really simple slide Don't use it, right? Yes a reaction Why not yeah, I'm going to say why not? So features was great right Could become a bit of a headache granted, but still great But it's it's really redundant with config management Features is taking your settings and putting them in code Config management is taking your settings and putting it in code What features does and actually it is great for development because what features does is it gives you a little bit of a UI to find out Which config you want Dumps in a module and as an extra YAML file it says you can't use my module unless you turn on features It's kind of pointless By all means use it to get yourself up and running and to learn how to create modules with config But delete the YAML and use it as a module that's all it really is And actually this is back to my point in the beginning that config is Dividable and packageable you don't have to treat it as your site config You can then stick in a module or distribution or a number of other ways of taxing out so Flying at this obviously quick recap of where we are so far We've had a look again started. You need one drush command in your way We've had a look at the file system and fact you want to move it We spoke about the drush commands and we looked at some local overrides Which maybe wasn't the best option? Where config and content meet which is principally webforms, but there are some other examples and the fact there's a bit of a module minefield so Next we need to up our game a little bit right and look at more sustainable Overrides because the overrides in the settings file was great for certain things for sure. They're not what we want generally So that brings us all the way back to config splits Conflict split does well exactly what it says on the tin it allows you to divide up your config into different packages and The defacto example here that I think everybody does is they divide this up based on their environment, right? so if we oh I have more slides. I apologize the split sense subsets The subsets can be cracked criteria based and it's actually a really good point The obvious example being there those environments But most importantly it has the full power of config management unlike our settings file where we were limited by What we could override and the fact that we can only override things with config split we are able to We're able to have full control over what we do and we don't want and most importantly for site voters We see the changes in the UI Sorry, I'm tapping a bit faster and I'm confusing myself So we can create new content. We can delete content with a config. We don't have to just override what we What we already have we can override literally everything and we see the settings in the UI So no more red on this page here, which tells us that conflict split is Definitely a better option than the settings file So going back out to our conceptual Overview the map has changed slightly right? We have our original import export with our active and our YAML file configuration But this time we're passing through config filter and we're splitting out our config into different packages and then re-importing them Just the ones that we want After a little example here of what might have been in the the dev The dev import and for those that don't know which I imagine most you do these zeros obviously aren't To disable those modules. That's not a typo of dev. The zeros are weight So you can set the weight of how your modules are included But it's a big thing with split that you're able to control what you have on and what you don't have on in your different environments cool so Who says that we need to name our splits? local dev and production or life If we change the names because the names really are just arbitrary to something more like agency client brand Suddenly we see that we can actually really begin to flex this system to do an awful lot more And again, if you're in the presentation yesterday You'll see that this is not how they intend this to be used and they're changing the config management system so this is Your wealth to change the way that we do this, but certainly with split the way it's designed today. You can just split up your Configuration into packages that make sense to you and you can import them in a way that makes sense to you If you're following this pattern, I would probably recommend that you use a profile Which in the end is just another module, right? So we can subdivide and module our content for things like your agency type config, but certainly where it comes to Generating an import for a particular brand or a particular client There's no reason why you can't use your splits to control that particularly in a multi-site environment But there's a problem, right? You have the site EU ID which prevents you from sharing configuration from one site to another So if you're trying to do that Agency brands client server divide you're going to run it to the case that you you are sharing config and it doesn't work The number one solution that is As I just said you can use a profile or you can fit some of your config into a module or you can cheat and you can Change it to change the site you you I need to be the same which depending on what you're doing Can help but the thing is it's not a problem this right? It's a safety net the EU ID is there to stop you accidentally wiping out a site that you didn't mean to So I would say do this with caution It definitely works and if you're in a multi site, it's maybe something you want to do But yeah, it's there for a reason. It's not a problem. It's an actual safety net. So be careful if you want to do that Cool So a really quick example Now actually I thought I was gonna run a time much faster when I run through this. So this is a really quick example So I'll put that a little bit Looking at standard multi-site. We have our shared code base, right? and then normally we have our shared default configuration using this settings file to put it outside of the file system and Then we have our Brands X and we have our brand Y or Brandy. That's how I say And each of them contain their database and their assets But they can also contain their own config as well using config split so we can Do our install use our shared code base get our shared default config and then import the split that we require just to adjust those Sites ever so slightly You know things that you might want to include here are the obvious things like your site name To the modules that you have enabled To maybe some more complex things around Well actually I guess modules about as complex as it gets really right It's it's actually a relatively straightforward and simple system when you get into Using it this way So cool that Is basically that that's all it is very quickly we have the contributions day and There is also Review for you to leave But that's us done and remarkably we have a couple of minutes to spare Sorry if I did speak too fast, so I ran through that too quickly, but Any questions? You want to come down to the microphone? Would that be a way to split configuration and like feature like Portions Yes, so I'm not sure that picked up properly. It is their way to split configurations feature like options And the answer is yes I mean you can use features to help you get going with that, but literally this is just splitting configuration into modules And once you get used to the configuration Explore and what the files are called what they do it is very simple to create those modules and to Separate out your conflict something we do a great deal actually is we break things down Sorry, we break things down using paragraphs to create components, which I'm sure everybody's doing these days But we package that up into a module as you would with a feature I have another question you say before that you suggest to don't put the config file into git No, no, sorry one of the reasons you would want to move it from the files directory and Possibly but above the doc group is because you definitely want to have your config files in git. Okay. Yeah So when one simple question but you find it frustrating that In the end you change so little configuration So basically maybe you even just the only configuration it changed was you changed it the site name then suddenly you do config export and you've got Hundreds of files there that you know the only difference between that and what is in core and in the contrib stuff is Now it has a UID and one of the files has a new site name Wouldn't it be more also interesting to have slightly better tools that don't export needlessly so many changes Yes, I'm not really needed. Yeah No, I see what you mean your your original export even if you just install the site and just do export you get thousands files with Absolutely relatively no bearing on you, right? And it seems frustrating initially and certainly it's something that our team has discovered Or come across is if you've got a large multi site with say 60 or a hundred sites in it You have a hundred directories with theoretically thousands of files in them for no good reason, right? But actually I think it makes a lot of sense to have those files is a bit frustrating me the first start but once you begin to subdivide them and Put your config into your modules or using splits to split them out across the grounds you're working with those Exports become much smaller and that original bulk export you probably put it into a profile or something. So you're only really dealing with it once Sure, they're about to kick us out can we do just one more question Hi Yes, the UI will show you what's going to be an important exporter so will it rush commands they give you a warning before you do it Thank you