A Taste of the Future: Site Templates and Recipes in Drupal

This talk at DrupalCon Chicago 2026, presented by Jim Birch, focuses on the powerful capabilities of site templates and recipes within the Drupal ecosystem. The speaker explains that recipes are pre-packaged bundles of configuration and content designed to expedite site building. They function as shareable Composer packages that can be applied to Drupal sites, supporting modular development without the baggage associated with traditional modules. Birch delves into the technical nuances of recipe creation, including the application of dependencies, configuration management, and the limitations of recipes compared to modules. He also highlights best practices for recipe design, the importance of standardization, and the integration of tools like Drush for better command-line interaction. With an eye toward the future, Birch discusses upcoming developments, including enhancements to the recipe ecosystem and the potential for AI integration.

Welcome to day three of DrupalCon Chicago 2026. My name is Jim Birch. I'm a director of build engineering at Canopy Studios recipes core subsystem maintainer. I guess recipes into full content Drupal CMS committer. Today we're going to review site templates and recipes in Drupal. First we're going to go through a quick refresher on what recipes are, how to use recipes, the general ecosystem today, what's changed since

the last time I met you all in Atlanta last year. We're going to talk about recipe creation and tooling and then what's next on our road map. So let's go through the essentials. Drupal recipes are pre-packaged bundle of configuration and content. They accelerate site building. They are applied to Drupal not installed. This is the main difference between modules and recipes. They are a shareable composer package. They

are predictable. Once you apply a recipe, it should do exactly what you expect it to do and they are removable. So your Drupal site doesn't know they exist once they're applied. They can be easily removed with our composer recipe unpack composer package. It can actually never be a part of the it has the possibility of never being a part of the composer the site at all. What

recipe does do? So this is an important step in applying each recipe. The first thing they do is apply other recipes. So you can be dependent on recipes. This is a great best practice to use cores recipes or other recipes that exist. Drupal CMS has broken their recipes into appliable packages. So the admin UI has been really tested by the Drupal UX team. Uh, it's a great

admin experience. So any recipe or site template I start, I use the Drupal CMS admin recipe first. So that gets all the dependencies and uh, module it needs, any config and content that is applied to the site first and then moves on to the install section. So then the recipe API applies installs modules and themes that you uh, have in your recipe. Uh, after that it imports

config from various places. So you can specify of those modules you just installed, which specific configuration you want to or or and or your config folder in your recipe. So your recipe can include config that you have. There's a difference between simple config and config entities. So simple config are metatag.settings or pathauto-settings. These are always imported because they're needed for the module to work. Configuration entities, so

think metatag bundle dot article that you have to specify you want to because you might not have the article content type in your recipe. So, it's a great separation of what's needed for the module to work, uh but also the configuration entities you have complete control of sculpting what that site has. so, this is different from the way modules work. When you install a module, and you

install the metatag module, you're going to get all five config entities no matter what cuz they're in the config install folder. But, when you apply uh recipes, uh the recipe author has that complete control. So, after that, it runs config actions. So, config actions is another API we got to add it to Drupal core, and this is kind of the the secret sauce of recipes. So, this

is where you can alter configuration that one exists in Drupal already. So, you can actually config, like uh what's the home page, or who's the site admin, the name of the site. Um And you can also do it on config that you just installed from a module. So, you want to change those metatag settings that we imported, uh you can do that. And even your config folder.

So, like you had a config folder uh that you installed, and you you want to keep it basic, but in this recipe, you want to alter it a little, you can do that. And then finally, what Once all the site building is done, and everything is configured the way you need to, you can import content. Um so, we modeled uh the core default content API off of

the default content module module that's been in the community for years. you can uh import content entities, uh and you can also now export content entities using Drupal core. Uh it'll get all the dependencies. It'll actually, you know, if you reference a media that references a file, exporting the content will actually include, you know, the JPEG that you had on the media, which was on the article

that you exported. It's pretty cool. What recipes can't do, they can't contain any code or make any logical decisions. We want recipes to be determinative. You know, we want it to know what it's going to do. It's not a choose your own adventure uh kind of thing. Uh then that gets us into logic and you're back into module and that leads us down a road of past

