Advanced Configuration Management in Drupal 8

welcome so hi I'm Mike I'm a Drupal developer it's been three months since I use features hopefully today I'll convince you to break the habit as well so I'm currently wanted to maintain ardila features module roughly a version is this 77.2 version also the architect of the open atrium to distribution and what I want to talk about today is a lot of things and I mark this as an intermediate class and so I'm going to do the beginning parts fairly quickly so I'm hoping that people mostly know about config and eh but I'm going to run through it really quick anyway and then try to get to some bad stuff because what I want to really cover is the hard stuff that we have to deal with day-to-day and why config management is still such a pain even though it's still one of the greatest things in v8 and why we still struggle and what some of the new solutions are who here was here at my talk last year on configuration best practices anybody okay so sorry I'm going to change the answer because as the years go on things change we get new modules we get new ways of doing things and that's what I want to talk about today anyone here read my blog last week I'm stopped using features getting a couple people good and that's going to be part of it too let's get into it so quickly reviewing config management for people that go to just starting out here so you've got this big verbal database your big my skill database and there's all this stuff in it like your pages and your articles in your comment to users and we call that content right that's the stuff your users are putting on your site and then there's all these other things in the same database there's your content type your field your views all the miscellaneous site information checkboxes all the stuff that you do in the admin interface to customize your site and we call that config and the problem is those are both in the same database and yet the dilemma is that your configuration is coming from your developers if your developers working on your content types in your field and your views but your content comes in your production users they're the ones on the actual production site creating articles and blog commenting so forth and so how do you take those two pieces of the database and merge them together you know how do you pull the config from the developers and the content from users and keep doing that over and over as you update your site so in d7 the way we all did this was with features and we took the config and use the feature module to export that config into code and then we have these feature modules they were just part of your code base you would deploy and with like the rest your codes and get and everything was mostly okay I mean it was d7 so we'd have all this problems but it was kind of the only thing we had around right so the new gateway it's built into core is used something called config export to export the config and this time instead of going into module code they get stored in something called your config sync directory and they get stored as a bunch of gamma plot and the a mole is just a data format we'll see some examples later so unlike features which can be 7mate PHP code which is what is kind of weird like you're storing data but you're storing linguist code and all arrays here you're actually storing that as a proper data format and it's all in this directory called the community directory which you can kind of put anywhere you want so let's look at how you're supposed to do for VA deployment of configuration so when you start with your dev environment and you run one of these config exports and that's done with all of those gamma files in their config sync directory and now you're going to go to your stage and QA server and you're going to do a config import and that's going to low and everything that's in the config sync directory into the database and overwrite anything that's there so it's going to essentially fill in that top piece of config but it's going to leave your content alone so it emerges those two databases and now you do all your TOS maybe make sure it works you tweak your config however you need it you now react for that updated config that's now working those two the same convicting directory and now you've over to your production environment with all your production content you import the config and now again you've pulled in that top layer you now have the working config with your production content and life is good right so the way you do this technically is first of all you can specify where you want your config stting directory to go by default NDA is going to store it in your files directory because the files directory is really the only place that's writable typically on your system but for most of us we want to manage our config the way we manage our code we want to get it into our git repo so we're typically going to change the sync directories of someplace else other than the file directory that has write permission for the DES that we can put in our git repo so for example you might put it in a top-level config slash default and we'll talk about why it default a little later so now you add that directory to your git repo so you do it get ads config slash default and then on your dev environment you do your dress config export so here I'm going to be talking about you can dress hopefully all you guys are intermediate and are used to using a dress there's a limited amount of stuff you can do with config and v8 using the UI using is config synced UI the problem is it's a lot of life downloading the tab all and uploading tarballs and moving the stuff around that we don't want to have to deal with so just use dress or you can use console if you wanted the dress has become big export command so that's going to take everything that's in that config parts database it's going to write it out to that config default directory we've added it to get so now you do you know it get disk get status check to see what what you're about to commit just like any other code being really careful on this step it's really super important to be a to view this step we've always wanted people to do this step but now it's really important you don't want to push too big that's bad you don't want to push stuff that's left over from from your technique so review what's about to be added and then go ahead and commit it push it to your develop branch and now over on your QA server you do address config import you know you're first going to do is get whole review what came in with rest config import and now you're good so this all sounds great and easy we've been talking about this now for years right this is one of the great things in v8 so why are we still talking about this after all these years I mean we're on 8.3 now going to 8.4 and I don't know about you but config is still something that's our guys doing a lot of time dealing with and it should be that way so what are some of the headache why doesn't the base config system kind of work as smoothly as we would like well the first thing you realize is you can only actually import configuration using ingress config import if you have the same site ID so in Drupal 8 every site has a unique identifier and it's actually stored in config which is an interesting test 22 and when you initially install Drupal for the very first time it's going to create a new random site ID for you and that's going to store it in config and so if you spin up a DA tight and you export your convey when I spin up a DA site and I try to take your config and import it it gives me an error that says your site ID doesn't match I can't do that so what's really important is the biggest transition the kind of aha moment the people that like people have with PDA is in da your configuration is owned by the site in d7 with features the configuration was owned by the modules like you created a feature module that module owned it if you reverted to features any new config in that module would take effect right and would overwrite any customizations you made like how many of us have feature reverted and lost stuff right because we didn't realize you know the super client had gone and changed something interview somewhere so the IBM v8 was to make sure that that didn't happen anymore so instead of having modules on their config the site owns the config and it's trying to do a lot of checking to make sure that you don't lose stuff so it checks these things like new IDs to make sure that you're not like accidentally overwrite your site with somebody else's site that might be different but it gets even more complicated than that because each individual config item every field every content type every piece that config has their own unique identifier and that is created randomly when you initially create the config so if you create a new content type and add a field to it that new field getting unique identifier so now the column is what if you've got to developers on a project and they're working on like the same ticket which they should be and one of them creates a field protesting and it's worth it and now I create a field for testing and I try to import the other developers stuff it's going to get new IDs and it's not going to import the config so it's not an existing site idea it's the individual configuration ID that can sometimes be a problem the other thing that can mess you up sometimes in VA is that config import command that I saw you address it will tell you what it's about to do like it will say hey there's all this new config that's being created so guys can't sit on the floor that finally the fire marshal is on site so sorry is there any way we can make green for somebody up front here and everything right here okay okay thank you so much for needing yes so when you do a config in court it will tell you what it's about to do so it might be creating new config it might be updating this new config or it might be deleting config you know if you actually delete one of those yellow files in your config sync directory and do an import it's going to delete that keep it in your database and that might be convicting you want it so you have to be really careful look at something important what it's going to do and even the standard profile will do that sometimes if you do a standard people install and probably do a config import it's going to complain that there's some shortcuts that got created of is about to breathe so some useful day-to-day brush commands we talked about this command a little bit here's more on it so the stretch config export there is if you do a help on this you'll see a lot of options honestly a lot of that a lot of those options are for doing gifting so they kind of like merge some git commands with the configure export commands to it like will automatically add stuff and a lot of method commit it will even automatically push I tend to not use those I prefer just use the gifts that I don't love to do something wrong but you select you bike there's often this optional label so by default it's going to use your config sync directory that we configured earlier and if you go back and look you'll notice but when we set it in our studies PHP we gave it the key sync now it stinks is the default name that it's going to use when you export you can actually create multiple export locations and name them whatever you want and when you do a config export you can say hey config export over here and give it a different directory name Elizabet so all the config commands kind of have that label and then config you import has the same label the other useful option for config import is if you want to see what's going to be changed at a more detailed level you can say that that preview equal to dip and it will actually show you hey in your site settings you're going to change the title of the site or something like that right it's going to give you those details and then there's this partial option that we will talk about so what is the partial option and what is it goo and why should you be careful so first of all to even make partial work properly at all make sure you have direct eight point one point O or greater what partial is trying to do is get around this issue of deleting can bid you probably don't want to accidentally delete stuff you're working on like maybe you're working on two tickets you're working on the blog ticket in the article ticket so you've already created the blog content type and now you know the PM says hey we need to do the top picks so you try to switch over to the master branch pull it in yo hot pick to do a config import well they something have the blog yet right and thinking for it's going to delete your blog if you're in the middle of working on it you know you may be having staff that yes and so you don't want it to affiliate over life the stuff that you've got on your database so the backtest partial options will kind of do emerge without deleting and so some people like this for convenience because they don't want to lose the stuff there in the middle of and they don't want to take the trouble load in the database backup and restoring in a clean pod database but the problem with this is as soon as we do a config import partial you now what I have with you now have what I call dirty tube is you've got the production config plus some random configs and you're messing with and develop okay and it's really easy to accidentally export that and get your dev stuff stored in production or in your repo so certainly don't get in the habit if you're in the habit break it don't use git add say don't do just committed a keg review your changes before you do a push so if you do a config export take a look at what's about to be pushed and make sure you don't have like that dirty blob but you're in the middle of working on that isn't ready yet you know you can undo that at that point but the best way to really view this is if you're going to do hot fixes you know stash your changes backup your database restore clean prog database through your hot fix their big export then go back to your you know branch that you're working on restore your def database so you know it's not that hard to take and restore databases these days doesn't take long and try to avoid - match partials it's it's there but I don't think we need to use it anymore so it's some other irreducible dress commands so if you want to mess around with low-level config and actually see where something is like maybe you don't want to navigate to the UI to look at some setting you can do it big debt and give it the name of your config Eisley and it will actually show you what's in the database now we're going to talk about overrides in a little bit overrides are things like in your settings or more detail on you can use access and clean overrides to actually show the overridden value so maybe it's not the actual site name the database could it be overridden site name so consider can be useful for inspecting the database and then of course greater config set option to let you this quickly second option will see an example where that so you pull a little bit later and even better there's a config edit option that will bring up that whole config on file in your local editor so maybe you don't want to go off and find it in the config sync directory and you just want to edit it live maybe you haven't even exporter to get config edit will load the config out of the database create that yamo file that you edit it and then changes you make will get written back to the database again it's great for developers definitely don't do that on production but it's useful too so at the bottom and maybe you don't even know what the config idea if something is so you can use config list so like if you do dress config list field it will show you all your field builder storages so anything that starts with a given prefix value it will display for you and then if you really need to you can delete config with config delete be really careful with this it will actually let you delete sometimes config that has content associated with it it's really actually kind of weird command if you delete a field storage it actually won't give you an error but it won't do anything if you have content because it knows you don't want to delete the field storages but if you tell it to delete a field instance on the content type you'll go ahead and do that you can see have content in there so just be careful useful giving for development purposes but not for a day-to-day so let's get into so I was a quick review hopefully all that stuff except you mostly knew about so now let's talk about some more complicated stuff so how do you actually spin up a site like you've taken all of this time to build a site create content types create field it's all working the way you want wouldn't it be nice to just kind of clone that site and yet not clone the content right I don't want all of my test content production content maybe I need to spin up a hundred sites I know a lot of you do that right you've got to spin up a bunch of multi-site stuff and you want them all to have the same content type in the same fields and the same reviews and all the same configuration so wouldn't it be nice if you could install the site using the gyro config and it turns out you can and this is something that's actually changed pretty recently so what's what's involved and kind of spin an epicyte now I I like to start with a profile mmm be a a profile it doesn't actually really have much in it because you're probably going to use something like composer to list you know here's all my modules and what verses they are and you're giving you poseur to actually build the site so profile fitness they have a lot in them but it's going to be useful as you'll see in a minute to start get one so on till one day like your mean technique they're going to start doing the initial install of your profile for the very first time and there you can use dress site install whatever your profile name is and your profiles can just be a dot into a politic map have any month modules or anything else is just something that lives in your program sector so address will go ahead and install that site and of course it's going to give it a unique site Ivy at that point that's going to now become the canonical site ID for all of your other instances of that site this was the first install the first time you started from scratch so now to go ahead and make sure that in your settings FTP you've got your config directory set so back to that earlier step where we put it into big slash default go ahead and do that now pretend you're saving type PHP confirmed the install profile is correct that should happen during themselves just double check the defensive profile name once those two things are set now you can go ahead and do your initial clean export so you haven't created anything yet you don't have any content types or field reviews you just got a clean install of your profile do your initial consider importance index board and then add that to your repo your code and now you've got the clean site okay go ahead and commit it in push it - here we go so now what do we do is that how can we create our second site using this code replay so now this code repo has Drupal core and it has your initials and fixing directories and it has whatever modules you've installed you know for your composer to process so what your second developer is going to do is going to install this site using your config and there's three ways to do this I'm going to give you a key a newish way that I think works best about two older ways you might already be using so what I think is the current best way is to use a pass and I've got the core packs down there at the bottom this pass is working its way through core it might make a point for but times getting short - we'll see but it's there it's being worked on by four people and we config management for people like they'll recognize the name I mean the pretty simple patch what this app does is allows you to put your config directory into the profile so you still use the same brush site install profile name that you used before that in your profiles info dot yellow file you add this line called config install and you tell it the path to your consistent directory okay so here we put in big slash same code and in my previous example of explicitly config slash default so wherever you put it right and it's likely bulking defleshing now one interesting trick here if you want is if you put your config into the actual profile directory like under profile profile name where you're normally your custom modules we go if you actually create a directory in your profile called big feet it will load that automatically so you know how you normally put your initial config install directory so instead it's complete install you put it all in sync and it will actually load from there automatically without even using the config install key so the config install key isn't over life for that default so what this will do is when you through the site install it does a little bit of magic it actually checks the sink directory first to see what the site ideals and instead of setting the site ID randomly it sets the fight I be using the export it too thick so now you have the same site ID that your previous site tab has having to copy a file or verbatim you just install really things exactly so you're applying experience like you're not copying the site over to the copy type over you're going to get all content to so here you want to create a new clean site has all your competitors without your content so it's going to set the site ID and then it's going to actually do the config importance so that the text 22 is config import like if your existing using brush command right you do add rush site install or the dress slight install sets a random site UID and now you try to do is thrush config import that says I'm not going to do that because your site nature of match so this little patch this kind of reverses thing and testified ID first and then it does the config import as does that in core now using the install so you don't even have to use rush site install with this core patch you could actually go into the UI and you know do it do a normal interactive install you'll see your profile listed is one of the available profiles and then follow that profile it will automatically do a config import so a really useful patch another one that people have been using before this pass because the patch is relatively new life it's been around for a few months now previously there was this new option added to dress site install called the config and so you can do a stretch side install your profile name and then configure and give it the name of your the past year and fixing directory or config slash default and there is the meta issues that talked about kind of all things related to installing stuff experiments config so this kind of work the begin because it was a Drudge command it has some issues so it did it did set your site ID correctly so it had that correct problem or left that correct solution but the problem is what if your profile actually has its own config that it creates at install time like let's say your profile dynamically creates a okay in the previous case your site IDs are all set before you migrate that people and so everything is good here it's going to actually create the field during install time and then rush even though the site ID is going to say now dress is going to sync the config that config has a different new ID for the field storage and things like that and so what it can do is you can end up telling you later that there's a potential schema checked so it gets confused sometimes the things that maybe the field story is different between the two because it's five chains in the UI B so it doesn't prevent you from installers you don't get any install error you don't get any you know anonymous batch type u ID or UID it typically happens after you run cron after you run chrome if you've written your triple Status page we'll say you have some uncommitted config changes or schema changes and the FD answer yes to that trouble this happens every time you do a fresh install so every time you do this command like I'm going to install a fresh spice today I do this command I run cron now I have to say yes to all these energy changes again you'll see this right now in lightning and there's a lightning issue that I've listed there for you but it actually also happens to disk install the standard profile and Drupal if you use this command to install standard than run cron you'll see semantic changes because of course standard installs things like page and article during the install process so it kind of works I think people have been using it they might not be aware of these issues they may be see the any changes and go I'm not sure what caused this but all of this get yes and hope everything's okay so it's just a little bit rocky so still usable but I prefer the core patch previously and then so what about the Installer this was talked about a lot a year or so ago Alex pocketed this to try to kind of start this whole process of how do you install config 312 sites using config so he wrote this profile called config installer and when you have this project installed this profile installed when you select it from your installer prompts you either uploaded tarball or to give the location of your convicted directory and tries to install from that it's getting old now it hasn't been updated since February I can't get it to work with lightning for example and it's kind of weird because it's a profile itself and you're installing a profile with that profile and it has to do some magic to like get rid of config installer when it's done and so it's a little rough around the edges like I say I think it's just maybe not being you know maintaining in favor of this core patch that's trying to get that's all in the core so if you're still using config installer you might want to take a look at these other this other patch to be effective better mandatory okay so great that lets you spin up lots of sites based on your profile they all have the same config they all have the same line beans everything is great and this is what we do good at sites it works really really well so what if you do have to act you have to set the side ID manually I just want to clear this in especially for people with existing insight it isn't actually that hard to do in community you basically will look in your system dot sight config and you'll see this thing at the top that says UID and there's your site name there's your site admin email everything else that's in your system configuration so you can go ahead and you can copy that UID to your clipboard and now you can use the dress config set command to set the system site UUID and paste in the UID and it will actually didn't prompt you if you want to update your new ID and you say yes yes that's the method you need to specify that you manually for some other reason because you've got to mess it up site how about updates how to update to work with config profiles so let's say you know you're updating considered maybe that's big changes some schema and now you've got some updates looks to fix with schema or update some content when we change to feel this or you wrote an update clock like you should so what order do you run update versus config so this is the order that you run things we pull your code do a composure install because maybe part of that whole updated linear module versions and so you want to get the latest version of your module this assumes that you've got your figure compose your lock file also as part of your repos that everybody is all on the same page under the version so now your models are all up to date now you run update cooks because now you've got the updated module has the update looks good so you run update look first now update hooks have done whatever it needs to do to make everything work so that when you do big import you don't have any schema changes so that's the correct order do not do an import before writing update hooks you'll run into problems and in fact this is about the beginning forced in course there's another core past that probably is going to make it to 8.4 and if you try to do a complete import when there are pending updates it will refuse to round so it will force you to run update books first so then the next complexity is people run into all the time when you're building complicated sites is you know the site owns the config that's great that's one key dory wonderful so you know contiguous at the painting on my sites you've got your your seduction environment with like your Google Analytics API keys and you don't want to use those API keys on your dev environment because then you're going to pollute the clients Google Analytics page with all your dev stuff or you're on production on aqueous and operas got aqueous nectar installed so it can talk to the aqueous stuff you don't have that on your dev site so you've got two different config and yet Drupal 8 is designed to make the config identical across all your sites and it doesn't work out so well and this is one of the areas where people were still kind of missing jersey style so what's the solution now so you've got your different environments like local days prods you a Romania environment they have there's a new model or a newish module called config split it's getting a lot of attention and a lot of use I like it a lot go take a look at it when it does is lets you split configuration into different directories and then when you do the config import command it will merge those directories together to do the import so it has a nice UI you basically go into the UI and you create one that's like this yep so you go in the config split UI and here's a there's a block up here it's got a good description of this actual workflow you basically create a sync directories for each of your environment so you create one for prod and one for Deb when computing and then in the UI you tell it first disable all these okay this is the important step make sure you're in the UI you disable internally split and then you export the full configuration so what you're exporting is no splits okay it's just you've got your student you've still got your config sync directory with you know 90% of your config and then you've got little bits of config and individual split directories but you've disabled those by default so then in your settings dot PHP you enable the split of you want for that environment so typically there's some way to tell which environment you're on like there is an environment variable or some directories you can look at you know aqueous there's an environment variable that says you know prod or dev so you can use that to edit which split to enable so by default they're all disabled now in your saves up PP you're overriding that with here is going to label now when you do the config in court it's going to import your normal consider default directory but that is also going to import with every split environment you've turned on so if you're on des it's going to take some big default with your death if you're on products in cases they result with your products okay if you actually want to update so config export is normally going to only update your main your default if you need to update like the prod or the dev there's this new dress command called config split export that you use to update the actual exploit let's look at how this actually work in process so here's our three environments we're going to talk about dev days and product so we do this initial consider import' on the like we we pull the latest repo we want to get all the latest changes so we do our config import on dev that's going to take the config from the default directory along with our local split our dev split through here I'll call it local it's going to merge those two together and do a config import so now you do some work and you add some heels or whatever your dev tap is and now you do a config export config export will only update the config that's in the default directory it's not going to update any of the local specific stuff if you need to do that use the config split export and we'll update that so now you go to your stage video config import well now this time it's going to take your main default config and it's going to merge it with whatever's in the stage directory and that's going to bring that in your stage now you do a big export from here and all the updates the master default and then on production you do an import and it pulls the default along with the prop okay so this is basically how your config deploy it's from left to right and each individual environment has its own split configuration this is the nice thing about this is you can basically put anything in the splits that you want you can give us individual like hey I just want my site settings to be split or I just want my Google Analytics to be split right this wants the aqueous configuration of xsplit the other max thing it has and it has a list of modules you basically want blocked so this is an important concept with config split by default every module that you're normally enabled is going to be enabled when you tell it what split to you it will then look at the black list for that split and it will turn off any modules in the black list so for example on dev you with black list aqueous nectar Google API or who analytics right anything that's deaf specifically it does is kind of after the fact and this is this is kind of a trick because the list of what modules is enabled on your site is in config there is this cord extension llamo file in your config sink directory that tells you what modules to enable so when you do that config import it imports core dot extensions and it tries to turn on all these modules the config split kind of comes in after the fact before it happens and says oh but wait blacklist beings so those models don't actually get enabled on your system and that's its main trick that it's doing that you can't really do otherwise you can't really do that with directs currently we used to have this thing with dress where you can kind of ignore certain modules you did something export if you're on aqueous or older version wlt tools in your project JSON file you could actually specify like enable and disable these modules on these environments you know if everybody was kind of trying to patch around this now config split is doing that for you and is a cleaner way so in fact the new operator blt tools used to big split and they're deprecating that list of module enable/disable so for example on prod block developed now the veil is not going to turn on get turned on across so it's kind of thing we used to do in d7 a lot even with features right we have all these features and we want to enable some on production but not on dev and vice versa and that card config split helps solve that in d8 so the next thing that you sometimes run into is well what happens if I want to override cupid's on like I have config split which is great measures the environment specific stuff but you know I really want the client to be able to change the site title and in the site title unfortunately is in the same file is the site we UID which is really kind of crazy that they put something that's almost content like you know this the admin email address and the site title are in the same follows the site UID which is this major you can continue but anyways that's the way if you believe but sometimes you need to override you think right so how to over ice work let's see how we do here know that my top hours go away to around all day okay we're going to dress because I want to get to school stuff so two ways of overriding overrides depend upon how different modules are getting too big there's two different ways to load config and d8 you can call config and this is giving you read-only config this is config that can be overwritten so if I override my systems off-site and settings up to HP I'm going to get the overridden value however modules can also call this to get some things you can call the config factory get editable this gives you readwrite config for example using in your edit forms this config over ignored then you override so if you run this on system dot sites that you're saying about these pink changes your site name you don't get up the overridden name that's the name stored in the form so this is why if you override like your site name but you go to the UI and look to see what it says it won't show your overridden site name in that it shows the site name without the override and if you edit it it will take your edits and save it means completely ignore you because it's been overwritten so just be aware that you kind of don't even know if your overwrites going to apply the depends upon how the module is getting the committee so there is a way to do over eyes like this as I said you can go and say inside PHP and overrides big there's also a config override module that supports this uses the same system that the translation system uses to override config for different languages so be aware of those if you want to be override but it only affects the immutable read-only to did and of course that's it us the UX challenges your users might expect to see the overrides in your UI and they don't so they wonder hey my Google API key is not set and that's the Bureau of Iranian PHP so I started talking about features what about features let me use that anymore so features was design and I told you last year its purpose was to package configuration into modules and we used it so we could reuse functionality across pipe we've organized config and of course 97 it was the only way but we all know features has problems if you're like me you kind of bang your head and I I mean I'm the maintainer of features I can go fix this stuff in theory right like why am I been in my head against it well turns out features just uses course CNO core configuration management so features can actually really change how for configuration management works we can work around some things but it makes it really hard so you know it's hard to figure out what to put in what feature and there's these new assignments plugins to try to help but they're really complicated and people don't really understand how they work so you mess with that you have these unmet dependency errors where you try to do the right thing and you've got you know entity reference deal that references a field that's in another content type and you think it's a circular dependency you don't know where to put what and you try to install the site and it says what Mexicans here and so you mention that you know you when you create when you import a feature or revert a feature if that config didn't exist yet you get a new configure UID and so then you try to use everyone says oh use configuration management so you do the config export and now you've exported that UUID your other developers doesn't revert they get a different view ID and now when you go with some big import you get errors so features actually doesn't play very well with the normal configuration workflow and these dreams aren't actually reusable which we'll talk about a minute so stop using features especially for deployment and I said this last year but I guess the message was strong enough because I look at the growth that wrote the features gone to three percent of the eight sites the 7% immediate site so the mirrors not better so you know Drupal 8 configuration timing mostly works if put super hairy Settignano files that version control captures all the config you don't have to worry about what goes where it's all in one the directory has this clean import and export workflow that we talked about showing you some of the ways to get around environment specific config with the big split so that problems basically solve now and you know you really care that it's organized into modules instead of in one giant directory like you know key one of the giant directory the file name directed pretty good you can find your field it's actually kind of nice to know where your config is right in d7 was like okay I gotta go change this config what module did I put that in which feature is that it here is just all in one place but here's the kicker for some of you what about the fusions so first of all what is the distribution in this in this terminology what I consider distribution is kind of a reusable profile so I said you can use profiles and you can install you know 100 different Drupal sites but those are supposed to be kind of identical sites you know within your organization what if you're trying to build a generic profile like say open atrium that's intended to be used by lots of people lots of different sites that cause distribution not just a profile distributions are used on lots of different sites and they have functionality that you're expected to be able to enable and disable you know maybe this site doesn't need the news you know the press release feature that this site does maybe this one needs a blog and this one doesn't like you have these pieces of functionality that you're expecting your site's to be able to turn on and off and we use features for that in the past the other important distinction with the distribution is the distribution tends to not just be a starting point but it's something you expect to update over time that if you improve your blog feature and you've got a thousand types using distribution you release a new version of distribution and you have some update process that allows people to get the new version of that blog and that's again something you don't typically do with just a profile so how do you do that you can't just use what I said before with that core patch and add the config seek directory to your profile because that config sync directory has all your UI needs in it so if I created open atrium and I provided a consistent directory that has the events and tasks and everything else in it when you install that on your site you would get the exact same UI sees as somebody else installing the atrium on their site and you IDs are probably there for a reason and they're called unique for a reason we probably don't want a thousand sites with the same new IDs there's probably security implications all sorts of stuff so what you really want to do is take that functionality and put it in modules and go into the config install directory and remove the EU IDs so that when Drupal initially installs your site you'll get unique how to be because wouldn't that miss what features does and so why not use features so the problem is features were supposed to be reusable and I'm going to have to wrap up so I'm going to go through this stuff pretty best because it's going to be a whole talk on itself this is what I'm working on today features are supposed to be reusable but they're not because if you look at configuration like this is a typical field in your field demo file you'll see a bunch of project specific stuff which is all your machine language so if you've got you know project blog and project image and all of your nightly mainstay stuff it's all kind of hard-coded there in your yellow file so every sites going to have the same content type mission names and feelings and oftentimes you want them to be different like if Berkeley installs opening a tree and they want Berkeley blog and the standard installed what they want Stanford blog and we can't do that right so how do we make this reusable well what if we converted those field name in two variables or those receive names in the variable so here I put at find around variable name and we're calling this a template so this is a sealed template where you can pass this the field name in the bundle name and it will create a field for you so now create a way to use that template so if you're just using SAS or something this will be kind of familiar to you where you can say or Twitter you can say include this to a call with this data here you're singing use this template with this data and store it to this configuration ID so you can also overwrite stuff at the same time you can say take that field store it as projects blog and project image and while you're at it change the label change the help text and make the field required so these are kind of adding overrides and this is what the config actions module does and this is a new module that I'm working on it's starting to get some use in phase 2 I would love people to start reading the tires and playing with this that already has a beta release it basically is a framework for manipulating config so you create an action file that says Croesus config change this add this delete this it's almost like a script for your config imagine using this for update hooks where you say hey go to this config update the title or help text it might feel to this it's only going to make that one change it's not going to import the entire config and overwrite potentially something else it's change imagine have a view and you just need to add one thing to the view so we're done go take a look at config actions into big templates which is one that goes on top of that I know so to summarize really quick so stop using features do config import and config export stop using partial use the core packs for each calling config different profiles you get you can take eclipse yes yes the sides are actually already uploaded ml via video then keep in the back all right thanks very much [Applause] you have questions since we go and we're going to have another speaker here some of the basic and I'll be there by neck

Channel: Drupal 4 Gov

Views: 8,233

Rating: 4.9587631 out of 5

Keywords:

Id: w0bhrmkaEVs

Length: 45min 49sec (2749 seconds)

Published: Tue Aug 01 2017