Closed (fixed)
Project:
Drupal.org infrastructure
Component:
Meeting
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
28 Jan 2025 at 22:14 UTC
Updated:
12 Feb 2025 at 16:49 UTC
Jump to comment: Most recent
0️⃣ Who is here today? Comment in the thread below with your drupal.org username to introduce yourself and why you are here.
| thejimbirch | Hi, thejimbirch on Drupal.org Recipes co-maintainer |
| alexpott | Hola, alexpott recipes co-maintainer |
| leslieg | Hi Leslie from project browser |
| Emily Kodner | Hi - emoleee - interested in Recipes, generally |
| robert-arias | Hi! robertarias - working on recipe unpack plugin. |
| bryan | b_sharpe on d.o, here for the free snacks |
| Nick Dickinson-Wilde | Heyo, NickDickinsonWilde. Starting to aggressively use recipes in my own personal work in preperation to pushing my work to recipes. |
| jerdavis | Hey there, jerdavis - starting to dig into recipes for our work |
| Carson Oldson | Carson here! A little late to the party, but helping review 8️⃣ |
| mandclu | Martin (mandclu), Events Recipe track lead for Drupal CMS |
| ltrain | Hi! ltrain here :wave::skin-tone-3: keeping on top of what’s new and looking for ways to contribute if possible |
| guptahemant | guptahemant from india, Syncing through latest updates |
1️⃣ Post here to ask a question or propose a topic/thread. Or go ahead and grab the next number and add it yourself!
| thejimbirch | ... |
2️⃣ Looking to contrib? Here are some hottt links!
Recipes Initiative Tag - RTBC
Recipes Initiative Tag - Needs Review
Recipes Project - Needs Review
3️⃣ @phenaproxima and I presented together, and @mandclu also presented recipe sessions at New England Drupal Camp last weekend. Slides in the thread.
| thejimbirch | Recipes: Welcome to Chef Schoolhttps://docs.google.com/presentation/d/1rmCY_-n6R6p3TDLv_CgkI-b_tG0NKLye... |
| alexpott | How did it go? |
| thejimbirch | Quite well. Great questions from full rooms in both sessions. |
| phenaproxima | I told people not to use recipes for content deployment or config updates, lest they void their warranties |
| leslieg | Both sessions were excellent and well attended. |
| Nick Dickinson-Wilde | wait! there are warranties? |
| phenaproxima | “phenaproxima does tech support” is the warranty =P |
| guptahemant | Slides look a great resource to get understanding of recipes. |
| guptahemant | I told people not to use recipes for content deployment or config updates, lest they void their warranties@phenaproxima Any specific reason as to why not to use it, i think recipes could be a great way to handle complex config update scenarios, like maybe migrating a field from one type to another |
| phenaproxima | @guptahemant They’re not designed for it. If you can get it to work for your use case, more power to you, but it’s not something we are going to explicitly support, so if you use recipes for that, you’re on your own! |
| phenaproxima | And migrating from one field type toanother…why the hell would you use recipes for that? The core migration system is designed to handle that sort of thing. Use that instead. |
| phenaproxima | This has been my friendly warning to not be tempted to abuse recipes, which will likely make your life harder and not easier :sunglasses: |
| guptahemant | yes core migration system is the way to go for migrating data, it is more about creating new field types and instances using post-update hook, instead of writing full php code to do the same, i have been thinking of a framework for using recipes along side drupal’s core config management workflow, basically IMO recipes is much better to use as replacement for https://www.drupal.org/project/update_helper (edited) |
| abhisekmazumdar | Thanks for sharing the session; it was really helpful for me. I'm using some of its content for my session in Singapore. I hope that's fine. |
| thejimbirch | Of course! |
4️⃣ :tada: New Config Actions :tada:
| thejimbirch | Allow recipes to enable Layout Builder via config action #3486981: Allow recipes to enable Layout Builder via config actions |
| thejimbirch | Lots of work happening in the Search API issue queue!https://www.drupal.org/project/issues/search/search_api?text=&assigned=&... |
5️⃣ Documentation updates.
| thejimbirch | Added lots of updates to config actions, documented strict and collecting input.https://www.drupal.org/project/issues/distributions_recipes?text=&status... |
6️⃣ :rotating_light: Config Actions issues that need review :rotating_light:
| thejimbirch | simpleConfigAdd - Add a config action to add to an array of configuration #3305859: Add config actions for views |
| phenaproxima | That simpleConfigAdd …I don’t like it as written |
| phenaproxima | I think we could do a little better |
| phenaproxima | We don’t want to have to add new config actions if, say, the need to prepend (or splice) comes up later. |
| phenaproxima | I also have some issues with the way the views one is written |
| phenaproxima | Although I do think that’s about the best we’ll be able to do, I don’t like that it’s three very similar config actions as separate classes with a base class. |
| thejimbirch | Great idea. Changed it to NR. |
| thejimbirch | Add config actions for views is up next #3305859: Add config actions for views |
7️⃣ :stop: One of our most important tasks: Dependencies should be 'unpacked' to the root composer.json :stop:
| thejimbirch | https://www.drupal.org/project/distributions_recipes/issues/3355485 |
| thejimbirch | @robert-arias I see that you have replied to comments and made some changes. Is this ready for re-review yet? |
| robert-arias | It is, yes! I'm still working on adding more tests, but it can be reviewed again! (edited) |
| robert-arias | But it's mostly done, I believe. Just need someone to review it! |
| thejimbirch | FYI @alexpott @phenaproxima |
| phenaproxima | :eyes: |
| phenaproxima | If I remember correctly, most of my requests last time were for descoping 🙂 |
| robert-arias | They were! At least for the patches functionality. That was removed and I referenced what I had done in the other issue. |
| phenaproxima | I’ll re-read this MR |
| alexpott | Will review tomorrow as well |
| Carson Oldson | :eyes: |
| phenaproxima | @robert-arias Would you object to me going in there and making small changes? For example: adding return type hints, removing methods that are only called once, making classes final and using private visibility — that kind of thing? |
| robert-arias | Not at all, go ahead! (edited) |
| phenaproxima | I have some architectural questions but I’d rather ask those; you have clearly done a really thorough and thoughtful job with this plugin so I don’t wanna blindly rip shit out |
| robert-arias | I don't have a strong opinion about the extensibility. Do you think worth it to remove the base class and just create the recipe unpacker? |
| phenaproxima | I personally would recommend removing the base class, yes. Extensibility is not a bad thing but I’d rather add that as-needed so we don’t get locked into an API that was not designed for real-world uses. |
| robert-arias | Agreed then - in any case, should other use cases arise, it should be easy to refactor it back I think. |
| phenaproxima | I agree! Always easier to add a new interface than to modify an existing one. |
| phenaproxima | OK, @robert-arias - I just pushed a commit that makes those minor changes. The overall architecture is left intact; if you want to remove the extensibility then I say go for it |
| robert-arias | Thanks! And I will. |
| robert-arias | Addressed feedback, left some comments and questions. I don't have as much experience with testing, so I'd appreciate if you could take a look into it; I left a comment regarding testing and the new changes. |
8️⃣ :chefkiss: Recipe types and naming needs review :chefkiss:
| thejimbirch | https://www.drupal.org/project/distributions_recipes/issues/3421666#comm... |
| Carson Oldson | I agree with Gábor in #32, the foundational recipes are ones that I think could use further sub-typeI think text format editor, content type, taxonomy, etc. type of a recipe would not appear as a site or a kit, so at best it would be a subtype of a foundational recipe (if recipes want to do subtyping that is). Would be great to run the three types through the initiative meeting and get feedback there. Then move forward to codify this as it would help move with project browser's listing. |
| Carson Oldson | When I think of those I think of config entities they would provide; text formats, user roles, etc. Maybe they are all still rolled up under a "foundational" type, but the sub type is really just the config entity type they provide, i.e. text_format_XYZ or user_role_XYZ .Edit: I actually mainly agree with @thejimbirch's point in #28. These types are foundational. You wouldn't have a Drupal site if you don't have at least one of these foundational config types (text format editors, content types taxonomy vocabs, fields, user roles, etc.)2. Do we assume that if it is one of the existing type (Text format editor, Content type, Taxonomy, etc) that it is Foundational?(edited) |
| Carson Oldson | Regarding the idea of a "Site" recipe I think we're aligned on what their purpose is, but I think we should relabel it to something other than "site".It's my understanding these site recipes would be the equivalent of install profiles so maybe to keep with the same naming for drupal developers would be helpful for adoption? Or do we want to break away from the terms like "distributions" or "profiles"? (edited) |
| thejimbirch | We do want to break away from the terms like "distributions" or "profiles". |
| thejimbirch | The "Site" nomenclature has been in the recipes docs since its inception. |
| Carson Oldson | Let's stick with that then :+1: |
| Carson Oldson | For folks converting distributions/profiles to utilize recipes they will need to create a "site" recipe instead. |
| Carson Oldson | If we wanted to codify the type to be specific to one of the 3 we have outlined would we need to modify this? https://git.drupalcode.org/project/distributions_recipes/-/blob/11.x/cor... |
| thejimbirch | Looks like it. |
| Carson Oldson | I'm trying to look further, but it doesn't appear type is used elsewhere. I'll give it another look before putting up a MR. |
| thejimbirch | I didn't even realize it was there! This is more for future use cases, like Project Browser and Drupal.org, but codifying it here will set precedent. |
| Carson Oldson | Got it! Another question then, should type be optional if this meant to function as a key by which D.O/DrupalCMS will query/categorize recipes in the future? (edited) |
| thejimbirch | I don't think our defining the types should allow for optional at this point. I think it should be required to be one of the types. |
9️⃣ A couple of items @thejimbirch and I discussed at NEDCamp regarding reapplying recipesWhen a recipe is reapplied, what happens to content that had been added? Do the original nodes get deleted and the new nodes created? Or is content additive - the original nodes remain and the new nodes get created?How are major releases of contrib modules handled? (Assuming the structure differs across releases). Both config and content would be affected.Jim suggested I created issues for these items, however I wanted to make sure these aren’t already part of existing issues and I’m not sure what the outcome should be.
| phenaproxima | When a recipe is reapplied, what happens to content that had been added?I think it would additive but I haven’t tested this personally. |
| phenaproxima | How are major releases of contrib modules handledHandled by whom? A recipe shouldn’t depend on multiple major versions of a module, for the same reason that nothing should really be doing that (the possibility of API breaks) |
| leslieg | If user installed a recipe with Media 3.x module (for example- if it was still contrib), are they allowed to install Media 4.x or are modules versioned by major release and they are stopped from trying to add a recipe containing Media 4.x? |
| phenaproxima | That would be up to Composer, as with any other dependency. |
| phenaproxima | If you have a package that requires media:^3, you won’t be able to add a package that requires media:^4 because they will conflict. |
| phenaproxima | So recipes do not do any proactive dependency solving like that. It’s all left to Composer, because that’s what it’s good at. Hope that helps. |
| leslieg | yes, was just wondering about how it worked with Recipes containing conflicting major versions of a module |
| leslieg | if a recipe was updated to use the new major version of a module, what happens if user tries to reapply the recipe? |
| phenaproxima | :thinking_face: I think it would depend on the situation, but it could get messy. |
| phenaproxima | @alexpott ^ This is kind of an interesting point; let’s say they apply Recipe 3.0, and then they later get Recipe 4.0 and apply it. The 4.0 version has a totally different config structure and dependencies, so it doesn’t outright conflict with 3.0, but it still leaves (at worst) weird zombie config from the 3.0 version lying around…no? |
| alexpott | Why would you apply the recipe again- the module update should update your site. If the a recipe has two different versions that fundamentally different things that’s okay. There is no zombie config. |
| phenaproxima | What about when force-apply is supported, @alexpott? |
| alexpott | Well if you don’t test force apply it is in your head. Force apply will not be recommended |
| Nick Dickinson-Wilde | User Error. I don't see any way to entirely prevent messing up your stuff if you don't test. I assume any --force type command is risky |
| phenaproxima | So there you have it, @leslieg - the whole idea of a site “having” a recipe is mistaken. Recipes are a thing that happen to your site, and then are removed/forgotten. You generally would not apply them again. |
| leslieg | The applied Recipes will still appear in the browser, so what is stopping a user from reapplying them? Is there no Apply button - but how would we even know a recipe had been already applied to remove that option? Thinking of our target audience of ambitious site builders. @phenaproxima (edited) |
| xurizaemon | To me it could make sense to apply recipes again, eg if you're applying a configuration to a network of sites. (Examples that might make sense, to me: standard configurations of seckit/csp rules for security hardening, or similar metatag rules for SEO.)Open to being corrected! Or maybe that's just not in "generally" case. (edited) |
| phenaproxima | you’re applying a configuration to a network of sites.I’m referring to reapplying recipes to the same site. If you apply the same recipe to multiple sites in the same code base, that’s the same as applying it once to each site. |
| xurizaemon | Ah, so am I, eg "we have ten sites, and we use recipes to apply {config} to each monthly". |
| phenaproxima | Not entirely sure I’m understanding that use case. Why would you reapply it over and over to the same sites? |
| phenaproxima | That doesn’t quite feel like what recipes were designed for |
| phenaproxima | They’re really intended to be one-and-done |
| xurizaemon | Yes, might not be the standard case, fair. I think if I have config which needs occasional updates across a network of sites, Recipes is a tool which looks appealing - but that doesn't make it the intended use! |
| phenaproxima | Agreed. Recipes were not designed to do config updates. |
| phenaproxima | As I said in my session with @thejimbirch, it’s unsupported and uncharted. If you can make it work for you, then good on ya — but you’ll void your warranty and I’ll hit you with a rubber chicken if I ever meet you at DrupalCon. =P |
| xurizaemon | (sorry @leslieg didn't mean to squash your question! I think there isn't a prevention against users reapplying recipes?) |
| phenaproxima | Correct. No prevention against it. |
| phenaproxima | In fact it is even necessary to the design of the system, for them to be composable. But that’s a little different than what folks are generally asking for when they say “reapplying” |
| mandclu | I would argue that the most likely reason to reapply a recipe is because of composability. When I create my site I apply the events recipe, but didn't need registration. Two years later we decide to ditch eventbrite and handle registrations on-site, so I want to apply the events_registration recipe. But maybe now the version of the events recipe two years later calls for a different major version of Smart Date than my site has installed |
| mandclu | Back to this point...When a recipe is reapplied, what happens to content that had been added? Do the original nodes get deleted and the new nodes created? Or is content additive - the original nodes remain and the new nodes get created?Remember that the content entities have uuids (literally the filenames). So I would expect that it would create them if they don't already exists, but not sure how it would handle ones that do exist. Would it care if they exist but are different? |
| phenaproxima | I don’t remember exactly, but I can sure tell you where to look for the answer… |
| thejimbirch | Also, the file name doesn’t need to be the uuid. They just get exported that way. You can change them. |
| mattgyver | As a site builder, i think applying and reapplying a recipe will be very common.Imagine I apply the event recipe. I play around with the new configuration, maybe change some things in views...etc but in the end I mess up my site.I want to reapply the recipe to have it back to the initial / correct state. |
| phenaproxima | @mattgyver That’s not a reapply you want; that’s a revert |
| mattgyver | Yes maybe.We need to make things clear in the UIBecause reapplying a recipe can means "revert" in site builders minds |
| phenaproxima | Which is a separate thing that we intend to support more fully. But you can already just take a config snapshot before applying a recipe. Why not just do that. |
| Agreed that this needs to be clear. Reapply is not a revert and it never will be | |
| mattgyver | Yes i canI was thinking as if i was a site builder trying out Drupal CMS |
Participants:
thejimbirch, alexpott, leslieg, emoleee, robertarias, b_sharpe, NickDickinsonWilde, jerdavis, carsoncho, mandclu, ltrain, guptahemant, phenaproxima, abhisekmazumdar, xurizaemon, mattgyver,
Comments
Comment #2
jdleonardAdding notes and participants.
Needs review and credits.
Comment #3
jdleonardFixed issue links
Comment #4
jdleonardFixed participants to use any d.o usernames specified in item 0
Comment #5
thejimbirch commentedComment #19
hestenet