missteps. They can't contain any other recipes. Or uh we don't want you to have nested recipes. Every recipe should be a first-class citizen. It should be its own composer package. Uh there are folks that have uh ignored this and done their own thing, but like on the drupal.org setup, um we want to get away from the Drupalism of modules can have submodules. Uh you know, every recipe

should have a stand-alone instance uh that could be required from other places. Cuz you're breaking it up into different recipes, you know, other recipes in the ecosystem should be able to use those recipes also. Um there are development techniques. Uh Drupal CMS is one of them where you have a monolith repo and at uh certain point when uh releases are tagged, they get sent out to their

own uh packages. Uh which is a a nice way to ease development pain if you so want to go that way. Recipes can't be updated. So, once they're applied to a site, uh the site owns them. They're ephemeral. They they're gone with the wind. Uh so if you want to make changes to the recipe, uh what we do in Drupal CMS is we publish a change record

um with simple steps of if you want to change what we change, click these three things in the UI and click save and you've done it. Um there are module there's a module called recipe tracker uh which is in contrib which actually tracks uh what recipes have been applied to your site because some folks felt they need that, but with Drupal core, you know, we we don't

want to know. Drupal shouldn't know what kind of recipe you've applied. And we made the decision pretty early on that you recipes can't delete any config or uninstall any extensions. Um so you can unset them uh you know, like with views, a really common thing to do is unset the files view that comes, you know, with the standard media profile uh standard media profile or recipe. Um

but we don't want recipes to be able to completely bork a site. Um so we made that decision. Uh of course, you could write your own config action that could do these things, but uh core never will. So I talked about, you know, the steps that the the recipe uh goes through when it gets applied. Um but this is the underlying technology. So there are four pillars

in core. Uh first is the config checkpoint. Uh so the config checkpoint API takes a snapshot of the configuration before a recipe is applied. that it basically creates a known state that it could revert to if the recipe fails. we got this in core. There hasn't been much done with it. There's a contrib module from Bircher, I believe, that it it starts play around with, you know,

giving you a UI, maybe you can look at and and click back to revert to a place. But it's kind of like a uncharted exploration there. It works for recipe but definitely cool things could be built upon it. The recipe API is the conductor. It it reads recipes, it resolves dependencies, it can collect user input, and is basically the orchestrator of the the whole sequence here. Then

the recipe API calls the config API. And that changes the config. The config action API can actually be called from anywhere. So because it's a standalone API, your custom module could call ECA can call config actions. So that's a pretty great tool where, you know, once you have this thing, you can set up workflows that could apply config as you need them. And then finally, default content.

It allows recipes to ship content as YAML files and import them on recipe application. So let's talk about using recipes. If you're starting with Drupal core's composer template examples, this is already configured for you. Also Drupal CMS. Also Drupal CMS. Which is great to start with, also. If you're adding recipes to an existing project, all you need to do is put this in your installer paths where

you want to keep your recipes. So recipes are a composer type. We've registered that with composer, so all recipes have the Drupal {dash} type in their composer.json. And we recommend that you keep your recipes above your web root. So, you know, sibling to your config folder because recipes are not a part of Drupal, you know, they should be kept outside of Drupal. Um so, this is the

recommended path. If you choose to keep it elsewhere, you know, you can so change that file. requiring and applying recipes uh works just like a module. Um composer is the best way to make sure you get all your dependencies. So, co- composer require uh drupal/recipe name. Drupal core has a PHP script uh called Drupal uh that there's a few scripts right now uh that uh take advantage

of it. And one of that is recipes. So, we have a recipe command uh and I believe the default content uh command is also in there. Um but basically, you can use the script apply the recipe. Um I notice I CD'd into like PHP core scripts Drupal. You have to tell it where the script is uh to actually apply the recipe. Much easier uh in Drush 13.

We got all these uh commands added to Drush, which is just a a wrapper around the core command. Um so, you can say just Drush recipe. Drush always runs from the web root. So, you want to back out dot dot, you know, back to the web root, and then apply the recipe name. Uh you can apply recipes using project browser. Uh so, especially if you install Drupal

