 Senakoto, gandio kailbun, gandio. Thank you, everyone, for being here. Hope you're enjoying your day. I've come from Dunedin, in the south of New Zealand. It's my family in the top right. I'm into data, throwing balls, open web, and film. I'm a developer at Catalyst, where I get to work on a bunch of cool things. maenai Kriss. Maenai Zirizim on Slack. We're going to talk about recipes. So, in caveats, I think recipes are really cool. It's an opportunity to make Drupal reach a much broader group of people with the functionality. It's not finished. It's incomplete so things can change and it's open source so things can change. It's not a complete replacement for profiles yet. And I don't consider myself an expert but I'm excited about it and stoked to see a bunch of people here. I'm going to take a photo. Is that cool? Thank you. Yeah, it's a cool little camera. Okay. So move on. Sorry. Okay. Recipes is a way to apply composable configurations and eventually content to Drupal sites. Drupal's got 20 years of this really long history of success and learning in how we empower creators to reuse functionality across a bunch of different sites with things like distributions, profiles, features, modules. Lots of things. Recipes are a new take on that based on what we've learned so far. They promise less complexity. They promise more importantly less commitment or less significant investment both for sites and for site maintainers. So what came before recipes was lots and especially was profiles. Profiles have been a real cornerstone of distributions to date. They're a great tool and really valuable contribution. Not the only method but one of the big challenges with them has been that they tie the site to the profile and thus the site to the other sites that use that profile. And that creates load for the maintainers of the sites and load for the maintainers of the profiles. And recipes want to revisit that. Profiles can be effective, but yeah. Yes. Okay. Sorry. I'm a good talker. Recipes are a response to that experience of wanting to deliver configuration to sites, without the commitment. So what's a recipe? It's declarative. They say do these things, but they do that without the context of the site. They don't know what the site is like beforehand. So by design a recipe is not informed of that state. They can do several things. They can install modules or themes which means that they have to be able to require modules or themes into the site to kick off. They can apply a module's default configuration or selectively some of that configuration. Or they can apply your configuration. Or they can perform config actions. We'll look at that in a second. Which, yeah, we'll look at that. So you probably know a lot of those features from previous implementations, but what's interesting about recipes is what they don't do. They don't let you land code into sites, except through the modules or themes that you're landing. But it doesn't go in the profile, as it would have before. There's no provision for code in a recipe. It won't respond differently at runtime and it won't respond differently at install time. It's not dynamic there. You can limit the configuration applied. So you can opt into some or all of a module's default configuration state. And the killer feature is that after you're done with using that recipe, it's not part of the site. There's no trace of it, except that the configuration in those modules are in there now. The recipe can be forgotten. So the parts of a recipe are the recipe yaml, which looks like this. And I'll just quickly talk through what we see here. We've got a name at the top that's required. We've got a type. And for a big complex recipe that has lots of functionality, you might choose to use site for that, which means this is a start point for a whole website, like the standard or minimal profiles are. We've got a description. We've got an install key, which is going to install the auto logout module. We've got a config key, under which we can see that we are importing with that star there, import auto logout star, all of auto logout default configuration. And we've got an action at the end, which is one of those config actions I mentioned. So it's going to apply a small config change over the top of the default auto logout configuration. So instead of copying that whole configuration and then changing one line and having maybe a larger yaml file, you've just got the setting that you wanted to change on top of that module's default. So we're using the module defaults as start point, changing the value we want, tidier. We can also provide a directory of configuration, which you can put other configurations into. Oh, I missed a moment. There are other things that can happen with the import. So you can import some of the module's configuration, all of it as we see there, some of it by naming an array of this one, this one or this one, and none. You can also import the optional configuration and you can manually, but not by default, import things that are config entities. So you might be familiar with contact or web form providing a default contact form. Both of them offer a contact form. If you want that in the site, you can add it here, but if you just said to install web form, you wouldn't get those config entities and that's nice if you want a start point that you control more. This is providing a lot more control over what the module's going to do. In the final piece, so then we've got the directory of config that we can provide to override things and we've got a composer, Jason, which allows us to say we want this module that we're going to install. So this kind of is used first, but the recipe yamal is the more core part of what a recipe is. If you're in the web recipes custom folder, you may not even need the composer, Jason. If you don't have dependencies, that's an option, you can leave it out. So that's a single recipe, kept intentionally small. It's the right size for that autologate component and that might be something that you stack into a bigger component which is your preferred security configuration and then you might stack that preferred security configuration alongside a user experience configuration into a bigger recipe that you use. You can reuse these small components in the bigger parts or bigger compositions of it together to make the sort of site that you want to see Drupal start off with. So one of several ways we'll use this is to make the initial configuration of a Drupal site much quicker and easier. It puts the options, currently a choice between things like minimal, standard or a whole distribution, into the hands of the site owner. It's nice to save a few hours of site click, of clicking around the site after install, but having a consistent start point will be a bigger benefit for agencies using this than just saving on set up time, I think. Recipes can also be applied later in the piece, so you could come along by auto log out to a set of sites in operation. You do that in local dev and achieve or bring sites into alignment that are already in operation. There isn't however support for applying a recipe a second time to a site, so you're a little bit on your own there. It'll work in some cases, but you have to consider the configuration. I'm not. Recipes are still in development. You can try it out today. You should start with an installed site. This link here, which is probably tiny, but is available from the distributions and recipes project page as well, gives you your complete set of instructions. Starting with an installed site, you need a core patch, so this may not be appropriate for production sites, but it's possible to do this in local dev and then leave the core patch out of what you're committing to use recipes to apply to a site today. There's composer configuration if you're using the composer parts of it, so if you're requiring in recipes and then unpacking them, there's a second set of this instructions that does the composer site of it, and then you use the Drupal command line tool, which is in core script's Drupal recipe and the path to your recipe, which is probably web custom recipes, something. It will do the configuration for you, or it will fail with an exception and tell you what you need to do next. Well, it'll tell you what went wrong. You'll work out what to do next. Okay, I think recipes does less and allows Drupal to do more together with other new functionality. I think that project browser is going to be a big part of this once recipes are available there too. It'll allow ambitious site builders to discover and build whole lot more with community provided recipes. I think automated updates are also going to be a really big part of that. What excites me or one thing that excites me about this is the possibility for people who the ambitious site builders that we talk about to access using and operating Drupal sites and building with it without the need for composer operation or the low level stuff that's familiar to us as developers but not accessible to the wider pole. I think that persona of the ambitious site builder is something recipes fit so well with and I'm excited to see what this will make possible. Okay, I see it is liberating Drupal sites from how profiles work today when recipes are complete just distributions will still be possible and hopefully cause or we expect cause profiles to become recipes. Sites will have more agency over their configuration from the start point. The freedom and flexibility to try new things along the way and I hope that will make more possible with Drupal. I think it will expand Drupal to a broader pool of users and those folks can be empowered by that flexible composable system to try stuff out which has the potential for the sort of creative explosion that the web makes possible and I hope Drupal can be a foundation for a whole lot more creativity online. I love that vision of Drupal being available to a broader pool of people for creative work. I love the big projects we work on I also enjoy the small playful projects and want to see more of that happening. I hope that creative and personal aspect can lead us to a more human and more engaged web. Recipes are iteration which opens a challenging aspect of Drupal today to more people and more people. I think that's me. That's... Yes, notes and a demo repo where I've been exploring this. Any question? That's the vision is that you'll be able to kick off, you've got a blog it gets successful and you may apply a recipe shop to sell some merch alongside or you may decide that you need to meet a security profile and apply a recipe that does that for you or does some parts of that for you. That's the vision, yes. So my understanding from testing and learning so far is that recipes is probably going to say no, there's an existing configuration. If you try to overwrite an existing configuration, however that simple config update that we saw here if your recipe... I think if your recipe contained nothing but so no install and only config actions this I would expect that to work to apply. I've decided that everyone gets a three hour time out now so I'm going to apply this. That recipe application using the config actions API I haven't tested a recipe that installs nothing. Interesting to try but yeah, I think that should work and definitely have had experience in the past of we need to drop a config update out to a whole bunch of sites. This is potentially a tool for that. You wouldn't apply... oh well I wouldn't today apply recipes in production because of the core patch that's required. But we may see that that becomes a useful part of the toolkit to iterate over a list of remote sites and say do those things. Content is not provided for and you can't really do a distribution very well with it or maybe you could but so default content is not part of core and recipes is in core. It can't depend on a contrib module. I don't know that default content has agreed to be the solution for that but there will need to be some solution. We already have migration core as well and that's another pathway that I can imagine would work. But that's not complete yet. It's a way away. Wait for that. I think that the fact that recipes don't provide code and don't leave you couldn't tell if the site had been manually configured or configured via recipes after the fact. That's the point of difference for me. So when a module provides default configuration it's that module. I've never tried no I do know of so webform for example provides a view as part of its configuration as part of maybe its optional configuration. So you could also land a module that when installed or uses an update to deliver configuration. Recipes would be a different way of doing that and probably what would happen in production is you'd deploy the updated configuration to production and import it. So it's not actually doing that update hook in prod just loading config. Yes, just up the front. Yeah. There is an issue to replace the standard and minimal profiles currently and I believe it's mostly working to reproduce what the standard profile does as a recipe. And then you'll be able to select the recipe you want to use at install time and say I would like standard and it will use recipes to achieve the same thing. That's the goal. What does that mean for an existing profile that would still like to be on that install screen? I don't know this point.