Talking Drupal #417 - The Recipes Initiative

• What are recipes
• How do you use recipes
• Is it a module, configuration or something else
• How do recipes compare to install profiles
• Are you stuck with them
• What happens if the config is changed
• Are there namespace collisions
• How do recipes compare with Distributions
• Can you include content
• Listener James: Can recipes uninstall modules
• Can we use recipes now
• When will recipes be in core
• Can recipes be used by tests
• Listener Andy: Can recipes and startkits interact
• Can themes require recipes
• Listener Matthieu: How do recipes compare with Symfony recipes
• Listener James: How easy will it be to make custom recipes
• Listener Matthieu: Should contrib maintainers be watching recipes
• How can we get involved

 [MUSIC]



 This is Talking Drupal, a weekly chat about web design and development from a group of people with one thing in common. We love Drupal. This is episode 417, The Recipes Initiative.



 On today's show, we're talking about The Recipes Initiative, the future of installed profiles, if distros are still a thing, and answering a bunch of listener questions with our guest, Jim Birch. We'll also cover the Quick Links Kit as our Mod of the Week.



 Welcome to Talking Drupal. Our guest today is Jim Birch. Jim is an internet professional who can bridge the gap between technical staff and business goals with specialties in Drupal, front-end development, content strategy, and SEO. He's an accomplished strategist, developer, community organizer, and believer in bridging open source communities. He spends his days leading an incredibly talented team of Drupal engineers at Canopy Studios.



 Jim, welcome back to the show and thank you for joining us. Thanks for having me. It's great to be here. I'm Nick Laflin, founder at Enlightened Development, and today my co-hosts are, for the next few weeks, Jen Lampton, owner at Generation Web Development.



 Welcome back. Good morning.



 By the way, I love the kind of, I don't know what you call it, alliteration or the name of your company containing your name. Is my company name kind of does the same thing with my initials?



 Nice. But I always love to see that with other people too.



 Also joining us, as usual, John Picozzi, Solution Architect at E-PAM. How are you doing? Hello, everyone. I'm actually surprised, Nick, you being the lingo file that you are. You don't know what that is called. I feel like there should be some sort of linguistic name for, you know. Probably something to do with eponymous, because eponymous means self-named or something. There you go.



 And now to talk about our module of the week, let's turn it over to Martin Anderson-Clutz a senior solutions engineer at Acquia, a maintainer of a number of Drupal modules of his own. Martin, what do you have for us this week?



 Thanks, Nick. Have you ever needed to add a set of Quick Links, essentially visual navigation prompts, to the homepage or section pages of your Drupal site? There's a module for that. It's called the Quick Links Kit, which is different from the Quick Link module created by last week's guest, Mike Herschel. It's a module that I created in April of 2021.



 It has a 1.06 version that supports Drupal 8, 9, and 10, and a 2.0.1 version that supports only Drupal 10, for reasons we'll talk about a little bit later.



 It is, to be honest, sporadically maintained, but a pretty simple module. And really, once it's installed and you've imported the configuration, it's something that you can safely uninstall and not really need anymore anyway.



 Now, it has only one issue open, which is not a bug, which is probably not surprising, considering that it is according to drupal.org in use by only one website currently.



 Now, the module is really just a set of configuration with an optional sub-module that sets everything up, including the placement of the block on the homepage for sites using Oliveiro as their theme. So it's perfect for a fresh install of Drupal. It allows for SVG icons to be set for each link and sets their fill to inherit from the link style. The links can be created and managed without leaving the page on which they're used. By using the settings tray, there would be a quick configuration change to use a modal or a separate page instead, if that's your preference. The 2.0 version also makes use of Drupal 10's new responsive grid views display, so if that's something you've been wanting to try out, this is an easy way to take it for a spin. I thought this module was appropriate for today's episode because it's an example of a module that will be a great candidate to be a recipe once the infrastructure for them is ready. That said, the Oliveiro sub-module does currently contain a little bit of CSS to improve the display of links, but that could easily be copied into your site's custom theme. So let's talk about the Quick Links Kit.



 I'd like to update the usage stats. It looks like two sites report using this module.



 You've doubled its exponential growth. You've doubled your user base. And so it begins. Directly related to talking Drupal, I'm sure.



 So, Martin, I'm wondering, what was your use case for creating the module? Was it just a necessity for you to be able to quickly add links in this manner, or was there some other use case that you had for it?



 So it actually started because I was working on a project that was really creating a website template that was going to be in use for multiple small municipal sites. And so that was a common requirement across all of them because they'll usually have, "Where do I get my parking permits?" or different kinds of things as having those Quick Links on the homepage was a common pattern for municipal sites. And I had built it as a module specifically because I wanted it to be reusable across those different sites. And then at the end of the day, it seemed like something that could easily be made into a contrib module and really shared with the rest of the community.



 Got it. That's super, super interesting. And I like the use of the settings drawer aspect of it. That feels like a really great way to administer that.



 Yeah, I think on that project, I had used that quite a bit. So also using the settings tray with a custom block for...



 or with the config page module to be able to have things like the header as something you could sort of slide out and change without, again, leaving the page, which I think for editors is kind of a nice pattern to say, "I don't have to take you off to someplace else." You can stay where you are, make updates without sort of leaving the page that you're on. One question I had is the icons. How customizable are those?



 So it's really just using... Essentially what it will create is a custom media type for SVG image, and then you can import whatever SVG icons you want. So it can be from like IcoMoon or any of the popular libraries that are out there. Oh, nice.



 Based on the visual on the module page, it looks like you can just upload your own too, right? Just to drop an SVG in there if you want. Exactly right.



 Are the images required?



 I don't believe that they are, but that's a good question.



 If they are required, it would be a simple update once you have it installed to either make them not required or to remove the field entirely. Because at the end of the day, it's just a set of sort of starting point configuration that you can then customize to your particular needs.



 So based on our primary topic today,



 I assume that you, based on what you said, are considering moving this to a recipe maybe at some future state?



 Yeah, I think once it feels like recipes are no longer experimental and ready to go, I have this as well as a number of other modules that I'm looking forward to making into recipes.



 Interesting. Well, maybe throughout the show, we'll figure out how you could make that transition and what that transition might look like for the end user.



 I'm looking forward to hearing more about that.



 Well, as always, Martin, thank you for your on-topic Modules of the Week. And yeah, I'm interested in seeing how that's going to work too. So thank you. See you next week.



 OK, so moving on to our primary topic, let's start off with



 what I would think is a simple question, but might have some unexpected complexity. Can you tell us what recipes are?



 Sure. So the Drupal distribution and recipes initiative,



 the code in the project creates and then allows for the installation of Drupal recipes,



 which allows for the automation of Drupal modules



 to be installed and configured



 using Drupal core as the installation.



 It is meant as an effort to



 add on to the ambitious site builder effort that Dries introduced a couple of years ago, where we would want to allow a site builder to install suites of functionality.



 So that's traditionally been done using installation profiles in Drupal and distributions.



 Occasionally features in Drupal 7, and there are a few different solutions using a lot of configuration manipulation modules in modern Drupal or Drupal 8 plus, whatever we're calling it these days.



 But the difference is that once you start with an install profile from



 Drupal or a distribution, you're stuck with it for life. So you can never get rid of the installation profile.



 With a distribution, the dependencies are so interwoven that if you try to install something, you may uninstall something else accidentally.



 The idea of recipes is that they hold no code. They are for installing configuration and requiring other dependencies, and they're meant to be composable and ephemeral. So you can connect them. You could have multiple recipes being called from recipes.



 But once you install them, they're gone. There's no no business of it. So in a module like Quick Links that we just learned about, that is basically a configuration-only module. He has no code in his install, his module file.



 You can install that module, but traditionally, when you uninstall a module, you would uninstall that configuration.



 So in a Quick Link kit recipe, you could install that configuration and nobody would be the logic. You'd have it forever. You could have it and alter it as you see fit.



 So this tool is meant to not necessarily replace the installation profiles or replace distributions, but become a tool in that stack.



 So there are some distributions where they want you to stick with the distribution altogether.



 OpenSocial does so much to create a social media website for yourself. You need them to continue to update the code. But if I just want to blog or if I want to add on a recipe book like Umami,



 those are good examples for just adding suites of functionality.



 We've seen the most interest right now from agencies like myself



 who want to have a starter recipe that lets us install everything we need to but not tie our clients to it forever.



 So there's a couple of use cases, but then we're spinning around use cases like, oh, how do you do mail service on a host that doesn't rely on mail service? So could we have a simple recipe that installs the SendGrid module and configures that for you? You know, we've probably all done it a dozen times in our careers last couple of years.



 Could be automated down to recipe install this recipe. So this is kind of bringing in the piece that we lost with features, it sounds like on some level, like there's some additional features to recipes than the features module had. But, you know, I think on its face, people thought config management was kind of like features, but there's just a lot of gaps, right? You have to be really careful about what the site UI ID is, you have to be careful, like dependencies don't all automatically get exported. So if you're trying to get a feature that's not a feature, you have to be careful, like dependencies don't all automatically get exported. So our recipe is going to kind of be like that feature, like you turn it on, you get all this stuff and you're good to go.



 Yeah, I mean, it's once you install it, you have that functionality and you need to save it in your database or export it to your config management.



 But, you know, you could remove it from your composer.json or not even have it in your composer.json, just bring the recipe down locally and install it and then push your changes. So because features were modules in themselves, you know, it kind of moved on to, you know, that you could use features to package up a module, but it's still a module and you still have the inherent problem of having to have it installed.



 For all those, this was Nick, or for people that are just listening in, Nick really loves the features module. It's a constant, that and web components are a constant topic, all right? At least use it. Yeah, I mean, I haven't used features probably in almost 10 years because kind of hasn't been used in Triple Eight, but... But wow, it's almost 10 years. But it does exist. It does exist.



 Jim, you kind of actually just touched on my question a little bit with what you were just saying.



 Before I ask my question, though, you know, I would like to highlight the fact that you did a talk at Design for Drupal.



 On this, we have the slides in the show notes for the listeners. And I was in that talk and it was very cool and very interesting. So, you know, thanks for coming on and joining us to talk more about it. So moving on to my question, you just highlighted a little bit, you know, that basically a recipe is still something you need to install, right? So it works the same way as a module where you install it. It's just like after it installs and sets up all of the stuff that it needs to set up, you have the ability to uninstall it and remove it from your code base. Is that accurate?



 It is not like a module. Maybe installation is the incorrect word.



 Maybe we should use the word applied.



 Jim, in answering Nick's question, you kind of highlighted a little bit of what I was wondering about. And it really boils down to like how somebody would use a recipe, right? So like as a Drupal developer, right, I may want to or an ambitious site builder. Right. I may want to use a recipe on my Drupal site, understanding that things are experimental right now. But like, how does somebody do that? Is it is it simply a composer require and they they install it, apply it kind of like a kind of like a module that then they can just remove when they have the configuration or is there some other some other process to that?



 Sure. Great question. So.



 Recipes are applied, they are not installed like a module or theme.



 You could require a recipe into your. Composer project, or you could require a recipe into your project using composer as long as you added additional composer type and your recipes composer file specified it was a Drupal recipe.



 But inside of Drupal core in core scripts, there is a script called Drupal



 and the patch that you apply to get to use recipes has a command called a recipe and you give it the path to the recipe.



 And that basically recipe runner grabs a recipe and applies it to Drupal.



 And then, you know, if you wanted to keep it in your composer package, your composer file, you could, but you wouldn't need to. One thing that is on the road map is that a recipe could have a composer file and could require modules.



 But the recipe runner itself Drupal doesn't know about composer, right? Only composer knows about Drupal.



 So there's a gentleman who developed a add on package called Drupal recipes Drupal recipes unpack, which allows the recipe to unpack its dependencies from the recipes composer file to the main sites composer file. So you do have those things required moving forward. So all right. So hold on, hold on. I got another I got to follow up here. Follow up question. This feels like functionality that needs to be added to Drush, like, you know, Drush get recipe or apply recipe, whatever the name is. Is that on the road map somewhere or something somebody's thought of or am I breaking new ground here?



 It has been a feature request by people that have not built it yet. So it stays a feature request.



 Since this is going into Drupal core.



 The idea that the core scripts Drupal script would have everything it would need and Drush wouldn't be a dependency.



 Yeah, that could be pretty easy to add to Drush if it already has support in core because Drush would just need to call the core command. So I feel like just because it's a feature request now doesn't mean it's not likely to happen very quickly. Maybe I missed it. And then I will let you ask your question, Nick. I apologize, but maybe I missed it. But like, so if your recipe requires a module or a set of modules, right?



 Is that only, is that core command also running the composer to go get those modules?



 No, I believe the composer require would be needed in that step. Got it. Okay. Got it. Okay. That makes sense. Yeah. In its, the initiative is still in its infancy.



 One of the biggest issues we're working on now is creating the Drupal



 install standard install profile as recipes.



 So, you know, as far as core would be concerned, that standard install profile



 doesn't have any outside composer package needed. It would just be enabling modules. But yeah, as a recipes evolve into the contrib space, that's when composer would be needed. Good deal. Nick. Sorry. Go ahead.



 My question was kind of related, but it's really just around, it sounds like there's kind of two different types of recipes. One is that has other dependencies and one is that really is truly ephemeral. And I'm just thinking about the delivery method of the more ephemeral ones. Cause I'm thinking as a developer, I'm not going to want to have to require something in composer to apply the recipe and then remove it from composer, like that composer step just seems extraneous, right?



 Now for something that's, I'm going to have to, that's a little bit more on the profile or distro side, where I want to reapply changes as they come down. That makes more sense to just include into composer, cause it's a pen, save my project now. So I'm just thinking about like, how, how can these recipes be delivered



 in a more ephemeral way when, when they truly are just ephemeral, like the quick links one that I mean, right.



 I think that's through the core script though. Right.



 Well, the core script applies the rest lies. It doesn't fit. So yeah.



 So in the quick links kit example, the recipe would have a config folder.



 So it'd be almost laid out like the module is now, except it would be applied not installed. So that configuration would get imported into your Drupal instance. It only requires core modules. So like the sidebar deal and the media entity.



 So that in that instance, it would be, you know, you wouldn't require anything in composer, but yes, if you did require other modules, you would need that composer step to go out and get the modules. And then this other composer package Drupal recipes unpack to unpack it to your main site.



 So, so it sounds like to me, either core, the core script has to be updated to go get the package and, and then apply it, right. Or maybe this is an area where Drushkin kind of combine those two, those two steps, even going as far Nick as to maybe uninstall it after the fact with a, with a flag of some sort. So that way it kind of does the whole thing for you. Right. I mean, I mean, Drushkin doesn't do any composers stuff really that I'm aware of. So I don't, I don't think it would do that step. I think it just look like Jim said, right. This is meant to be core. So you don't want additional dependencies.



 So at it's, you know, right now, though, all the work that's being done is to get it into core. So, you know, once that happens, you know, it can be extended. You know, there, there is a roadmap where, you know, these things need to happen for phase one to get it into core. And then what happens in phase two, you know, initiatives, you know, to me, the Drupal core initiatives are the proof of concepts by extremely smart developers. And I just, you know, should point out that that is not me. So I'm an initiative coordinator at best. The initiative lead Alex Pot has worked a lot with Fabian Burchner and a lot of the people that have developed the configuration management system and the contrib modules that are in that config management space. So config ignore and config split, config actions.



 WIM LIRS is doing a lot right now in the config validation space.



 So, you know, the configuration management is great, but it is actually like when you import it into Drupal, there isn't much validation that happens. So he's doing a lot in that space where you can basically, you know, go in and validate the configuration and how that gets applied to recipes would make things safer and work better in the long run.



 So you, you mentioned a lot about recipes being configuration. Do they have additional code like a module would, or are they only the configuration that get applied? Yeah. So that is where I think the separation of church and state happens where recipes do not have code.



 So they have a config file.



 You know, one of the, I gave this talk at design for Drupal and DrupalCon and yeah, everybody says, well, we need to run update hooks after we import the config or we need to do this or that. So that's where recipes can be chained.



 So you can have this recipe require this recipe require that recipe and then recipes can require modules and enable those modules also.



 So if you need to add code along the way, you can do that in a module that recipe would require.



 So I'm going to go off script for a second and ask, have you, do you know if anybody in the initiative has talked to you're going to ask at ECA? Cause I know that he has a configuration export or like a feature export for helping him debug ECA models that does a fair, like it will export a list of all the dependencies of modules and it will export all the relevant configuration for the model, including content types and that kind of stuff. So it kind of handles some of that dependency gathering bit into it. And then he has an import function that will import all that into a site so he can, he can test a model. So I don't know if that's something that could be, you know, possibly built on or, you know, any, any issues that he ran into might be helpful for Alex and the team to think about too.



 Sounds cool. Yeah, I don't know of any interaction with that gentleman or that module, but it is on the roadmap to, you know, have a recipe UI eventually where you could help put together a recipe from configuration. Like wouldn't that be a site builder's dream? I could build a blog and then export it to a recipe and share it with the world.



 Yeah, that'd be awesome. So you've mentioned profiles at the top of the show. Can you kind of tell us a little bit more about how they interact? Because I know, for example, like you said, if you start with the minimal profile and then you try to import some config from a site that has standard profile, it's just not going to work. It's going to be like, hey, these are different profiles, which personally I've never really understood because it's like if the module exists or that functionality exists, why can't you import it?



 You've already said that that's not the case with recipes, but can you just apply, like once a recipe is applied and that's taken away, like there's no residual, there's nothing saying that something came from a recipe, right? So there's nothing preventing you from applying a different recipe or applying the same recipe again or something, right? Like there's no hard lock. Correct. There are feature requests, like a question I know John's going to ask about, can a recipe be unapplied?



 You know, no, because at this point we don't know that a recipe has been applied, but you could apply a recipe that could undo a recipe.



 But yeah, there are all these discussions, you know, should there be a record of recipes being applied somewhere so you could alter them later?



 Maybe.



 But yeah, all these things are still up for discussion. So I'll double down. I'll double down on that question. And I think as you already answered my next question, I'm wondering, like a recipe literally is just a set of configs, set of modules, so on and so forth, like, hey, here it is, right? Once that configuration or the config that that recipe interacts with is changed, right?



 That recipe is done. So the recipe doesn't really care about it. The config is now in your site and you can change it as you would, right?



 Correct. OK, and then to get back to maybe that recipe's configuration, could you reapply the recipe? Is that like, would that overwrite the config that has already been applied or changed?



 That is the hope. I don't know of anybody who has done a proof of concept of that. Sounds like a fun issue to create in the issue queue. I mean, this is going to solve a huge problem for one of my clients, actually. So one of my clients has a number of a number of sites, right? And some of the some of the most of the functionality is very different between the sites, but some of the configuration needs to be the same, like CSP site header rules and things like that. And it's fairly tedious and complex to keep all that configuration synced between five or ten sites. But if we move that to a recipe, that just means if you need to add a new site header rule, you just add it to the recipe, reapply the recipe and you're good to go. And that can even become part of the pipeline, right? Because if you just version the recipe and it's included always, you just have part of those pipelines, just applies the recipe again. And that kind of stuff just will get updated whenever there's an update that.



 That's going to be a huge, this could solve a huge problem for that client. That sounds like it's all that problem, but I feel like that also creates a lot of other problems, that that was part of your pipeline, because then every time you're like, oh, I thought I fixed this view, like I wanted it to show up 50 instead of 10 or whatever. And then every time you deploy, it's like, ah, it's back again. If they have like, because they're maintaining this site, they aren't going to know what's in the recipe and what's not necessarily. And so that could also be a huge course of headaches.



 That's very, that's very, I mean, that's very much a documentation of culture type thing. I mean, for this particular client, I mean, we have a few things like that that we know are just like standard functionality that gets managed in this one place. Right. And so it's a small team. So that wouldn't be a huge problem, I think. And for agencies that can really see things like, hey, metatags are just managed this one way. They're in the recipe. And for people inheriting projects, yeah, that's going to be a major headache.



 But, you know, the efficiencies that you gain not having to reapply that kind of configuration five or six or eight times, I think is is worth the extra time you have to spend documenting something.



 I also wonder what it's going to be like, like if you have a slideshow on your site and then you install a recipe for a slideshow later, if there's like a conflict in like the names of the views or the displays or something.



 You're going to overwrite if you import that, not import, apply the recipe, you're going to overwrite that configuration, right? Is there some special convention that people use for recipes where the naming is done in a way that it's not going to conflict with anything that exists or? So I don't believe so. Since anybody can create a recipe, you could call it what you want.



 We'll go under the hood a little bit. At the core of recipes is an API called Config Actions.



 So Config Actions, there is a module in Contrib that was, I think, inspired by this.



 It's issue 330-3127 where the Config Actions API were added into the project.



 So Config Actions allow us to do a few things. Update simple configuration.



 So you could take, not only can you apply a configuration that's in your recipe, but you can apply individual FUBAR statements inside of your Config Action. So that's in this recipe itself. You wouldn't even need to have a config file for something like node.settings, user.settings. So we want to set our register to admin only or system.theme. We want to set the admin theme to JIN and the default theme to Stark or Oliveiro or whatever we want. So you can update configuration that already exists inside of Drupal. And that's one thing we've never been able to do from the config folder in a module, right? You always needed an update hook or something to get in there and actually change existing config.



 And then you can hook into a config and then change things or add things to it. So like in a Config Action, you could grant permissions. So you're creating a content type using your config folder, but how do you add the permission to edit any event to the user role? So like that's another Config Action that you could do.



 So I think if a recipe could find the config that already exists, your view that lists 50 items, if it could find the view and we could, you know, I haven't messed with views with Config Actions yet. It's going to be fun to drill down into there. But yeah, we should be able to find that setting and reset it. So I think, Jen, what you're talking about is, yeah, you could really screw up somebody's site that they've customized, you know, versus what Nick is talking about where he's more maintaining a distribution that requires us to constantly update. You can undo the problem somebody did. So I think it's trying to be, you know, the tool that we all could use. Like, yes, you could reapply the recipe later to make sure it's up there and updated or you could just let it be free out in the world.



 So speaking of distributions, how do distributions and recipes differentiate? I mean, I gather that distributions provide a lot of functionality, whereas recipes provide configuration.



 Yeah. So again, I think that distributions would be a tool. Sorry. Recipes would be a tool in distributions toolbox instead of just your config install, config optional and config override folder options versus having to write a ton of update hooks to change things. You know, they could use recipes as a piece of their distribution, a piece of their code base.



 I mean, the major thing, and we've discussed this here, though, right, is like distributions usually have code in them, right? So recipes solely configuration.



 I mean, I think the other big differentiator for me, and this is kind of what gets me so excited about recipes, is the fact that



 you're not hooked to them. You're not chained to them forever, right? So like with a distro, typically you are using that distro for forever, right? You're kind of like updating it as a whole module. So like, to me, it feels nice to be able to say like, hey, here's a starting point for your site based on this set of code and being able to kind of like



 run free, if you will, based on that starting point as where sometimes I think distros can get you into a spot where you're like, you kind of feel trapped. Is that fair to say? Yeah.



 And another thing distributions can include now is content. Is there any talk about allowing a recipe to include content in the same way? There is. It's one of the biggest pieces left in the phase one roadmap of recipes that hasn't been cut at all. So the issue is slim, but I believe it's the idea that there are config entities.



 So your configuration would be written into a file or your sorry, your content would be written into a file. That's probably going to be another full bar. Here's your field name. Here's the content.



 You know, the.



 There's a lot of thought about it. And like, I think we'll one of your listeners asked a question about the content distribution leaning more towards like a workflow scenario where somebody could approve content. I don't think it's going to be that, but I'm thinking it's going to be more umami like where you could start with default content.



 You would have to.



 Since it is content, right, you would have to reapply that recipe as you deploy to dev test and live or multi dev or tugboat environments. You know, so there are I think a lot of things to think about in that issue.



 Or what will turn out to be many issues. Is that is that accurate though? If you apply a recipe, right? I'm assuming that content gets added to the database, right? Yeah, it's not the environment that you of the environment that you applied it to. It's not correct. But like if you're just starting a site, then you're going to move that database from your your local to dev to stage to prod, you know, as you go.



 So experiences may vary, I guess is what I'm what I'm saying there, right? Sure, sure. That that's super that's super interesting. That was kind of one of my questions when when Jen was asking about content was like you said you were trying to rebuild the.



 You know, the default Drupal install profile, right? And part of me was wondering if you guys were also working on like an mommy install profile. And I imagine the content piece is a big part of that.



 There. Well, once we get through the standard profile, right? Which I can say I personally have been working on it for a few months now in my free time.



 Then I assume that the minimal profile will be relatively easy to do. And then there is also a ticket for the umami, which really can't do until that default content.



 Yeah, ticket is right.



 And John, just remember the point of recipes is that it's not just at the beginning of a site. It's not an install profile. It's not a distribution. Like imagine a privacy policy recipe that privacy policy includes privacy language as GDPR compliant.



 You would have to apply that at every single environment. You're not going to upload the database just to get that one piece of content that that would defeat the purpose. Yeah, yeah, yeah. I mean, that that's true. And like I said, like I think you have to you have to apply it how how you see fit. But it was just, you know, came to my attention that you may not necessarily have to apply it everywhere.



 Which goes back to our our beginning parts of this conversation with like how you go about applying a recipe is very important because you may have to put that into a CI CD process at some point in time. All right. We have quite a few listener questions in this show, which is awesome. So happy that our our listeners chimed in via via multiple methods, one being slack to ask questions. We actually have a question. Hold on. My computer just went to sleep. There we go. We have a question from James and he's asking. So we've been talking very additively about recipes like recipes can add modules and they can add content and they can add configuration.



 His question is actually, can you use a recipe to uninstall modules? He has a couple of modules on every site that he builds. He just he just takes them right out of there and he's wondering if he could have could use a recipe to do that for him. I'm assuming the answer is yes. But I'm assuming the answer is I don't know.



 But I would like to take a little step back and say, why does he have to uninstall modules on every site that he starts? Is it because he's using a profile that installs modules for him?



 It might probably. Yeah, there you go. You know, if he didn't have to use an install profile, well, you know, what if Drupal came with only system enabled



 and you can apply whatever recipe you wanted.



 Yeah, that would be great. It's a great question, and it actually started me to create issues in the Drupal initiatives, recipe and distributions initiative issue queue with the header proof of concept. So it'd be great to see if we could uninstall a module. I know we could alter core extension using a config action. And I don't know what it would do. Would it run all the uninstall hooks needed?



 But it's a great question. From a recipe perspective, if I'm reading into this question a little bit, I do feel like from a recipe perspective, all a recipe should do is change that config to say it is modules disabled, not uninstalled, but disabled, right? Because like when you uninstall a module, like typically it's a two-step process, right? You disable it from Drupal, then you uninstall it from your code base at some later date, depending on what your CI CD process looks like.



 So yeah, I don't know. Maybe, well, so hold on. There's one question just came to mind here. Is recipes working with other initiatives, like the update initiative, to possibly use some of their composer interactions to do some of the things that recipes may or may not need to do? Is that something you guys are looking at? I think it's on the roadmap.



 Got it. Discoverability, since this is for ambitious site builders, the primary is the primary audience, integrating with a project browser is on the roadmap sooner than automatic updates. Sure. But yes, I mean, it would be great if it could work with other initiatives also. I think too, the point is if you can use recipes as kind of your starting place, that'd be great. Whether or not it can uninstall. Uninstall modules, I think, would be helpful maybe on some level. But the true problem that I run into is I find you kind of have, if you're not using a distribution. Do you mean uninstall? Sorry, do you mean uninstall module or disable module? Because I think we're using that term interchangeably. There is a difference in modern Drupal. It's the same. You can't have a module that's not uninstalled. Well, I think the Drupal community still technically considers a module that's on the code base as installed. And uninstall means to delete it. I'm looking right now because I think that's right. It deletes all of the data from the database, obviously. Yeah, but not the actual files of the file system. Previous versions of Drupal had a state where you could turn it off and it didn't actually delete your data. And you could do that on your own if you wanted to or not. But now you can't have that. It only is there and not turned on yet.



 Or there and all your data is gone. That's the whole thing only. But you can have a module. Sorry, you were using the right terminology, Nick. That was on me. I was in my brain. I was considering uninstalling, like removing from the composer. John is still in Drupal 7.



 I'm very much going to update my lexicon here.



 Continue. Anyway, back to my question.



 It kind of sidesteps one of the problems when you're talking about starting with Drupal. Because one of the things I found is with Drupal 8, one of the other versions of Drupal, if you're not using a distribution, you kind of really have to use the standard install profile. I'm not saying you can't use the other ones, but I've inherited sites that use the minimal profile and have run into problems. Basically, if I'm starting a site, I'm using the standard profile. That's it. The standard profile also comes with modules that I have, like Tor. I am never going to use the Tor module. You can just uninstall it. It's easy. Comments.



 I think I've actually had a site that actually used comments that wasn't using Disgust or something twice in 15 years. Like it's very rare that I used that module. But you have modules like Shortcut, which some sites use. Some of my projects do. Most of my projects don't use Shortcut, but you can't just disable that module because it has content entities. You have to delete the default Shortcuts before you can uninstall the module. And I imagine recipes aren't going to handle that issue. But the solution to the problem is being able to say, "Hey, my recipe just installs all these modules, not including those three or four that I never use." Or like History, the History module.



 You almost never need that module. Like there's just eight or ten modules. Keep going, Nick. Keep going. But being able to instead go the other way and say, "I'm starting a new site. Install these 25 modules and be done with it," would be a huge boon.



 It would save half an hour of my time on every new project, which would be wonderful. Nick, I feel like it sounds like after this show, you need to create yourself a recipe that you can just start installing things from. I mean, when recipes are ready to start from, I'll be happy to do that.



 So you could use recipes right now because they're ephemeral and they can be applied and not shipped with your code base.



 There's no reason why you couldn't start experimenting with it now.



 By experimenting with it, you can hopefully find some bugs and create some issues and contribute some code back.



 I agree with you, but I do start all of my projects with minimal profile. And then I actually go in and import some configuration from standard that I need.



 There are some issues, like the workflow module assumes that there are states that were created in the standard recipe option. So there are some assumptions in Drupal Core, even in the end, and a lot of contrived modules that you are starting from the standard profile. That's why I never use minimal.



 Minimal always feels too minimal to me, which is, I don't know, maybe we should have a whole show on that topic.



 So what I did with my approach to replacing the standard profile as recipes was the idea of composability in those things. So like, what if I wanted the article content type, but I didn't want the tags taxonomy. So I tried to create the article content type, the tag stacks on me, and then another recipe that would have it installed with both.



 So that's where trying to come up with a stack of, I do like some of the stuff in the standard profile, but definitely not all of it. Like you said, comments.



 Jim, because of the structure of these, right, these are the recipes are, and correct me if I'm wrong here, the recipes are like, just basically YAML files, right?



 Somebody could take once this is released into core, right? And somebody could take that core recipe, install profile for core, right? And change it to be more of what they're looking for, right?



 Correct.



 So there you go, Nick, you have to wait. Once they have a full install profile, then you can take it and do whatever you want with it.



 So, so the, I mean, the idea of



 replacing the install profile as a recipe or a suite of recipes is a proof of concept. I don't know if that's going to be applied to Drupal core. You know, we, it hasn't been discussed with Drupal core team. There's an extension of that is other core modules have a config folder. I mean, should all core modules have their config folders replaced with recipes?



 There's an issue for it. I don't think anybody will get to it anytime soon.



 But there is that idea if it can be a core wide tool, or we're just doing this as a proof of concept to see if we can and install profiles will always remain in Drupal.



 Yeah. Okay.



 So speaking of recipes and core and issues, when will this feature be in core? When do you think, what's the timeline looking like? You think in 10.2, 11.1, 11.0?



 I would not care to wager on that.



 There's still a lot of work that needs to be done.



 Like I mentioned earlier, it seems like all Drupal initiatives are



 that I've seen as of late are the brainchild of a super smart developer or a couple of super smart developers.



 Some like single directory components, like Mateo, with that out in no time. He had experienced getting JSON API into core and, you know, within what six months, it seems like he got single directory components into core because he knew as fast everything, what to do. Other initiatives like the, I don't know, the JavaScript modernization,



 there was somebody trying to make the Drupal logs JavaScript. Like I don't think that had much effort behind it. It might still be going on. And then not all initiatives landed for, you know, they are great experiments and hopefully it'll end up in core sooner than later.



 - Once it is in core, has there been any talk about using it for the testing framework? Like we have a lot of tests that test whether Drupal's working, whether correctly or not. And those often include some default configuration to test something like, oh, does this content type have this field or what have you? Is there any thought of replacing that with recipes and would that make the testing system run faster?



 - This is the first time hearing of this brilliant idea.



 - It's a great idea. - Yeah, we could make an issue for it.



 - Cool. - So we're going to start with the, we've had a couple of questions from Slack already, but we now have a long list of them. So let's start with Andy's question. Can recipes in Start-A-Kit interact? For example, could recipes include making a new theme or use a Contribute theme as a Start-A-Kit template without adding the Contribute theme to the project's dependencies?



 If our listener's Start-A-Kit is kind of like the new way to create a fresh theme from scratch,



 and it makes a lot of things easier. So will recipes interact with them? - So I had heard of Start-A-Kit before.



 I had to, when Andy asked this question, I had to look up how it works. So with Drupal Core, you already have the themes in your project, so you could just have a script that runs and clones it. But Andy wants to clone a theme that's in the contrib space. So I would need to run a recipe that would get that Contribute theme.



 Then I would need to somehow run the Start-A-Kit script. And I believe the Start-A-Kit script uses that Drupal Core script. So how would we run that?



 Maybe a script in the script section of your Composer.json or another module that would be required to run that script.



 And then I would need another recipe to uninstall the contrib theme



 and remove the module if we needed to have a module. So it is possible in my brand that I would need to run the script. In my brain, I also created a proof of concept issue in the Drupal recipes and distributions initiative issue queue to see if that's possible. - So if a recipe includes a bunch of default configurations, can a theme require a recipe? Or does it have to go the other way around where the recipe has to require the theme?



 - Seems like that could be really useful if it went both ways. - Well, at this point, Drupal recipes doesn't have a home on drupal.org yet. So I think you would-- like a theme or a module needs to require a contrib module that's on drupal.org, right? From coming to the back of just whatever. So at this point, I don't think so. But again, cool proof of concept there.



 - And they're ephemeral. So there's no way to determine if they've been run or not already, right? - Yeah. Yeah, I mean, it would happen on theme installation. I would imagine that you could get a recipe that would come up with it. - But I believe the flip side that a recipe could require theme.



 - Okay.



 - Another question coming in from Matthew on Slack.



 How did Drupal recipes articulate versus symphony recipes? And are they even related? - They are not directly code related.



 Symphony recipes are applied to symphony, and Drupal recipes are applied to Drupal.



 So the structure is different, and what they need to do is different. But the idea is the same, that you have a pre-configured bunch of functionality that you can apply. There was even, nevermind symphony recipes, my good friend Bob Snodgrass from the suburbs of Chicago had a group in Fox Valley that had a project called Drupal recipes. And they were building, yeah, like you'd think in a cookbook, recipes on how to configure this and how to configure that. They were doing it all manually, but really helping out site builders, building out steps to build a piece of functionality. So this idea has been around for a number of years. You know, an out spot, whipped up a bunch of code



 that magically made it happen, and it needed a better, it needed a great name that recipes came to be.



 - We have another question from Slack. James asks, how easy will it be to create my own custom recipes?



 James has a set of modules and stuff on every new site, and so he's looking forward to using a recipe for that instead. - James can do that today.



 I wouldn't pretend that it's easy, it's a little ableistic speak, but the, you know, it is a YAML file.



 We're getting better with our documentation on how to do this.



 There's a few great blog posts, and as I find examples in the community, I post them in the distributions and initiative Slack channel. We have a meeting every two weeks that I point out. Some folks are out there sharing their recipes.



 So, you know, there's nothing like copying and pasting somebody else's great work and tweaking it to make it do what you want to do.



 - Sure, and Matthew has another question. Is there anything that Contribute Maintainers should be doing to prepare for recipes or monitoring to like update, like Martin was talking about with his brother this morning?



 - Yeah, I don't think anything at this time may be aware of the initiative and the possibilities that the tool could do to help people. You know, like, yeah, the quick link kit was a perfect example. You know, I maintain a few modules that are basically configuration only, you know. So those kind of Contribute Maintainers are, it's a great opportunity for those modules to be replaced with recipes to make things a little easier to maintain in the long run for the end user of the site or the end developer of the site.



 - If people are really excited about recipes, how can they get involved or contribute?



 - Why, I believe I mentioned it, but there is a project on drupal.org. It is called, I probably murdered the name a bunch of times, the Distributions and Recipes Initiative.



 So I've seen this before in a couple other initiatives like Olive Arrow and Single Directory Components. The work of the initiative is done in a fork of Drupal. So the project can iterate faster and make as many commits as they want without having to patch it every single time. So, you know, the project is a fork of Drupal 10.1, I think at this point.



 There is a patch that gets created using the Drupal CI. So all you have to do is apply a patch to your Drupal 10 and higher,



 and then you have the recipe runners and everything you need to apply the recipe. So in the code base, there is a plethora of documentation



 in this project, and there is an issue queue where we create issues and feature requests and support requests. There is a Slack channel called Distributions and Recipes in the Drupal Slack, and there is a meeting that happens every two weeks.



 There is an issue in somewhere in Drupal for what's under the infrastructure project. If you search for Drupal issue 326-9687,



 and I'll add that to the project notes,



 there is a meeting thread where you can add your Slack name to the ping list. So every time we start a meeting, you can get pinged if you want to. You don't add here or add channel everybody. We just ping the people that want to be pinged. So that's all there is to it. Jim, you might have mentioned this and maybe I missed it, but is the meeting in person via Zoom or is it via a Slack meeting or how's that run? It is an asynchronous Slack meeting. So it is not in person at this time. It is typed. We collect the issues and then save them to drupal.org at a later date.



 I think we missed one really important question too. I'm just realizing. And that is, how do you create a recipe?



 How do you create a recipe? So there is an amazing blog post by our friend Kevin Quillen. Blog post is on Valir.com and it's called exploring the new Drupal recipes feature. So we plan to turn this into our foundation for our documentation, but this is a step by step on how he created his recipes and applied it to a project. It's a really cool recipe.



 Again, coming from an agency point of view, this is a starter template for their agency's Drupal projects. And he estimated that it saves his agency two to four hours on every new project.



 - Wow.



 Impressive. Well, Jim, thank you for joining us again. It was a pleasure having you on to talk more recipes. I'm really excited about this.



 - Great. Yeah. And I'd love to answer all your listeners' questions in Slack. So keep them coming.



 - Do you have questions or feedback? Reach out to Talking Drupal on X with the handle Talking Drupal or by email with show at TalkingDrupal.com. You can connect with our hosts and other listeners on Drupal Slack in the Talking Drupal channel. - You can promote your Drupal community event on Talking Drupal. Learn more at TalkingDrupal.com slash TD promo. Get the Talking Drupal newsletter to learn more about our guest hosts, show news, upcoming Drupal camps, local meetups, and much more. Sign up for the newsletter at TalkingDrupal.com slash newsletter.



 - And thank you, patrons, for supporting Talking Drupal. Your support is greatly appreciated. You can learn more about becoming a patron at TalkingDrupal.com and choose become a patron.



 Okay. So Jim, if our listeners wanted to get in touch with you, what's the best way for them to do that?



 - Yeah. Say hi if you're on Cape Cod.



 Go out for some japino.



 Ping me in the Drupal Slack is probably the best way, or join the Distributions and Recipes channel and say hi there.



 - Awesome. Jen, how about you? - You can also find me on Drupal Slack, but more often I am on the free open source alternative. So if you want to find me on Zulipchap.



 - John, how about you? - You can find me on all the major social networks, and Drupal.org at John Picozzi. And you can find out more about EPAM at EPAM.com. - And you can find me pretty much everywhere at Nicxvan N-I-C-X-V-A-N.



 - And as always, if you've enjoyed listening, we've enjoyed talking. Have a good one, everyone.