CMS, Drupal CMS comes with a uh project browser module has different project browsers. So, you can have one for contrib modules, and you can have one for core modules and and themes. And uh you know, we added one in Drupal CMS for uh approved recipes. Uh I believe there's also talk of uh core contributed recipes now that we have recipes on drupal.org also. So, that is opening

up in project browser, selecting your recipe, and clicking It says install incorrectly, but you'll know that it applies it. For creating recipes, uh best practices are to extend core recipes. So, one of the things is media. You know, the the recipe in core was built on the standard profile. It gives you, you know, the media entities and the fields and the appropriate configuration you need. Um why

bother recreating that? Um so, we'd like to extend I use core's uh text editors uh and filter formats, you know, get you uh some nice consistency out of the gate. Uh so, one of the things, especially with Drupal CMS, I wanted with the admin UI recipe is, you know, we're starting to give our users of Drupal a consistent behavior and a consistent consistent admin. Um so, the

more you can use, you know, what core and Drupal CMS offer, we can offer a a better admin experience for for I like to make small recipes and build them up together. So, this is really good in the recipes. Uh at Canopy, uh we've, you know, started out with uh a big suite of uh our site builder, and then we broke it up into individual recipes. So,

we can add uh event content type onto a site, and it has a content type of view, you know, every taxonomy, everything you need to just make the small feature. And for, you know, those of us who are older, we can remember features in Drupal 7. You know, this is kind of like the uh uh application of that without the baggage that you have to maintain that

for the rest of the life and change things and worry about breaking your client site. You know, so you're applying that event and then you can customize it as you go. Um one uh terrible process was uh you need to remove the UUID and core keys um from your config files. So, the UUID and core keys, you know, make it unique to a site. Uh we want

to have it abstract so it can be applied to any site. Uh you know, I've come up with bash scripts that do this. Uh in the Drupal CMS helper module, uh there's actually uh a helper that uh flag that you can add that uh just removes it as you export config, which is great. rather than adding another burden to the Drupal Association uh maintainers of drupal.org, like

we didn't create another content type for uh recipes on drupal.org. Uh instead, uh you create a general project on and they're smart enough they can parse if you could create a composer.json and have it as a Drupal recipe, they know it's a recipe and it'll get in all the views and everything that they need to do. Um so, once you're ready to publish create a a general

project on drupal.org, you know, upload your code and you should be good to go. Um unlike a module, because it's a general project and it doesn't get packaged, uh just a small note, you want to include a license file with it. Uh when you publish a module, uh the package is the packager of the module actually adds Drupal's license. Uh in this instance, it doesn't cuz there's

no packaging. Uh so, just include a license in your file. So, let's look at the ecosystem and why recipes matter. efficiency. So, you can build and rebuild faster with reusable pieces instead of requiring a module, enabling a module, opening up the UI, and finding the configuration screen, creating a new bundle, a new content type, configuring it all, you could uh with a click of a button have

all that functionality. Uh standardization, applying consistent recipes across projects, uh whether you work at an agency, uh a business, or a university, um we all have the pain of maintaining different solutions on different sites that do the exact same thing. Like, I'm looking at you carousels and mega menus and, you know, all that kind of thing. standardizing on recipes allows for like a consistent starting point. Uh

scalability. Uh so, if you start from that standardized space, uh you have easier onboarding, uh documentation, and training, uh and replication across teams. Um when there's an approved defined approach on how your organization does things, you can onboard faster, you can train junior devs easier, uh and you can create testing solutions and implementations for quality and and And empowerment. Uh so, non-developers and junior developers can apply

complex features, you know, through a UI, you know, through project browser or through the command line. Um you know, using Drupal CMS, you know, we have a really fast Drupal installation where end users can install a blog, uh install the AI tools, uh which you get so much functionality out of the box with that recipe. Um the event system, uh one of the earliest uh recipes uh

that Martin made was, you know, so amazing with a like a beautiful Drupal view, and you know, you can add on you know, uh recurring dates, you know, the location had a map that uses an open source API solution and you know, that was one of the earliest recipes that that we created and and put out on drupal.org. You know, and like you know, 20 years of

