Recipe Unpack: Leaving Drupal CMS Is What You're Supposed to Do

All right. Well, welcome everybody. If uh you're here for Recipe Unpack, uh you're in the right place. Um the whole purpose of this presentation is just to talk a little bit about recipes and the newly introduced composer plugin for Drupal 11.2 called Recipe Unpack. Um it lets you leave Drupal CMS and really it lets you leave any recipe behind because that's what's supposed to happen with recipes. So, let's uh let's talk about this. Let's get into it. First of all, my name is Josh Mitchell. Um, I'm the founder of M6L, uh, independent consultant. I do something kind of unique. I work with teams that have or organizations that have internal teams of developers and I help level up those developers. So, I come in and I teach those developers how to do Git, how to do CI/CD, how to build Drupal stuff the right way instead of hacking core and writing lots of custom code. Like, the goal is to leave them better than I arrived. Um, and also to work myself out of a job. So, if you ever find yourself in need of somebody to come in and teach your developers how not to screw up, that's my job. Uh, I call it a full stack consultancy because I'm also really comfortable presenting. Uh, I've presented to city councils and leadership teams in all sorts of situations. Uh, I've got like 20 years of Drupal experience, including u two and a half years as the CTO of the Drupal Association. I hired Tim Lenn, one of my proudest things ever. Um, I'm a musician, outdoor enthusiast, and uh, you can connect with me on either LinkedIn or Drupal Slack. And I'm pretty active in Drupal Slack. So, if you have questions, ping me in there. I'm happy to have an answer. Oh, uh, fun story about the photo, the little GIF there. That's like a 9-year-old GIF that I created as I was leaving the Drupal Association for their Slack channel. So if they ever mention my name, they got to see my kitchen and me making a sandwich because whenever I worked from home at that time, my computer was facing into my kitchen. They always joked it looked like a cooking show. I thought it was appropriate for recipe unpack, right? Okay. So what are Drupal recipes? They were introduced in Drupal 10.3. Um they've been around since that time. Um, and they provide a standardized way for you to include configuration and installation into any Drupal site that's older than 10.3. Um, it can include uh dependencies to modules and themes. Um, a big part of it is doing uh the configuration. So whenever you do a config export, you're able to actually add that to a recipe and then it can apply it to a new site as a config import as a part of the recipe command. Uh, and you can also do content and the way that you can do that right now is with a default content module which lets you basically export a whole bunch of default content into a place that you import in with a recipe. And what this means is you can create really unique combinations of things uh by combining a couple recipes and maybe saying, "Oh, hey, I want a recipe for creating an event content type and I want event content types in a separate recipe to be able to show up in a full calendar view." Something like that. And those could be two separate recipes that are heavily linked to each other and maybe there's even a dependency between the two of them. Um there's some example recipes built into Drupal core. Uh if you do a standard site install right now, so if you do Drush site install, yes, it's going to do your standard site install. And when you do a standard site install, it's actually using recipes to create all the standard content types. Now that's happened over the the last couple releases of Drupal. Um another example is the mommy demo. Most of the content and configuration that's in the Umami demo is all built with recipes right now. So when you're doing that site install profile Umami, that's using recipes to build that all out. So it's a really powerful tool cuz it lets us extract code and stuff and put it into a place where we're able to reuse it over and over again. The trick is when you reuse it, you want to throw it away. you don't want to use that recipe anymore after creating all that configuration because that's dependencies you don't want to have to live with in the long term. So in Drupal 11.2 there was a important new addition to recipes. At this point we're able to unpack a recipe. So instead of just requiring it we can say okay after I've required it unpack it into my site so that I don't need to use that recipe ever again. So this is kind of the step by step. If you're not on Drupal 11.2, then you would need to do composer update Drupal core with all dependencies to get on 11.2. Uh you're going to need to make sure your composer file is set up to, you know, actually get you to 11.2. But the idea is to get as much updated as you can so that you make sure you got the right stuff. Um if you're not on Drupal 11.2, to you can do a composer require Drupal core recipe unpack. So any previous version of Drupal all the way back to Drupal 10.3 can use this composer plugin. So you can run this composer command if you require it. When you do that I've got a step in here step four. When you do that composer require it's actually going to pop up with do you want to allow this plugin to change your code? And you can just click yes. If for some reason you don't, you can also run that command config allow plugins Drupal core recipe unpack true and it will do the same thing as clicking yes. It's going to add it to your composer.json in a way that you can basically run this command from there on out. Once you've done that, you've got a new composer command at your disposal. And by the way, you can write custom composer composer commands. A lot of people don't realize this. Um they're called composer scripts. uh the recipe on map pack module has it kind of hidden in its um you know plugin that it's creating in your codebase. Uh but you can actually expose them in your composer JSON. You can do all kinds of cool things like you can say um I've got one that's composer uli that I use for a lot of projects and it actually runs a series of Drush Uly commands or like if I'm on aqua instead of running Drush Uli maybe I want to run ACLI remote Drush Uli with a couple of um variables appended to it like maybe the name of the environment and the user I want to log in with and you can all run that through a composer command. So I can run it through like say composer uli dev josh and it will log me into dev as Josh and it's really cool kind of feature that you can do but that's essentially the underpinning idea behind this unpack command that you're able to do. So once you've done that um you can you can do one more thing if you'd like to u optionally disable this from happening automatically on all future requirements. Uh, you can add this little little bit in here. I actually don't necessarily recommend this because again, I feel like when you use a recipe, your goal should be that you are able to throw it away when you're done applying. So, caveats and considerations. If you are using this concept of recipe unpack, it works against your main project dependencies, but not your dev dependencies. So, if you have anything in the required dev section of your composer.json, JSON, it's not going to do anything with that. You're going to have to manually unpack those dependencies. And there's a command you can run against specific recipe in that dev dependency to get it to unpack, but you would have to do it manually at the end. And if you have a really complex setup where you're trying to do lots of things with recipes, there may be some additional dependency stuff that you have to work out. So if you have a recipe written by one developer and a recipe written by another developer and maybe one developer is requiring version seven of a package and another developer is requiring version 8, what you're going to have to do is actually kind of figure out how to blend those two things together and probably get yourself up to something that works with version 8. Um, so there there are times where you may not be able to use two recipes together using this composer unpack technique. But if you know you're using recently updated recipes, they should mostly work. Now, this is really why you're all here, right? You want to see the live demo, actually see how it works. And this is the stuff I love doing cuz it's kind of fun. So on my screen here, uh, you can see I've got up. It's really small. I apologize for that. Um, and you know what I totally forgot to do? And Bob, you didn't yell out Josh, you forgot to put the captions on. >> Command Alt F5. >> Yeah, that's right. Here I I can totally do the command and put them up there. Live captions. Done. And I hit there. Okay. So now for the rest of my presentation, it's going to have accessible commands or um accessible captions down below. Totally forgot that. Shoot. Oh well. Um, so here I am in Drupal CMS. I'm going to show you how to run uh the recipe on pack. Um but first I'm going to show you kind of some what the dependencies are in Drupal CMS. So let me just So what you can see here is a set of dependencies. And all of these dependencies that you see when you install Drupal CMS from scratch are recipes, right? You can see Drupal CMS accessibility tools, Drupal CMS AI. every single one of those is a recipe. Now, that means that those underlying recipes have a whole bunch of dependencies that are defined in the recipes up in the recipe folder. So, core recipes are going to um be within the core folder wherever you've installed core, but any other recipe dependencies, including the way Drupal CMS is built, are going to get end up getting installed into the recipes folder of the root of your project. Right? So you can see all these recipes up there. Now I'm at the point where I'm like, you know what? I am ready to run my composer recipe unpack. I'm even live typing. Okay, I just did it. Oh, wait. Did everybody see what happened there? >> Deleted all the dependencies. >> Yeah. So now if I look at my dependency folder in my composer.json, JSON. What do I have? I have every single module in every single recipe that's a part of Drupal CMS now in my root composer.json. And if you want to kind of see what that looks like from a diff standpoint, we can just kind of pull up uh the viewer here. And you can see here like Drupal core got turned into all of those. And by the way, this is not a one for one like this one equals this one. It's actually an alphabetical list on your right and alphabetical list on your left. But basically, it's unpacked everything so that it is now all in my composer.json, which means that after I've run my recipes, which in this case, they're uh many of them are actually run as a part of installing Drupal CMS. Some of them aren't like uh Drupal CMS AI. That's something that you would have to install after the fact. I can still do that in my, you know, actual site that I've built out with Drupal CMS. Um, but now I no longer have to worry about maintaining my dependencies via those recipes. I've just unpacked them all into the site, which now means from now on I'm actually maintaining as the actual modules. The other thing this does from a development perspective is it gives you a really good sense as a as a developer of what am I getting into? Um, Drupal CMS is extremely opinionated. I love some aspects of Drupal CMS. I do not think you are going to apply all of Drupal CMS to an existing Drupal set. It just doesn't make sense. You know, you you you want to pick and choose a few recipes to apply to it. But out of the box, Drupal CMS installs a lot of stuff. And this is a really good job of just showing you how many things are tied to that. By the way, I also think this is a really good litmus test for having your developers look at when they're thinking about modules to take on for a project. if it's included in Drupal CMS, there are so many more maintainer eyes on it than if it's not included in Drupal CMS. And we're at the point now, too, where I truly believe like 90% of what you can need to do on any Drupal site. 10% is a lot, right? But 90% of it can be done with the modules that are included in Drupal CMS. If you haven't used event condition action the ECA module like most of your custom code you can get rid of and do with models of ECA right it's it's a really really powerful tool like I had some custom code that did a uh content uh reviewer required sort of feature right like you have a node maybe you post a news item and your editors are able to create it but only your publishers can publish it and they put it into a needs review state and you have a little entity reference field that says here's a list of reviewers that can review it and they select from that and then when they hit save the ECA module actually can send the email for you right maybe you combine a couple other modules in there like easy email or something else to actually send the email but the fact is you can write an ECA and use a couple of contrib modules and achieve everything that was done with the custom code so something to consider this is not my only demo for you today because that was Drupal CMS. What if I want to do Go ahead, Chris. >> Can you unpack? Can you pass a Can you pass parameters to the unpack? Can you only unpack specific uh like choose to unpack just like the SEO recipe or something? >> Yes, I'm actually going to demonstrate that right now. That's part of it. So, this is a Drupal 11 implementation. And if I look at my composer.json here, it is much less complex. There we go. Composer require. This is literally if you went to DD's site and said, "Let me spin up a Drupal 11 installation." This is all you get, right? But you'll notice because I'm on 11.2, it does have composer recipe unpack included. Literally, this is what the change in 11.2 was is that the composer core recommended now has Drupal core recipe unpack included in what it does. Right? That's the only change. This is why you can apply it to a Drupal 10.3 site because recipes work the same way in both those. Now, one of my favorite things to do uh whenever I'm looking at composer unpack. So, let me let me do a ddev actually. Um this is totally an aside, but you'll notice here I'm just writing Drush. If you were writing this in your own DD container, you would probably do DD Drush because you're passing it through DDEV. I have all that aliased in a in a um bash rc file, right? Like I I don't want to have to type that much. I hate typing. So, anything I can alias and always run in ddev containers, I do. Uh this is why you'll see me run just Drush and just composer. I am technically running it inside the DDEV containers. So, here I'm going to do uh Drush Uli and get myself a one-time login link. Let's click on that. I'm going to go ahead and open it. Okay, so here I am on my Drush site and you can see across the top I've got my admin toolbar. It all looks pretty standard. If I go to content, it looks like CLO, right? That's pretty straightforward. So let's bounce back over to my D11 site and I'm going to do composer require Drupal Frupal CMS admin UI. This is, by the way, one of my favorite things to do to any Drupal site right now because this applies the Gen theme and the admin toolbar or it gets rid of the admin toolbar and starts using the new Drupal navigation. It's really cool how much better everything looks afterwards. So, I'm going to hit require on that real quick. And you'll notice because I have recipe unpack already installed in this, it did not even bother putting that dependency into my composer. it auto unpacked everything. So now I have all my dependencies sitting there. I'm now going to cd into my web routt um just because when you're running drush commands that's where you're supposed to run them out of for recipes. And now I can do oh I should mention up here when I ran it it also added this recipe to my recipes folder. And it's just the one recipe. It's not all of Drupal CMS. So now I am going to do Drush recipe. And remember it's above my web root. So I'm going to do slash or dot dot slash uh and I'm going to do Drupal oh I'm sorry recipes Drupal CMS admin UI. Okay, so this is me executing the recipe. Oh, something didn't work. And you know what? I had this happen earlier today and uh I told Phipox Proxia that I would reach out to him and tell him that it happened again and exactly what happened. But I'm not going to do that right now because y'all don't need to watch me jump over into Drupal Slack and try to troubleshoot something. I've got a better solution for that. I'm just going to do a composer update-w cuz this fixed it earlier. There's something weird about something weird about the dependencies of those two things that were causing this problem. So, let me cd web one more time. I'm going to run that recipe command again. And shoot, Bob's your uncle. It didn't work. Uh, let's see. I can get myself out of this. This is an error that I'm going to work with the uh Drupal CMS and recipes folks to figure out so that it doesn't happen again. >> What happens if you exit the terminal and log back in? Is it maybe like a memory issue? >> It shouldn't be, but let me uh I can do that. I can add a new terminal. CD web crash sp still not going to do it that that's okay I've got my workar around right what it's doing is it's saying I can't find the modules I actually think this is something related to dub and udigen and how long it takes for it to sync and the >> actually have the files appear >> but I know the files are there so what I can do as a workaround is I can actually run a couple commands to just enable things. So, what I'm going to do first is I'm going to do Drush. Um, I'm doing theme enable. I like the shortcut of thin or thin. Um, you can literally do thin or thin, which is kind of fun. Uh, so I'm going to do gen successfully in installed and I'm going to do brush enable. This is uh project colon enable, but the shortand is brushen. So, coffee. Uh, that should be the rest of them. Okay, they're all installed. Um, so I I basically just worked around the fact that it said it couldn't find them. Normally, the recipe would actually do this installation for you. So, pay no attention to the man behind the uh uh curtain there. Now I can run my drush recipe and it will correctly apply it. And everybody saw how quick that was. Normally it's that quick, but it does the installation. So it it decided not to do it that time. And I literally ran into this bug again earlier today. So it's not completely unexpected. So now that I'm here, um, let me go back to DDev launch. I'm still logged in on my site over here. Oh, look at that. I'm running the navigation toolbar. And if I go to my content page, it looks like Jen instead of like Claro. Kind of cool, right? So, we literally just applied a single recipe from Drupal CMS. Um, everything is unpacked, which means that technically at this point, I would delete the recipes folder. I don't need to commit that because I should in theory never need to apply it again. There's some exceptions to this and depending on your workflow and your developers and how they set up their recipes, they may want the recipes to be something that can be reapplied. But in this case, I don't really need it, so I'm going to move it to trash. So, I've literally taken a vanilla Drupal 11 site. I've applied a recipe which automatically unpacked or I required a recipe which automatically unpacked. I then applied it and dealed with a bug which wasn't as fun, but I did it. And now I've got a site running just that recipe added to a standard profile. What do y'all think? I'm pretty happy with that. Um, if you'd like, I can do it for a Drupal 10 site, uh, because I have that up and running as well, but I'm also willing to take a moment to stop and answer any questions from >> For those of us who aren't yet fully familiar with recipes, what what entails a recipe? Like, is it a obviously there's a composer aspect of it? Is there config management aspects of it as well? >> There is. Let me break down by showing you the recipe I just applied. I'm going to do it again here and do composer require Drupal uh Drupal or I'm sorry Drupal CMS admin UI. And I could do this for any one of the Drupal CMS ones. Um there are recipes outside of Drupal CMS. There's actually some really cool ones out there that are documented. Um I'm trying to remember the name of the documentation. I probably should add it to the presentation, but uh uh the Jim Burch does a lot of the recipe stuff out there and he's created a page within uh Drupal documentation that outlines quite a few really cool recipes for a lot of things that you wouldn't necessarily expect. Uh you could break down some of the recipes from like say uh Martin Anderson Cluts Manlue. Um you could break down his recipes from event platform. Good place to look. But the Drupal CMS ones are really clean. Um, so if I open this up, what you're going to see is a license file, a composer.json, and a recipe. Um, you'll also see some tests, which means they put some tests into it. Um, but then you'll see config, and this is where that config comes into play to actually apply that. Uh, so let me break that down piece by piece here. So, first of all, this is a recipe where you can see the basics of what's being included. First line there, you can see what it's trying to install. If I compare that to my composer.json, you will see that those values match, right? It's trying to make sure that your recipe is installing the same things that are in your composer.json. Um, the next thing you'll see is config. And you'll see that it's importing a set of configs. So, in this case, it's importing some configs specific to Jen. It's importing configs specific to navigation. Yeah. And if I take all those examples of config and look at the config folder, um you can actually see the breakdown of that config. So some of the config that it's referring to >> rolled into a single file. >> It's all rolled into a single file. And you know what the awesome part is? When you're building recipes, you know, you can do a Drush config export. If you just delete the hash ID from the top of a config export and throw it into a recipe config file and then put the dependencies in in the correct format cuz it's all just YAML, right? That becomes configuration that will import as a part of your recipe. >> How do you get a config like this where it's rolled into one as there? >> So this is not all of it rolled into one. this particular recipe, the only config that it's calling that is not defined somewhere else is this block layout. So it's it's doing the block layout for you. The rest of the config follow the actual uh uh installation of the >> Yeah. So if I look at this block gen breadcrumbs gen context, all these configs that it's importing, it's actually importing that from the gen module which gen module already has defined as a part of installing gen. And so it's it's doing that additional work here. So um the example of the block navigation block is something specific that isn't a part of enabling navigation block. And so they had to add that additional configuration over there. So >> could you do uh just another basic overview of creating a your own recipe? >> Creating your own recipe. Um so there's no automated way to do it right now. Um there are a couple of ideas out there for doing recipe exports. Uh one of the ideas that exist is uh to actually how many of you are familiar with the features module? >> Okay, features I was just having a conversation about like there's no reason to use features in modern Drupal. Like you just you don't need to. Please don't use it. Um use config and use config split. that will work for 99% of your use cases unless you're on a massive multi-sight and you've got to turn off and on features and yeah, okay, using a features to create a featured module and then going from there kind of makes sense. But they've actually talked about doing something similar to what features does where you can say, oh, okay, well, here's a set of dependencies, export that to a recipe. And I think when we get to that point, recipes are going to become much more accessible to site builders because now suddenly you're you're going to be able to say, "Oh, I just created this view and this content type and I create a little bit of default content and I added a really fast car." And the result of doing all that is like an export recipe. I I hope the mic picked that up cuz otherwise it's not a very good joke. Uh, but the result will be a recipe that you can then apply to other sites, which is awesome if you're somebody who needs to apply things to multiple sites, such as when you have a feature you need to turn on for a second. And I would actually argue that like this kind of works in that model a little bit as well in that your real dependency is that initial configuration of turning on the feature. You now have the content type, you now have the views, you now have maybe a little bit of default content. um you should never need to do that again, right? >> If you do need to do it again, it means you have to account for it and upgrade scripts and stuff like that. So I I I don't have a full like presentation in mind for like walking you through step by step creating a recipe, but I think from a site builder perspective, it's coming soon. From a developer perspective, the documentation out there is pretty good. Um, it actually required a ton of pre-work in Drupal core to basically do something that's um called config validation across all of the different configurations in Drupal. And there was a update a few versions of Drupal ago that when you updated it, like it it made a massive config change. >> So hilarious. >> That is the loudest car >> and it's not getting very far. It's just stuck in one spot. That's amazing. >> Oh, this this is awesome. This was outside my hotel room last night until about till about midnight. Um, all that to say is from a developer perspective, there's some some cool things to be able to uh put one together. It does it is it is pretty technical to build a recipe right now. I I don't think it's something like if you're a really good site builder, even an advanced site builder, it's probably not something you want to undertake. Um, which is why I don't know if I can like go through building one in in real time, but >> as a developer, you can figure it get >> you can figure it out because it's really about that syntax of that recipe. YAML file >> stuff that you've already done export and pulling the pieces into >> pulling the pieces together and then putting it together into the thing that you want to reuse. And I think this is going to be really powerful for like if you used to build distributions, you might shift instead to just building a recipe. And when you think about Drupal site templates and the site template marketplace that's being bandied about, right, that is essentially going to be a recipe. It's going to be a recipe that says this front-end theme combined with um this set of modules will give you a site that accomplishes this use case. And that's that's super powerful, right? Um, and the recipe unpack I think is just kind of cool from I've applied it, I've got the thing I want and now I'm maintaining it as a Drupal site, not as a distribution of this. Because how many of you have done a distribution and then you changed like two or three fields on it and changed a view and now suddenly you can't update your distribution anymore and you have to undo the distribution which was really hard to do before 11.1 cuz you know removing a profile was super hard. Um this is a powerful way to do it is you unpack it you use it once and then you go along your merry Drupal way. >> More questions. So recipe unpack is in Drupal 11 to delete the module in like to to install to do the compos thing uh and then see it like actually get installed as an unpack recipe. >> Yeah. So like in my Drupal 10 example here, I don't have uh Drupal composer recipe unpack. So, I would want to do a composer require uh Drupal Drupal damn Drupal recipe unpack. And if I type that all correctly on my first try, triple triple dam apparently. I don't know if y'all saw the uh the close captioning there. Oh, shoot. I did it wrong. It's not underscores, it's dashes. >> Can't remember live demonstration and I I have the things in my head and then I lost it. >> It's core recipe unpack. Thank you. Ah, so sad. Live demo. There you go. So you'll notice here, this is the thing I was telling you about at the very bottom where it says, "Do you trust Drupal core recipe unpack?" You you see this not for most Drupal modules, but when it's a Drupal module that changes something else, like say you added C Wiggins patches, composer patches, or if you added uh the Wikipedia Foundation has like a composer merge plugin that you can use for doing some cool things with web form library dependencies. Um >> there's a composer plugin available specifically. Yeah, >> my favorite is the manifest. Have you seen the manifest one? >> I haven't used that. >> It just creates a man like it'll create a instead of having to look through your lock file to see what version of whatever got installed, but it'll just create a long manifest of um everything that was installed. It's a oneliner version number. It's super handy. >> Nice. Composer manifest. Um had to look up that and and try to apply it to something cuz I like anything that simplifies the view of things. So by adding that dependency now um any additional command I ran against that Drupal 10 site even though it didn't have it before recipes works the same in 10.3 as it does in 11.2. So you're able to run that composer uh composer Drupal colon recipe unpack and it will unpack the recipe. And I I should mention too, if you have a specific recipe that you want to unpack, like in this example, um I required the recipe previously and I want to unpack it now. Actually, do I have it there? Oh, I'm on allow plugins. Okay, here. So, um I installed the recipe and then I installed composer Drupal recipe unpack. So now I can say uh composer run my script drupal recipe unpack and what you should see when I hit it is admin UI is going to get replaced by the dependencies. There you go. >> But it's running as all the recipes that are in historical. I could have in addition to running it the way I did, I could have specified >> uh Drupal >> uh Drupal CMS admin UI and it would run just against that one. Uh obviously it didn't that time because >> there I already removed it. >> But if it had been there, I could run that and it'll say, are you sure? And then it'll run it against it. You can pass it a I think you can pass it a dashy as well to make it just apply. So, but super powerful to be able to do it one by one um and and just kind of get that. Incidentally, if I had a dev recipe, so it was a dev dependency instead of a core um dependency, a require versus a require dev, um I would have to run it against the specific recipes in order to remove those from my environment. So like maybe I have something would be like a oh I don't know like a a dev dependency to devil uh or some other module that you mostly don't use in production. Um then being able to run that against that explicitly is important. I still have time for more questions if you want. I'm a fast talker so go ahead. >> Um I was thinking about maintenance. So if the recipe updates, would you just do composer update like right here or do you have to reinstall the recipe and update the recipe? >> Yeah, so that's the beauty of recipes is it's a um it's meant to be run once to give you your configuration. All future maintenance and updates is against the dependencies you now have unpacked. >> So I'm not going to update Drupal admin >> is basically just their expecting. Okay. Yeah. >> Yeah. It gives it to you the first time. Yeah. So now whenever I see that there's an update for Tagify or I see there's an update for uh SAM which is uh simple add another mod module or something like that it it makes your uh uh entity reference fields where you you have add another it makes it collapse down into a single value instead of starting with two which is a horrible UI experience. It's it's a neat little like fix that they added into Drupal CMS because all these like little bits of goodness get added into Drupal CMS. Um so like any changes to those you would see as individual to that module and you would update it individual to that module. you're no longer updating it >> like oh now this recipe now a year later requires two other modules or >> so that's kind of interesting because um certainly within the first year of development of Drupal CMS I experienced what you're describing is that um they started adding additional dependencies as they went along a good example was uh under privacy they went back and forth a little bit on CLO versus another module under analytics um they ended up trying to figure out a way to do both Google Analytics and something that wouldn't require giving away data, you know, like trying to really think about like what would site builders possibly want. And so they added different dependencies over time, different modules. The AI module added all kinds of dependencies between when it started and whenever it uh to where it is right now. And I expect more to come. Technically, you could rerun a recipe. Like you could require it again and then rerun it. If the configuration validates and it says you haven't changed enough of this site that this recipe no longer applies, it would absolutely update with the new dependencies. The longer you go, the less likely that is to happen. >> So, what would you recommend if somebody wanted to keep their recipe fresh or does it not really matter? I mean that's all the changes properly. >> If if you really wanted to go that route where you wanted to use recipe based instead of uh recipe unpack based then you would want to make sure in Drupal 11.2 2 and beyond to add a recipe on on require false to the recipe on pack which means as you required the recipe you would then have the option and then you would only manually run that command against the recipes that you were willing to give up. Yeah, absolutely have that option. >> Um yeah, so it it it's possible. I would say with most of the Drupal CMS recipes at the point you're applying it, you're building something and the likelihood that you're going to want that new feature that they come up with 6 months from now is much lower. Um, there I I expect there to be other developers out there that will want you to install the recipe and then reapply it every so often. But I hope that that's a minority of developers because really the intent with recipes were these immutable changes that you do once to your site and then you live with the results afterwards and and live hopefully happily with the results afterwards. That's the goal. >> Stuck with it for life. >> Yeah. >> I mean, you can always kind of unpack a recipe. you just kind of like go, "Oh, they updated these things. Maybe I want these things. I could just take those dependencies and install them separately." >> Nah, not as easily as you'd think because configuration, right? Configuration needs to be immutable. So, if the thing they changed was they added a new field to a view, >> you can't reapply that recipe. And >> No, I'm saying I'm saying if if you're not using the recipe anymore cuz you've unpacked it. >> Oh, yeah. But you wanted to take some updated attributes from the recipe, you could just kind of >> reapply it. Yeah. Well, >> manually >> manually apply it. Yes. Yeah. You could absolutely follow along in a recipe and then try to to incorporate those things back in, >> right? >> It's it's an interesting framework, right? Like this this idea to wrap your head around. It's it's meant to be a template to get you started and then you have an amazing Drupal site that is really extensible. It's not meant to be like a distribution where somebody's maintaining it for you. >> Um, and you can't customize it anymore because if you customize it, your distribution update may break, right? Like you just used it as a template and now you forget about it. >> Distributions are really annoying. >> I How many of you had to migrate something off of Lightning? >> Really? That that few? Okay. >> Aqua I forget what it was called. Commons commons. Oh yeah, there's another one that that went away. But the lightning distribution was actually on Drupal 8, which was so hairy. >> I had to do the lightning, too. >> Yeah, really hairy to get away from it once you're on it. Um, and that wouldn't have been a problem here because instead of a lightning distribution, it would have been, hey, here's some opinionated ways you could build your site. Build it, change any of them you want. you never go back to this, which is the idea behind recipes. It was really to address that idea of distribution lock in. >> There really is still a place for distributions though. >> Oh, there there is still definitely a place for distributions. It's just like if if truly what you're shipping is a site template, which I would argue Aqua Lightning was, um, then ship it as recipes. But if it's if it's something where you're going to maintain it and you're going to enforce that maintenance to your customers, then I think lightning or I'm sorry, distributions make a lot of sense. Um, uninstalling recipes, which use case would be like you got three, you put them in, and then tomorrow you go, oh, number two, I shouldn't have done that. >> Are you stuck with just manually going through? That's >> so the question was uninstall a recipe. How do you do it? And the answer is if you've tested the recipe and it's done what you've done and what you wanted it to do and if you followed all the best practices mentioned by a couple of the other presentations and you've got, you know, premerged dev QA and you're doing all those things, right? You're you're doing your equivalent of tugboat and diffy and automated tests. Uh, which I do think are best practices doing that kind of stuff. Whatever tools you use in that chain, do that chain the same. Um there's still the option of not merging it um or rolling back a commit. But once you've applied it to the database, there's no there's no real option. You you've got to manually remove the things that were added to it, which means fortunately you can go to the recipe, look at it, and say, "Oh, this is what it did. I want to uninstall these things." Um which is it's very transparent in that way, but it is very manual. >> It doesn't like if you haven't unpacked it yet, it doesn't have an uninstall option. just >> there even if you even if you didn't have unpack unpack in place or recipe unpack in place if you've applied a recipe there is no unapply >> I see >> right you you are doing it >> the composure package but that wouldn't change >> yeah it doesn't change all the configuration >> you would have to uninstall the modules that it installed and um think about the config that it's going to delete and all that kind of stuff >> you could you could in a lot of cases is just revert that commit. So if it's adding the default content or getting taken down, >> yeah, >> that's going to be unless >> anything that changes your database, which is going to be something that pushes config in a way that um could be destructive, you know, like that. That's the kind of thing you can't undo with a recipe. Again, it's not a bad thing though if you're looking at the recipe as something that you've applied locally, you've tested it, and it is a feature you want in that that shape. Like admin UI, perfect example. If I'm if I'm doing that, I want all those features of admin UI and then I'm going to continue to to kind of live with the way admin UI works afterwards. Um, and that's that's the way recipes were meant to be applied. Any more questions? Cuz we got one minute. All right. Thanks everybody. [Applause]