About this talk
In this talk, Jordan Thompson discusses strategies for managing configuration in Drupal multi-sites, introducing concepts like config splits, templates, and automation to streamline the process. He explains that managing multiple sites can create complexity due to unique configurations and environmental differences, necessitating a structured approach. Thompson outlines three types of splits: feature splits for reusable components, site splits for site-specific configurations, and environment splits for different deployment stages. He emphasizes the importance of using templates to standardize site setups and shows how automation can expedite the process of creating new sites. The talk also includes a demonstration of creating site and feature splits, while highlighting best practices for maintaining configurations.
Full transcript
Okay. Thank you for for coming and I'll be talking about managing configuration for Drupal multi-sites which will include config splits, templates, and some automation. Um yeah. Before I actually get started, how many people here have trouble with multi-sites? Put your hand up. That's why we're here. >> [laughter] >> Yeah, trouble might be might be a a broad term. So, a little bit about me. My name is
Jordan Thompson. I am a Drupal solutions lead at Northern. Used to be Digitally Kidnapped if you know who those guys are. I like to call myself a level nine Drupler. Just means I've been in the game for a little longer. Um almost at 10. Um My my main quest, become the greatest Drupler of our time. Whether that's a a thing that's possible, we'll see. Um I also
like all sorts of other kind of fun stuff when I'm not Drupling. So, today we're going to be covering a few things. So, why multi-site configuration gets messy. Um some three split types that I recommend. Um how um we can build uh the configuration across some layers. How config config split applies these Um creating a structure that will stay maintainable and and make it easy for you.
Um using templates to standardize your site setup, automating new site setup. Uh covering a quick end-to-end example with a demo, and then take aways and questions. So, hopefully everyone can see that. So, why multi-site configuration gets messy, right? We know um once you know, we have a shared code base. We get multiple sites. Um but then those sites start getting specific differences, right? It's like, "Oh, on
on site A, I want to have this very particular configuration. On site B, I don't want that thing. I want something completely different. Or maybe I want unique branding. Maybe I want a very particular feature on, but only on half of my sites." Right? So, it just kind of keeps kind of growing and growing in complexity of of very particular things. But they still share that same
code base, and that code base still needs to exist cuz, you know, you make a new site and oh, now I need feature one through five, but not six, seven, and eight. And you want to be, you know, make sure that you're not it's not too coupled, but also making sure that it's flexible, right? Um and something also to note, too, even to throw another layer to
it, um is environment differences, right? So, you want to have things that are only for your local, only for your dev, but then maybe on stage, on production, you know, you don't want data like, you know, DB logging on your production site. You don't want devel on your production site, for example. There are other things that might need to be configured in such a way based on
your environments. And also, even just manual setup in general can get messy over time. Um so, we want to make sure that that there's something that's automated that, you know, you don't have to worry about, "Did I get all the steps? You know, did I follow my 10-page document to get my site set up properly? Did I miss something? Do I find out a little too late
and I've already deployed it everywhere and now I I got to like redo the whole thing?" Let's do something that'll make it easy, repeatable, and continue on. So, that's where the the three split types kind of come in. So, uh this is uh again, my approach. You might feel differently, um but hopefully this helps you uh as well. So, what I recommend is having the three types
of feature splits. So, that can be a reusable feature, such as say events, like an event content type maybe, maybe some e-commerce, a CRM integration, let's say. Can be anything, right? Anything that you can think of as a feature. Something that's reusable, something that you want on multiple websites. Um and it's a you can compact it. Um then you have site splits. So, per site configuration. So,
you know, for every site maybe, you know, you have you know, this site has this particular piece of content, but then this other site has another piece of a content type. Um but they're not really reusable across sites, so you're not making a feature for that cuz you don't want to make a feature for everything cuz then you're going to have a whole box of features, and
then each website's turning on like 50 features. It's not really the point. Um so, you have one per site, and then you have your environment splits. So, again, your local, uh depending if you have these, your local, your development, your staging, your production. And again, trying to then make sure that you're applying the the right configuration and the right uh way to do these things uh and
and uh make these is important, and that's kind of where the hard part comes in. Um but we're proposing these splits uh again so that you can kind of keep them separate when where it makes sense, but also make sure things are reusable uh across your sites. So, how configuration will build across these four layers? So, this um and I guess I'll sorry, I should note that
this is using config split. Hands up for you those who use config split. Of course. I would hope so. Um so, this is the the way that the configuration will then build on config split. So, starting with our baseline, we have the shared configuration. And then on top of that, we'll then have our feature splits. And then on top of that, we'll have our site splits because,
and again, they're in the order of this way because you could have a feature, but then what if site A uses the feature out of the box? Site B, you're like, "I want to change that feature a little bit, but I still want to have that base feature." So then the site split then builds on top of it, so then it can override. So just to note
that anything kind of above will override the lower or can override the lower. Uh so that's our baseline, and then we have kind of the precedence. And then on top of that is environment because the environment is kind of the king, right? So if you're on production, doesn't matter what those other things are doing, production needs to be clean, needs to be, you know, your production level
ready. So it can maybe override some settings that you have that might be part of your feature, that might be part of your site. Cuz again, at the end of the day, it matters what what environment you're on. And then again, how config split applies these layers. So there's different ways that the config split works. So the different kind of mechanisms, so we have complete split, which
is just a uh take all this configuration and split it out entirely, right? So that's good for say our feature splits and and whatnot. But then there's the partial splits. Um so where partial splits come into play is when in that example, let's say, where I want to override something that's on the baseline or I want to override something that's in the feature. So you're not taking
that feature and complete splitting it for, [snorts] you know, site B, you're going to be partial splitting. And the way that they also like to to word it is like patching, right? So you're saying, "Okay, apply that, but then add my changes on top of that, but just my changes. I don't want to redo everything." that's where you can kind of change that shared configuration. And then
some terms come in of stacking things and and weight. So um it lets you split them into those layers, and then you can stack them the way I showed. Um and then based on the weight determines who uh like the the precedence, so who can override who. Right? So again, if if you were to put, say, your feature to be overriding your site, then your sites can't
override your features, right? Or like your if your environment's first, then that gets applied, but then somehow your site can override the environment, and then this kind of gets messy. So the order really does matter. And you're kind of going from common and then the things that are more specific is really kind of the way to do it. And then again, environments always win at the end.
Um but having them stackable, so that is a feature in in config split to turn them to be stackable. Uh and then maintaining the the proper weight distribution for those layers really is important. So the structure that I propose uh and that I've been using uh kind of breaks down like so. So, we have our config folder, and then we have our features, we have our sites,
and we have our And I also recommend just putting a number prefix on them so that they kind of match the order. Now, you'll notice that they're slightly out of order than the other slide. It's because And this is just like a fun fact. The way that they're ordered in the UI is this way. So the things that override things are at the bottom. So just to
match the UI, it makes it a little easier to kind of visualize. Um So we have our again, our features at the top. So let's say you have an e-commerce feature. And then you have some sites. So let's let's say you have an arts and a business sites. Maybe they're departments uh for, you know, higher ed. And then you have your environments. Uh again, are also ordered.
And then you have your your general sync uh directory. And then you have some templates. And these templates are going to be used when you're generating, say, a new site or a new feature. So that again, those repeatable tasks that you want to make sure you're not messing up, they're just done for you. Right? So then you're saying, "Oh, I want a new site called, you know,
health sciences." Okay, I I'll do that for you. And instead of, you know, a half an hour, an hour clicking, takes like 5 minutes or or less, depending on how much content or configuration you have, rather. Um so, we'll kind of get into that more into the demo. Um but again, we're having that layer order so that it's very obvious how these are are working. and then,
you know, you have your environment order to to be explicit there, and then the templates again follow. So hopefully that that structure makes sense. And then again, why do we use templates? So without templates, you're copying, you know, an existing site split. You're renaming everything in the directory, maybe you forget a name somewhere cuz, you know, you have to rename the file sometimes, you have to rename
everything inside. Um you have to update any kind of references. Uh maybe, you know, you forget to uninclude something or forget to include something, and now it's all messy. And then you try to import and it's like, "Oh, can't import that thing. I don't know what that is. You named it weird." And we're having a bad time. But with templates, we're starting from that reusable template. We're
filling in the site-specific values, and we keep the naming and structure structure consistent. Um and then we can validate to make sure it actually works, which is pretty nice. So, they turn that that one step uh setup into a repeatable process, which is really nice. So, if someone asks you for a new site, instead of you like, "Oh, hold on. Let me make sure I cover everything."
You're like, "Yep, I got you. New site done." Um so, automating that that new site. Um so again, I've I've kind of come up with an automation. Uh again, I'll walk through it in the at demo. I've had a I command called site setup. So, you specify your site name, so it's in the um variable there, and then the path. So, the because the the path or
like uh that could be, you know, maybe it has a dash in it, maybe you know, you don't have a dash between the words. So, sometimes, you know, you might have something specific. Uh so, you know, maybe if the site is health and sciences, you want to make sure it's like health sciences. There's maybe no and or something like that. You want to be specific, right? So,
it's passing in two things, and it only needs those two things. And then the rest, it can go off and and do by itself. So, really, it's going to create some site resources for you. So, what it does is creates a a local database for you, creates some drush aliases, add some settings, some routing, and installs Drupal using the bootstrap or the shared baseline. Uh it generates
the split file. So, from the templates, um it makes the splits, and I and it replaces any placeholders that it can find. Um and then it validates the setup by either importing or exporting all the configuration for you. So, again, the automation's then turning those templates into a repeatable workflow. Uh which is really nice as well. And the end-end example that we're going to do as we're
going to scaffold a feature split. Um so, again, we're adding reusable functionality. We're going to generate a site split from our site template. We're going to enable the feature uh on the new site. And then we're going to import configuration to make sure everything Um so, again, the goal is not just create a site, but it's to create one predictably, right? So, you you want to make
sure all your processes work. Now, pray to the demo gods that nothing goes wrong. Everyone cross their fingers. Okay. So, I just need to switch some things, and then we should be okay. Okay, hopefully it's not too small for everybody. Okay, so just a walk through my my uh layer model here. So, we have our sync directory, so that'll again include everything that's general We have our
feature. So, right now I just have an empty e-commerce feature just for the sake of the example. Um I have some sites pre-done, so I have an art site and a business site. And again, these are pretty basic, but you could obviously have them more complicated. And then we have our environments. We have our local, our dev, our staging, and our production. And then there's our templates.
which we'll go through as well. Okay. So, what we're going to do is also show you my sites that I have set up. So, currently we have an arts site And again, they're pretty basic. It's just kind of to show you the idea. These were both generated uh with the command as a starting point. So, you can see, you know, they have a brand color. Um they
have some words, they have some content, and whatnot. And then we can kind of see as well um that they're both uh again using some shared content. So, if we go to um our templates, I'm just going to see over here. Actually, sorry. We're going to go to our shared content first, our shared sync. So, if we were to go to say um our site settings, if
I can find them. System site. So, you know, we have, you know, what the name of the site is. So, the shared configuration's called shared baseline. Maybe it has a mailto, no slogan, and specify say the front page. Now, if we go into our splits, we have these patch files that I was mentioning. So, these patch files will then remove that that shared configuration and add in
their own custom configuration, like so. So, you're just saying, "Oh, I just need to change, you know, the title. Maybe I'm adding a slogan, changing the the the front page." And that'll do that. So, when this go gets imported, it'll import the shared configuration first, and then it does the patch on top, and that's how it works. So, this will always get applied after. Again, assuming that
our weights are are in proper order. So, to show as well on the website, if we go to configuration, oops. If we go to our configuration page and we go to config split settings here, we'll see that they're in our order that have in our sidebar. So, we have our feature at the top, our faculty sites, so our sites there, and then we have our environments. So,
again, it'll do the the basic um shared baseline, then apply the feature, then apply the sites, then apply the environment, which is why this is then patching our baseline. And again, it can do other things as well. So, for example, it's changing our uh all of our settings, so it's changing our primary color. So, that's why we have the orange on the one and the purple on
the other. And then it can also change our gin settings as well. Any kind of thing you want to change from the baseline, you can, and then those are the partial splits um that we're using, which is why the files you'll see here say config split patch. Um and they're not including everything. So, we're not copying the whole file. If the whole file was there, that would
be a complete split, but we don't need to change everything in the whole file. We're only changing a couple things, right? So, we're only overriding the things that make sense. And as you see, it's kind of nice because these files are actually very readable. It's These are the things I'm adding, these are the things I'm removing. And you can even make these by hand if you want
to, assuming that you're comfortable writing YAML um as well. Um and then we can we can see on, for um our business site has our config split um config split patch for a config split. I know it's a little meta, but what it does, it turns on the feature e-commerce. So, if we had these side by side, so this is the art one. If I go to
the business one, we'll see that the feature is in fact enabled on this side. And all that's doing is it's just changing the status from false to true, which is pretty easy. So, I know sometimes you'd be like, "Oh, well, I have to turn all my feature splits on manually in some kind of file somewhere." This the the site splits are determining what features are on, and
you can just do that in the UI if you want to. You don't have to manage that any kind of anywhere else. And then something I'll show as well, we do have a settings file for these. And you can see that we're turning these on, so we'll say this is the, you know, we want the business um specific split turned on, but as opposed to you having
to go in and say, "Okay, I want feature one, I want feature two, I want feature three." Again, we're just managing that on the split level, and then this settings file is just turning on the site split for you. So, it knows which site you're in. It's the setting file for that site, and knows which one to turn on. It also just turns on the local um
by default. Normally, we would have also some um some settings here to to figure out which environment you're on. This one's just more of a thing for uh turning on these splits, and then this environment indicator just so you know which one's on. So, we know we're on the local one right now. And then, we can kind of show the templates. And while that's running, or while
that's while we're just going to show that. I'm actually going to run the the code uh cuz it does take a a moment. Um so we're going to make a new website. A new uh multi-site rather. So we do Lando. So I'm on Lando right now, but um you don't have to have to use Lando. I just have it wrapped in Lando. It's a script. Um so
we have our Lando site set up. We site equals say school of health And then our path is going to be say health. We're going to let that run. It might be very quick. So I might have I might have made it too quick. Um but we're going to look at the templates. So right now we're making a site. Currently in the site um template here we're
we're using the name that we're going to pass it um to to replace that. Similarly in our sync folder we're making a split with some placeholders as well. So if we go to our and it's already done. So I was I was much slower than the script was. It does take longer if you have a real site when you have real content. It takes a little bit
longer to to do everything. Um so what I'll kind of walk through here um I just have some helpers as well. But what is this doing? It's getting in the site name and the path um generating an alias for you. it's making sure um that you know, it's making in the right spot. And let me go down to the bottom cuz these are all our functions. And
actually what I'm going is maybe what I'll do is I'll split this to the right. It's very awkward doing it on two screens, but that's okay. Um I'll put our functions on the left on the right and then I'll have our steps on the left. So, what this is is it's going to make a new database. So, it calls this create database, creates our database for us
on our local. Done. Easy peasy. Next, it's going to create a drush alias for us. So, what that's doing is it has we have a a template for that as well. So, I will show that So, under drush here, we have our templates. And then this is how we have our template. So, we have, you know, it'll put our site in, it'll kind of keep a consistent
URL. um it'll have our site there as well. Um this is just kind of a local setup, but this could also then make an alias for your dev, your stage, and your production again using the same thing. Um so, just kind of using the the find and replace there. So, you can see even right now if I looked at our sites, this is our arts one, this
is our business one, and this is our health sciences one. And then after our alias it's going to get the site settings set up. So, again, that one also has a Um which I just need to figure out where on this screen. I think it's in here. So, yeah, in our templates again really just again, finding things and setting them up. So, this could be more complex
if you needed to do to be, but again, very consistent, it's always going to be the same. So, it makes our site settings for us. Generates some things that it needs to, puts it in the right spot, makes a folder for it as well. and then we're going to create a sim link for it. we're going to actually install the So, it'll take uh our existing configuration
if it exists, and if not, it'll just install uh the standard. and then it's going to create the config split. So, using those folders, it makes the the the split for us based on those templates, fills everything in that it um and puts them where they they need to be. And then it prints out if your site's ready or not. So, I I like the to say
it's like an easy bake oven. You ask for a site and it'll do it for you. Um so, let's try that, shall we? So, if we were to just copy this URL, actually, I actually have it here. So, something I added is that prints out your URL, but it also gives you a ULI link, which is kind of handy. And once that loads, we'll see our new
health site. Oh. I got to click that. There you go. So, we have our School of Health Sciences. So, that didn't take very long, right? Again, it'll take much longer if you have a little bit more configuration, but it was pretty quick. Um and then if I wanted to, I you know, I could change around some of the the and and change the colors. So, like let's
just do that for fun. So, let's go into the appearance for Olivero. And let's change sure, firehouse. Once we save that, I can go back over and I can run config export. So, then I have my health at or health.local, which is my alias that it made for me, and I can run an And you'll see that it grabs some configuration for me. If I go back
to my code here and go to my health split. just might need to refresh this. I thought it was going to be a split. Oh, this is what happens on a demo. Um it should have been splitting the color, but um it's possible that it didn't know to do that properly. Let me just uh That's okay. We'll keep moving on. But, it should have made a split
file for it, so it's all good. Um and then something else that we have, so very similarly to the site split, we also have a feature split template. Now, uh um this one is a bit bland because it it really depends on your feature. But, if we wanted to say add a new feature, so we do Lando say feature and we'll call it say feature equals student
portal. And give it an ID of student portal. Oops. >> Like so. It'll do It'll make our split for us. And it's again pretty small because it really depends on what your split is, but it will make the folder and we will need to add some configuration for it, but it'll still make it so that we can we can start it. So, the the feature one is
a little lighter, um but if you say had more things that you wanted all your features to do, you again could could uh template Um and then uh something to show that's kind of important uh is just those weights. if I were to go and find the sync folder sorry, the actual sync folder and I were to go to my config splits, you'll see that my sites
have a a weight of 20. So, those keep them grouped and that's again specified in our our um Our uh features have weights of 10. Again, those keep those separate and then our um has a 31 so that our dev if I can find the dev one here has 32 so keeps those in order as well. So, it just kind of keeps them in order visually in
the UI, but also to kind of match our our folder structure. I just find it's very helpful to know how these stack visually. Like, I don't have to go into the UI and remember how they stack. I can see it in the the structure as well. yeah, so we we can actually take this feature split and let's actually enable it on our new site. It should already
be there once I find >> Uh I might need to import first. So, just give me 1 second. So, that it picks it up. And then I can go in here and then I could activate it. And then I would go into my health I would partial split, so not the the complete split here, but I would partial my student portal. So, if I find that, I
would hit partial. I think this is also maybe why my my olive area didn't stick. but that's okay. We'll just change this. Save it. Export it. And if everything works the way I want it to, our health sciences should now Oh, so it's fully splitting this right now. Um but in theory it should just have the turn on, but I probably didn't I missed a step there.
As it happens in the demo. Am I right? Um so, yeah. So, again, just kind of reiterating, let's go back to the slides. So, our main takeaways, again, we have separate configuration by reason for change. We use our templates to make our site set up more consistent. Um that way again, we can just press a button, spits out a site for me. Um we can automate that
set up and validate uh anything to reduce drift. So we we already have a way to to confirm. So when I was building the demo, there was lots of things that didn't import properly and I was like, oh, we got to fix it. Make sure it runs all nice. Cuz you can just blow it all away cuz you're just setting it up for the first time and
then make sure that it works. And then, you know, building conventions that work both for people and for the goal is not more splits, but less ambiguity and making sure that our splits make sense. Um and that we understand them is kind of is kind of the key. So. And that is all I have. >> [applause] >> And I think Oh, yes, we have lots of time
for questions. Where does site-setup that SSH come from? Oh, good question. So the question was, where does site-setup come from? Uh so I will show. Will let me find my code again. There we So that is just a wrapper that I have in currently, but it doesn't have to live I just use Lando and it works for me. If I find my Lando, um all that's doing
is it's calling my Lando command, which then just calls my uh bash script. And then it prompts you for for some things. So if I call just site setup, it's nice the Lando command will prompt you for these things, so it makes sure that you put things in. It also kind of gives you some examples here, but um yeah. So you could have a wrapper, you could
just call the script directly if you want to. Um I just >> your own. Pardon? Each person would have to write their own. >> For the site setup? >> Yes. Um yeah, in theory. Um it really kind of depends on what you need to do. But, in also theory, I could make this available and then people could steal it also. It's not necessarily proprietary. Okay. [laughter] That's
what That's what I Yes. Yes. In theory, yes, you could steal it. Um, it'll just cost you uh $10. Just kidding. yeah, I'm selling scripts uh in the back of my van tomorrow. Uh, no. Um, yeah, you could totally steal it. Um, and like, yeah, it's all in bash. It doesn't have to be in bash either. I just I like bash, so I pick bash. But, it's
really the concept, right? It's the making that reusable and then I figured, okay, how do I do that? Okay, let's make some template files. What's the best way for me to to figure this out? Well, I usually make bash scripts and then kind of went from there. And I was like, oh, I'll make a Lando command cuz then I can I can make it just a little
nicer of an interface cuz some of the Lando commands are a little nicer to look. Um, so, that's how it kind of evolved from there. But, good Yes. Um, is the directory order controlling how the how the precedence No. The directory order is Oh, so, sorry. Question is does the directory order really matter for precedence? It does not. How are you How are That's the weight. Okay.
So, when the splits um, so, if I show back to the split weights, which you can specify in the UI, but I just It's easier to show quicker here. So, for example, um, so, like we have arts, which has a weight of 20. and then we have say development, which has a weight of 32. So, the way to think about it, it's the the concept is kind
of hard cuz it it doesn't really fit visually, but the heavier the weight, the bigger the weight, the more override power it has. So, feature splits have a 10, for example, so, sites have a 20, and then the environments have anything higher than And then that's that's what sets the but I also make the folder structure the same just so it's easy for me to understand what's
doing what. Because if you had them all in random order by like alphabetical, it might not necessarily mean that that's the order it respects. So I I find visually I'm a very visual person. I need it to match the the UI or and then I'll be oh okay that makes sense. I understand that this is overriding this cuz it's heavier. Um so. Um how are you managing
like sensitive uh data within uh config files like API keys and all that? Like are you just keeping it up Um if you were doing like oh sorry, the question is how do you manage sensitive data like API keys? I would recommend you using the key module. Um so what that does it lets you add well so essentially it's configuration that then is tied to a key
but that key would then live in like the private directory or somewhere that's inaccessible and then it has a path to it. So then really your configuration doesn't know what that key is. It just knows where it's supposed to live and where it's supposed to find it. And then your key could be on an island somewhere and it's like I know where that lives. So I go
grab it. Does that make sense? And that lives in the like those key definitions live in the YAML as well or Well so the key yeah so like where to find it would be in the the the key YAML. Uh but then someone would still have to have like access to your server and then know where that like find it and and stuff like that. But yeah
so it's it's kind of a way to abstract any kind of like keys like that. Cuz you can save them in configuration but then it's like oh it's just there and now it's in your repo. Uh so yeah. My guy way at the back and then I'll get I'll get to you in the middle. How do you handle uh module updates that you update the Okay so
the question is how do we manage module updates that might affect multiple splits essentially? Uh, that's a good question. I guess it really depends on how we're splitting those things cuz if they're in the shared baseline, easy peasy. We do it like normal. Typically again, I try to not have >> [snorts] >> things that are in too many splits. So, for example, if I had Uh, it's
it's a very situational Um, but it's a good question. I I I respect it. Um, but if I had let's say I had like features in in two sites for example that are then using the same module, maybe I should try to make that a feature split and then override. It really kind of depends on what it is. Um, but I would say try to feature as
much as you can so that you're not like complete splitting all of these things that are kind of the same thing and you could make like change them. But if if there's situations where it's like this could only be this thing and this could only be this thing, then for sure just keep it on like the site level. Uh, I think it depends as as the answer
to my your question. But it's a good Um, did you ever experience any like just conflict management management or conflict split? Like um, impose the conflicts, but it's they're not imposed. You have to export it first and then import it. Like the format Okay, so the question is do I find any issues when I have to like export it or import it first and then export it?
Is that what you're saying? Yeah, so it's like even that's in chance, but you feel one like in the Drupal security updates or any module updates. There's some like format changes. Like this line goes down and this line goes Right. Um, I mean that does happen sometimes and then general in config, so I don't really know. I I I don't really think it's it's necessarily specific or
not specific to this setup, but that does happen a lot of times. I will say something that's key, which is maybe kind of your question, in order for um your site to override, so those those patch files, they need to exist in the baseline. They can't patch nothing. Right? Which is why when I was exporting these, it probably grabbed the whole thing, cuz it doesn't have something
to compare it against to see what the difference was. So, it needs to know, for example, that my feature is off by default. And when I go into the site, I turn it on, that's the difference. So, then really the patch file is like the diff. And it's saying, "Oh, you turned it on and you export it. So, you need you care about the on." Or whatever
you've changed, you care about that. So, there are some times where it gets a little tricky, cuz like if you don't do that, it'll export the whole thing, and then you're have to like, "Oh, well, I didn't want the whole thing. I just wanted part of the thing, and now I need to override it." So, it can get a little messy in that way, if that makes
sense, of like trying to make sure that you split things properly. Um this in general took a lot of trial and error to try to figure out the splits. Um but you kind of get the hang of it at some point, but it is sometimes you can kind of mess up the order. Um so, it just kind of takes make sure that you're following the same steps
every time. But, good question. Any other questions? Yes. Can you tie recipes into this at all? Um so, the question is, could you tie recipes into this all? Um Like recipes for what? Like features? Yeah, I was just kind of thinking because it seemed like the way you did enabling modules and stuff, but what add modules to it? they are on the site when you build. Um
so, you could you could you could combine this with recipes, cuz really you're exporting and you're splitting whatever you want on that site. So, in theory, yeah, you could have a split that turns on a certain thing, but I guess it kind of depends cuz for example, if you had say an event recipe, you could So, let's say you could apply that event recipe. Maybe it's like
super generic, but maybe then that turns into And then maybe then a site um takes that feature split. Um so, maybe the recipe is really like the starter, but then you're making a split after cuz you want to maintain it as opposed to just having it, but you could use that that recipe as the starter cuz your your um feature isn't just like empty by default. You
could say, "Oh, I want events and this is like how I like to do events. Make my feature." And then that's your starter feature. And then if you want to override it, you do that on Cool. So, in that a multi-site, the three standalone sites that are sharing the same repository, how do you handle UUIDs when they're different across each of That's a good question. Uh so,
the question is Is that better than the other one? >> All questions are made equal. Um the question is how do you maintain UUIDs if you have three separate sites, but they're sharing the same code base? That is a good question. I will have to think about that question a little bit. Probably very carefully. Um I don't think cuz you can't I don't think you can technically
Well, technically anything in the YAML is splittable. So, like in theory, maybe you could split the UUIDs. Sounds kind of messy, though. I don't think there's like a good way to do it. Yeah, I feel like that would be kind of difficult. They'd probably have to be some trial and error. I'm sure you could figure it out. But, that is a that's a a very particular good
use case, though, I would say. Um cuz yeah, these will share the UIDs uh for the most part. Um so, that does it kind of does the defeats that. So, I I don't know. In theory, you could have them all share the same one anyways. Only if you built them all from the start. Correct. Yes. Yeah, so it would be hard to like implement like a structure
after the fact cuz everything's going to be on its own jam. Yes. Um yes. Good question. Oh, sorry. Uh that's a good question. Um I I I don't even know if there's like a Slack for like multi-sites in the Drupal Slack. Maybe there should be one. If there isn't, maybe I'll make one and then I'll put it in there. Um so, yeah. Why cuz why not, right?
Oh, uh are you saying like a Well, well, how would I deal with single sign-on? All right, right. Yeah, I the I've done So, sorry. The question the question's kind of going around like like single sign-on in general, but uh I have done things where like the single sign-ons are there, but usually do that by like environment. So, you can do it by environment? Yeah, so like
for example, all the dev sites you log in the same way, all the stage sites you have the same thing. And that's kind of where those environment splits are nice cuz then it's like all of the stage sites share the same kind of thing. And now again, you still have to deal with like metadata per se, and and that kind of stuff. Sure, you got to set
all that up, but like the base is like kind of set up for your stage or for your prod and that kind of stuff. So, the things like that are more of environment specific, that's where the environment splits are good. Right now, I think in my example, I just like logging and performance, which is like the usual like don't have logging turned on and make sure you're
caching on prod, for example. But, there's so many more things you can have. so, any other questions? I think there Yeah. Yeah, so what is your recommendation to maintain those templates? So, you for example, usually create them, then you create some new content types and everything. How do you maintain those templates like something like that? So, the question is how would I maintain those templates after? Um
so, if for example, I really wanted um I'll see if I can find a template So, if I really wanted to change Yeah, maybe I wanted to change like how this one was working, let's say. Um well, this one's just a patch, so that's a little different. maybe this the other Good question. So, I would say how I would do it if I wanted to change it,
I could So, if I was making something like not patching, most of these are patching so, it It make it a little easier, but if let's say I was like full completing complete split something, um I could then take it from my shared baseline, copy it Yeah, there's not like a way to like convert it back to a template. Um if that yeah. But um it also
it kind of depends on how much stuff you're doing as kind of a site template in general, right? So, you're not like you could have really complicated like beginner setup, too. But yeah, it'll it would take time to to to have curate that and maybe update it if it was complicated. Yeah, there's not necessarily like a strategy to keep those templates up to date per se. It's
really like my approach um that I've been taking is like we kind of figured out how our sites we want them to start. And like that's how I've set it up and that's hasn't really been changing. But it's a good question of like what what happens when I want to add something new to my my stuff. It is a a bit of a manual process and you
have to kind of figure out where the bits fit in. Um especially if you're doing stuff where like you're using things from the prompt. Like I have to put in placeholders instead. Um but in theory it would be not too bad, but it I guess it kind of depends on the configuration I suppose, too. Um but I know I keep saying that, but like they're good questions.
So, be proud of that you asked a good question. Yes. What tips would you give to someone starting out with config split on their multi-site? Um I would say experiment. Make sure you read all of page on the config split um because I feel like it take it take some time to fully understand like how like what the ramifications are of like putting say like something incomplete
um but then if you put it complete on one site and on another site, are they now competing for the like the complete split? And if you export it on one, you forget to export on the other, then like they're weirdly out of sync. and even like the partials, too. Um it's just like knowing how to balance it. Um the other thing is this advanced area. So
this is where that stackable I also find um this is not a a bash of anything. The wording on this it does it does also take like is a little confusing cuz the the that in my slide I had it like bottom baseline up, but it's really top down. And that's how it describes it. It's like the heavier the thing, the the more power it has. So
even understanding how those stack to each other it it takes some time to kind of get hang of, but I would even just try making a couple and then having some like override certain things and just exporting and see how it exports it just to kind of understand like oh this is patching cuz it's a it's a it's a partial split. And this is complete the whole
thing because it's a full split, for example. Um and then even yeah even just playing around with some of the settings as well. So and just yeah trying different things, maybe changing the weights around, seeing what happens. Um and whatnot. So yeah, just experimenting. I don't really know if there's like pure tips other than I've learned a lot of this just by messing up a lot and
then figuring out how to how to make it better cuz That's That's usually how I learn things. Yeah, cuz like for example, I had the features below the sites at one point. And then I was like wait, sites should be able to override the features. So my features are in the wrong spot. But I didn't know that cuz I didn't have any features yet. And then I
went to go make my first feature and I was like oh, it's in the wrong area and I need to move it to the to above. Cuz I always kind of think more generic to less to more specific is kind of the way you want to stack it. I think your environment is probably the best place to start. Work my way up. Yes, yes, for sure. Yes.
I just wanted to add on to that. One thing that we did which we are recently working on splitting our configuration the multi-site is we wrote ourselves a script to do what Drush used to have like a multi-site Drush to import so that when we do the config import we always run it on every single site. Um because you don't necessarily need it on every site, but
sometimes unexpected configuration changes show up. So that we're always watching for that on every site because we've got like that are you know running on different schools. So if they get out of sync it's better to catch it sooner rather than later. Yeah, that's a good point. So just to repeat what you said on here is making sure that when you're changing config when you have them
split like this, making sure to constantly be importing on your sites because like you said you could be working on site A a bunch changing like some of the baseline and and all the stuff and then site B is like super out of date and then that somehow changes something and now it's changing the baseline for site A, but really they should be on the same baseline
and now everything gets out of sync. So that is a good point of trying to make sure that those uh which does happen a lot cuz you make a site and then you could like ignore it cuz it's like it's fine forever. So just making sure that you're always making sure everything's synced which is kind of a general best practice for configuration management in general, but much
more important when >> you know, new site could easily mess up 10 old sites just by accidentally exporting something that it that shouldn't have. So good point. Cool. Well, thank you very much. >> yeah, maybe I will make a Slack channel for multisites and then we can