experience in in one click you get. So, really great empowerment for for Drupal users. Um so, we've been talking a lot about recipes uh and then this sir Do the recipes deal with the with the design? Cuz it sounds like the theme is disconnected from all of this. Correct. >> something but it looks like blah till you actually go in. Which is a great question to parlay

into this next section. So, yes, recipes Uh recipes uh do not have any theming uh capabilities to themselves. So, when you are applying a recipe, you are applying uh and content and dependencies. So, one of the dependencies could be a theme. Um but it needs to exist in that theme. Uh you could also include a custom module or module you publish on the web um that would

need you know, something if you needed theming for your Canvas will make this all easier moving forward to. So, recipes uh you know, does all the things we just talked about. Imports modules, configuration, config actions, uh content um and they're composable, you know, range from a single feature, you know, those ingredients or snacks up to full meals or you know, our site starters. Site templates, we recommend

that site templates have your recipe, but also include a Canvas theme and a curated demo content. Um, so we actually recommended to all of our site template builders uh in the initial marketplace push, like don't include Laura Ipsum. Include real content, you know, for your your target demographic. Um, that will really show them, you know, what this site template can do and how they could use it

uh to be there. Canvas um uses a theme uh but uses uh can use single directory components. Um, so those are kept in code and configured in config. Uh, but the future of theming in Canvas is code components. So, in the UI, you can actually build components. So, you can build your pricing table or your carousel uh using Tailwind CSS and Preact, and that's all saved in

configuration. So, you definitely necessarily wouldn't need to have a single directory component. You wouldn't need a Twig file and a JavaScript file and a CSS. You could have that all in your config So, that will be the evolution once people adopt code components more um that you you might not need a theme in your Drupal site at all. Um, so we want site templates to be a

complete starting point and you know, there are generic ones, but right now we're pushing for specific verticals or use cases. I think that's going to help us build the marketplace and you know, extend our reach uh beyond uh what we normally do. Um, we we you know, to be included in the Drupal CMS marketplace, um we must meet base baseline standards, accessibility, uh, security, and documentation. Uh,

and they are reviewed right now, uh, by the Drupal CMS leadership team, uh, before they could be listed in the marketplace. Where we can find recipes? Uh, you can find them on drupal.org. Uh, so there is a new.drupal.org/browse/recipes. This is a view that lists all of the recipes in alphabetical uh, so we'll talk about that a little bit later, but we don't have telemetry on which recipes

are the most popular like we do in modules and themes. Um, so right now they're listed in alphabetical order because because. Um, in project browser. So like I mentioned earlier, uh, Drupal CMS ships with a browser where you can uh, select, you know, the pre-approved and then you could also make your own browser. Uh, so for organizations like businesses or higher education, you could actually create a

curated list of recipes that your users could apply. Site templates. As of yesterday, there is marketplace.drupal.org. Uh, so you can browse that and uh, find the 12 uh, recipes. Uh, three of them are in Drupal CMS. Uh, so Haven, Blank, and Bite. And the rest were contributed by Drupal agencies like us. in the olden days, we'd go scouring on GitHub and GitLab and search for composer type

Drupal recipe. So there's still some gems out there in the universe. Uh, same for Packagist. Uh, so you can search Packagist for that composer type. Um, and other people make their avail recipes available on Packagist so you got to add that repository instead of just having the drupal.org repository. And uh Drupal CMS installer. So, Drupal CMS installer allows you to create a curated list of res- uh

site templates uh that would ha- appear at the start of your installation. So, if you customize sites/default/site_templates.php, Um I just want to say one thing. This is all really new and really half together, like literally 2 weekends ago. And it's all documented. So, if you want to use this, talk to me. So, this is just a secret experience for those of us who attended this event today.

yes, we are flying this plane while we built it. Um so, this is a great way if your your organization wanted to, you know, have the ability to have users spin up their own site, you could give them a pre-configured list of site templates. So, your department, your professor, your lab, you know, you could get them jump-started with these installers uh site templates. All right. So, what's

new since DrupalCon Atlanta? And this happened in Drupal 11.3, we added content export to core. Um so, now the content export command uh was added to help with recipe development. Again, uh there is a Drush command for this, but you can basically do content export, uh and there's a variety of things you can do. You can say uh which bundle. So, give me all of the article

uh on the site, export them all. You can do uh which node. I want to export node 42. Uh, you can throw the width dependencies flag, so that would get you everything, or you could export things one by one as you need them. Uh, and then you can give it a directory of where you want the content to end. So, this is, uh, extremely similar to what

the default content can trade module gave us. Um, we just added the ability to core. Uh, besides that, there hasn't been much. Uh, there's some small changes to config, like you can add a question mark in front of the config to make it, uh, optional in config action, so it won't break if the config doesn't exist. Um, there's been some bug improvements, um, but once we got

it into core, uh, our fearless leader, Alex Pott, went uh, Alex potting all over core, the you know, the whole ecosystem. Uh, Adam got sucked into byte and canvas and Drupal CMS, anywhere where that touched. Um, so we don't have a lot of, momentum on development on making, uh, recipes, uh, into our phase two and our phase three. but let's talk about that. A lot of folks

are saying, "We want to make recipes generation easier. So, let's skip that phase two. We don't need to fix all those bugs and everything. Let's get to phase three where we're going to make some tools." Um, so one of the things that came out of Drupal CMS was Drupal CMS helper. Um, so because, uh, you know, core moves at, uh, a pace that core moves, there's only

so many core maintainers, it's it's hard to get things in and and, you know, balance their, you know, work-life balance and their work contrib life balance. Um, Adam has put a lot of, uh, custom, uh, work uh, and helpers into Drupal CMS despite the name, this can be used on any site. Again, it's a standalone package uh, that you can it's a module that you can install

in your site and it gives you a bunch of tools. Many undocumented, which will help Adam out with here. Um, the most important, I think, is Drush site export. So, this is a real game changer in recipe or I would say real game changer in site template So, now you can build your whole site the way you want it. Site build it on a sandbox or in

Ddev and do Drush site export and you have a recipe that is exactly the same as your site you built out. And then your development changes. So, then you have this recipe, you do Drush SQL drop a lot and you can just spin up this recipe over and over and over again, reiterate, make changes, make improvements, remove things, and then do site export again and you're getting

that recipe set up. So, it really eases the development of choosing which configs and and which content pieces and and what you need on your site. You don't want to worry about maintaining that maintaining that development site and having it in a pristine shape that matches the recipe. Um, so really cool tool and there are a bunch of other helpers that are in that module, also. That's

a contrib module. That's a contrib module, yeah. Uh, all of these are going to be contrib modules, yeah, or or packages of some sort or another. I haven't played with this, but in the fall, uh, nice gentleman created a wizard uh, with a module that allows you to export uh, certain things from your site that you've built on. Um, so it it goes through and it gives

you like a kind of a step-by-step wizard of what you're you're doing. Uh, so they released it. Uh, it has like 17 uses. It has a big warning at the top that it's under development, but definitely cool to check out. Our friends at TripYard published a module yesterday or day before. I don't No data on there. Very similar thing. This gives you a just command where you

can really dial in what you want to export for your recipe. So this is not a site template tool necessarily, but more if you want to sculpt your recipe into, you know, smaller bite-size recipes. Ooh, didn't change the image. There is a VS code extension that a gentleman from Acquia made that helps you with auto complete. So if you're writing your own recipe, you know, it'll help

you along. Again, it hasn't been updated in a year or two, so it doesn't have everything, but it'll, you know, help you get there, you know, 70% of the way. So let's go to practical authoring and organizational strategies. Still doing pretty good on time, I think. I kind of already mentioned this before in creating recipes. Site templates, monoliths we're calling them, and that's everything all at once.

The site export command makes a recipe that really hurts my heart. It's It's very robust about It exports everything. So it doesn't matter that you have, you know, core has this exact same config, but it really helps with development. So this is where we are for now. Again, create genuine content. uh you know uh I used I created a Canon uh the healthcare site template uh where

I created an island off of the East Coast where we have a hospital network. Uh I created an agent and the skills and I said, "Help me write this content. Tell me about the doctors. Tell me about the locations." Um so we had some fun with LLM and got really creative to create the content I needed for my site template. So, you got a good creative team

and copywriter, you know, that's great. If not, that's one of the things that AI's pretty good at, writing so many words. Um export uh draft site export and then review and revise. And it's great to have other folks apply your recipe, give you feedback, you know, definitely step through all the content entities. This is definitely different than Drupal development because you're creating the content for the site,

too. Um so one of the things we did with the healthcare template was we reviewed all the necessary pages uh for like a hospital would need for their website. So, you know, they definitely have to have a privacy policy and an accessibility statement. But they also have a have to have an open pricing uh transparency. So all all hospitals need to have a price list. Um so

we created that outline of content for them uh to use and customize once they apply the site. So it's not all just throwaway content, you know, it there you definitely could have real content at the end. Um so I want to show you some simple uh recipe examples here. And let me see if I can pop up pop. this is the general structure of a recipe. You

have to have a recipe.yaml. That's the only requirement. Uh so recipe.yaml in a folder, uh it assume assumes the recipe assumes the name of the folder. Um for fun and drupal.org findability, include a logo uh SVG PNG. Uh composer.json for uh depend dependencies. Uh and then readme license I mentioned. The content uh in this instance, we added a taxonomy type. Um so in in the content folder

there are four content types. So, we added a event type uh event category and we gave it uh four different types to to kickstart the event. Uh configuration. So, in this instance, I am adding a bunch of fields uh Martin's event recipe. Um so, I found the event recipe a great base, um but I wanted to add some more fields that uh Google looks for uh in

structured data. So, I added the field storage, I added a meta tag, I added the that taxonomy. that's great. It all gets created, but how do we put it all together on the site? And that's where the recipe.yml comes in. Uh the anatomy of this recipe is it has a name, a description, and a type. These are the recipes uh that it applies first. So, it gets

core content editor role cuz I want content editors to be able to uh edit these events in addition the site administrator role. Um I require uh the events, the events calendar, and the events locations. And then I uh require another couple uh fields recipes. I go through and I install the modules I I mentioned this earlier, but here's config strict. So, config strict, I want to contreat

uh treat these configuration files by themselves strictly. So, if field called SA cost on a site, it must match exactly. I do this on the field storage and we did this in core because define what's in the database. So you could have a text field called field underscore image on your site. It'd be pretty rare, but if you had that that would blow up my recipe. So

we want to treat these configly strictly and then same for that taxonomy vocabulary. We want to make sure that is exactly how we need it. And then we use config actions. We've imported the field storage. We've imported the taxonomy and everything from the events recipes we need. And then I want to use config actions to set the fields on the event form. So this is uses field

group and you know, grabs the name of the field. Gives it the type like everything that you would do on the event form clicking everything together dragging things exactly where you want to be. I do that using config actions. We'll go down. I'm adding a lot of fields 12, 16. Add that move it into tabs with the set third-party settings config. Which basically this is the same

uh thing that you would see in your config file if you had configured field group yourself. at the end I remove fields we don't use using hide components. Again, we're not deleting things, but we're hiding them so that drags it off of the list. Um we do this again for the location content type. Hide some components. Uh we configure the address field exactly the way we want

it. So the address field in Drupal is very complex. Uh we set permissions. So basically we say create create the anonymous role if it doesn't exist, and then grant permissions, allow them to see the node event node if the access unpublished modules. We use a module called access unpublished, which allows admins to say, "You have 2 days to look at this unpublished module." It's great tool for

sending things to your boss to check out, or your client. And then down here again, uh for the content editor role, it creates it if it doesn't exist, and then it grants uh that we need for them to use it. So, this recipe allows us to grab you know, existing awesome event recipes, add our customizations to it, configure it all uh with one click, and then it's

part of the site. So, then the developer can start customizing the way it needs it. Another great use case is uh in the Drupal CMS SEO tools recipe. we add some fields here. Get rid of Get that. We use wild cards. So, I You see, ensure all instances of field SEO image reference image media. So, you can do field {dot} field {dot} node, and then the star

is where the content type is. So, in config actions, you can basically add a field that you want, and then say, "I'm going to add this field to every content type that exists on the site." So, this happens at the time of application. So, if you have six content types, you know, these SEO fields get added to all of the six content types. Um, I mentioned ECA

earlier. We actually leave behind an ECA in this recipe that does the same thing to all future content types. So, there's a action that says if you or an event that says if you create a new content type, take the action of applying these config actions to that content type. So, it's a really cool way to say like I want this consistency. I want a taxonomy uh

term on every content type and if somebody adds a content type in the that ECA would go and make sure that those fields get added you can also collect input. Uh we do things like uh ask for API keys. So, like when you're setting up the Drupal CMS AI recipe, it'll ask you which you know what your API key or Google Analytics or Google Tag Manager, what's

your tag. Um it's uh there's a way for it to appear to appear in project browser uh or on the command line or both which is a pretty cool thing. We just want to use this for simple attributes. Uh you can ask for environment variables. Um what we don't want to have it do is you know choose your own adventure. Um but you know take it as

you may. So, what's next? What's the road ahead? Uh we have a phase two road map uh and it is hopefully out of date. Uh you know because we got it into core and everybody went everywhere. Um we need to take an honest look at you know what is there and what is needed and what needs to be prioritized and probably rebuild that all. Um so, I'll

probably work be working on that in the contribute room tomorrow uh to do some triage on the backlog if anybody wants to help out. Our biggest open challenge is translations. Uh so after a recipe is applied, again, there's no trace uh that a value came from a recipe. Um the config system can't know the string was supposed to be translatable. Uh that means that config action strings

must be translated at application time. Uh which we're totally not set up to do. Um so there's there's no opportunity to do it afterwards except from manually. Um there's we've broken into three distinct problems, and these are like hardcore problems. Um we need to translate recipe metadata strings, labels, descriptions, you know, it's just they're not available to be translated. Uh config shipped with recipes config files in

the recipe package um should already be translatable by config translation, but the strings, again, aren't extracted uh because they're not parsed. And then config action values, um so like translation in config actions, you know, hasn't even been dug into. Um if a config action sets a menu item title or a views display label, it saves it as is in the language that you've been applying it in.

Um and there's no translation uh no mechanism to translate it afterwards um because we don't know where that translation came from. So there's any translations experts in the room, you know, we'd love help and support there. Uh next up is recipe preconditions. Um so sometimes you apply a recipe and it just fails, and it's pretty ugly when it fails. It tries to back it out to the

nearest checkpoint, but sometimes it can't get back uh to that because of Um so we have we actually have two different issues on this that probably need to be consolidated cuz there's, you know, two different approaches. But we want to find a way for recipes to check if they can be applied. So it's called preconditions in other languages. So um you know, we definitely need help there

uh if anybody's interested. we have a big issue that Drupal Association would love us to figure out how to tackle is that tracking for drupal.org issues. Um you know, because we don't know what recipes are applied and and required. Um there's no way to gain popularity and check things out. I'm you know, not a crazy developer, but I like to document things. Um so we have uh

two big issues here. I have the distribution and recipes uh project still where I maintain recipes documentation. would love help iterating and improving. Especially if there's any uh newcomers and you're looking and following documentation and it doesn't make sense, you know, I'd love to hear from you. Um we have a more technical one where we'd like to expand the config action and action method attributes to support

structured documentation metadata. Um so I I I saw Drush does this. Basically they have you know, comments you know, in their code that gets parsed uh for their documentation. So we can really expand upon this and help discoverability of uh documentation. Uh it would be really great. That will help us as contrib adds more config actions and core adds more config actions. So right now config actions

are like added to the editor module in core when we need to touch CKEditor or they're added to the block module in core. So it's not always obvious to the recipes team that there are new config actions. Um but if we could like parse the code base and pull out all the documentation, uh that would be really helpful. Uh so, yeah, we'd love your support in the

recipes initiative. Uh we have a recipes channel of in our Drupal in the Drupal Slack. Um you know, Adam and I are kind of like hyper-vigilant if anybody needs support, you know, we're always there. Um we have twice a month asynchronous meetings in that Drupal Slack um where we kind of post issues we need to work on. People can come and ask questions. Um we have the

phase two roadmap issue. Um we add uh tags to issues because now, you know, in core and in contrib, everywhere we go, um we try to add the recipes initiative tag and the config actions tag to issues when we can, so you can follow the tags and look for issues. And then we have documentation on that project page. Uh so, key takeaways, if anything, uh recipes are

game-changer for productivity, consistency, and usability. Um site templates we hope will increase the use and creation of Uh you know, now is the time to start creating, curating, and applying recipes in your projects and your teams. Um and new features and improvements will only happen uh if we can get more developers interested in contributing to the So, thank you. I know we're at time, but I'd be

more than happy to take any questions from anybody. Are people using config actions in update hooks? update hooks? I would say you definitely can. Mhm? Sure. I mean, like you can call config actions, you know, using PHP, so whatever you're doing in an update hook, use config actions, but there's kind of no point. Um you got to see if you're writing PHP, you might as well just

call the functions directly. CD action class, okay. So, since you're writing PHP, you it it be better just to reach the function instead of doing the config action which reaches the function. Yeah, you showed an example where you're orchestrating the actual content of the page. It makes me think about I have a lot of editors who are building something very big and complex on the dev site

and then they've got to just go replicate that by hand on the production site. I include images. Is there an opportunity there to use this tool? Like you can export the page as a recipe and then import it on prod? Great question. The question is we have developer or we have content editors creating content on uh dev sites or staging sites, you know, is it possible to

use recipes to push that content to a production site? And we love this question because like definitely not. Uh So, uh in a perfect world like that would work, but there are a lot of dragons in the default content system. Um you know, you you don't know the node IDs of uh what you're doing. So, like if you have a reference on your page to a taxonomy

term here, it might not be the same on your site. So, uh we recommend the work uh workbench? No, it's not workbench. Workspaces. Workspaces. So, in Drupal core there is a workspaces module that has really reached uh a good point where you can create a workspace on your site. So, I mean you'd be on your production site and you create that workspace and then once that workspace

is ready to publish, you can just publish it and it'll all automatically be be there. So, you don't need to worry about the dev staging site. You can do that all on your production site. I have thoughts for you, too. Yes, sir. So, there's been a notable lack of AI content in this talk and so I'm going to have like withdrawal. I'm going to ask an AI

question. Sure. The um the chatbot that's built into Drupal, you know, core AI can do things like alter the content model. But it always like it seems like it's trying to sort of invent it on the fly, whereas I feel like recipes are sort of like a known good approach to a particular problem. Has there been any discussion about creating like a skill or a tool or

something like that so that those can start with a recipe and maybe even suggest that to the user as opposed to trying to invent things from scratch? have you discussed creating tools to help AI use recipes to make content? Yes, we had some discussions last year with with Marcus and Jamie about being able to store recipes in config rather than the files that they exist in Um

but I think that would be an AI hill to climb rather than the recipes initiative. And we would definitely support them in their efforts, but with our limited time Yeah. We I AI Yeah. Joe. you might have already covered this. Sorry if you did, but uh Like that one there. Recipes and default APIs that are in core, what's like the status of those? Are they still considered

internal or experimental? Correct. Yeah, they are the APIs that we've added to Drupal core are internal experimental. Technically yes, but realistically we're not breaking backwards compatibility. I I personally think they should just be called stable whatever. Don't worry about Yeah, so far you know, since we got them in in 10.3 we haven't broken anything. That's me knocking on wood. Regarding the functionality of exporting kind of an

entire site, you would it be is it either on the road map or even possible now to kind of curate, like only export a subset of the site? Uh so it could be used as a tool to generate sites. So yeah, so this the site export commands that comes with uh the question was can we curate what gets exported from the site? Uh the site export command

from Drupal CMS Helper is just your monolith. It's one and done. But those other contrib modules, rather 2E and and Drupalyard's new module, helps you select what entities and and what what things you want to push out. Yeah. Or, you know, like what we used to do in the olden days was do a drush CEX and then start picking and choosing. >> Yeah. Yeah, yeah. I mean

uh I guess there's all there's other worse ways to go about that. I can associate with that. Yeah, yeah. One more in the back? Did you say you're going to be available tomorrow to discuss this? I'm here Yeah, I'm here till 11:40