>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3499813. --> Reported by: [kristen pol](https://www.drupal.org/user/8389) >>> <h2>0&#65039;&#8419; Who is here today? Comment in the thread below with your <a href="http://drupal.org">drupal.org</a> username to introduce yourself and share another one of your favorite modules.</h2> <table> <tr> <td>hestenet (he/him)</td> <td>Tim from the DAhestenetI like WebPHere to see what DA support might be needed as recipe browsing is further defined</td> </tr> <tr> <td>Andr&eacute; Angelantoni</td> <td>Hola, from Idaho but about to get on a plane to Oakland. aangelMy current favorite module is Automated Testing Kit and we&rsquo;re currently trying to get a recipe going to make a demo site in time for BADCamp.Working through the existing config issue right now (<a href="https://drupal.slack.com/archives/C2THUBAVA/p1727282755286669?thread_ts=1727282731.551169&amp;cid=C2THUBAVA">https://drupal.slack.com/archives/C2THUBAVA/p1727282755286669?thread_ts=1727282731.551169&amp;cid=C2THUBAVA</a>)</td> </tr> <tr> <td>sonfd</td> <td>sonfd, I like <a href="https://www.drupal.org/project/maxlength">MaxLength</a></td> </tr> <tr> <td>eclipsegc</td> <td>Here</td> </tr> <tr> <td>Andr&eacute; Angelantoni</td> <td>@sonfd well, 50,000 other people knew about that module&hellip;except for me. And now I do, too. &#128578;</td> </tr> <tr> <td>benjifisher</td> <td>Can I reply to the prompt from the previous meeting? My first recipe is currently on my <a href="http://GitLab.com">GitLab.com</a> account, but I plan to move it to d.o after a little more work. <a href="https://gitlab.com/benjifisher/import_csvI">https://gitlab.com/benjifisher/import_csvI</a> already got some feedback from @thejimbirch (not yet addressed). Thanks for that!@Andr&eacute; Angelantoni: I will see you in Oakland, but I will not get there until Wednesday evening.benjifisher</td> </tr> <tr> <td>Andr&eacute; Angelantoni</td> <td>@benjifisher sure thing! We do the load-in Wednesday night then arrive the next morning bright-eyed and bushy-tailed.</td> </tr> <tr> <td>bryan</td> <td>:wave:</td> </tr> <tr> <td>thejimbirch</td> <td>I'm not including it in Drupal CMS, but thought this looked pretty cool!<a href="https://www.drupal.org/project/ai_seo">https://www.drupal.org/project/ai_seo</a></td> </tr> <tr> <td>ltrain</td> <td>@ltrain here&hellip; I just started using Layout Paragraphs and it&rsquo;s kind of neat</td> </tr> <tr> <td>briangilbert (realityloop)</td> <td>:wave:&nbsp; Druxt (decoupled helper module)</td> </tr> <tr> <td>Bob McDonald (ultrabob)</td> <td>Ultrabob. In transit to BADCamp.&nbsp; ECA is really cool, though I have not found enough time to really put it through its paces.</td> </tr> <tr> <td>dww</td> <td>dww and I'm a fan of <a href="https://www.drupal.org/project/editoria11y">https://www.drupal.org/project/editoria11y</a></td> </tr> <tr> <td>guptahemant</td> <td>guptahemant from India, and my all time favourite module is views</td> </tr> <tr> <td>markie</td> <td>markie here.. of course.. smart_trim</td> </tr> <tr> <td>markie</td> <td>but also, recently <a href="https://dgo.to/sdc_styleguide">https://dgo.to/sdc_styleguide</a></td> </tr> </table> <h2>1&#65039;&#8419; On the last episode we announced <a href="https://www.drupal.org/node/3478662">Recipes can opt out of strict comparisons with existing config</a> This change will be in 10.4 and 11.But we should move forward on <a href="https://www.drupal.org/project/drupal/issues/3478669">Make recipes' comparison with existing config lenient by default</a></h2> <table> <tr> <td>thejimbirch</td> <td>In anticipation, core recipes have already set the precedent to set strict on any configs that create database storag[#3481751]</td> </tr> <tr> <td>phenaproxima</td> <td>I generally feel like strict: false is a sane default.</td> </tr> <tr> <td>Andr&eacute; Angelantoni</td> <td>Oh&hellip;.this may solve the issue I mentioned in 0, above.</td> </tr> <tr> <td>phenaproxima</td> <td>BUT that means field storages would also be treated non-strictly by default, and that is dangerous</td> </tr> <tr> <td>phenaproxima</td> <td>@Andr&eacute; Angelantoni Might help with your issue, but it can also be tricky. If you opt out of strict checking, then you cannot be sure that preexisting entities with the same name are what you expect.</td> </tr> <tr> <td>phenaproxima</td> <td>So strict: false makes it more forgiving, but then you really have to stay on top of your assumptions.</td> </tr> <tr> <td>thejimbirch</td> <td>I too like strict: false by default as it provides the most flexibility.</td> </tr> <tr> <td>thejimbirch</td> <td>And with great power comes...</td> </tr> <tr> <td>phenaproxima</td> <td>Flexibility comes at the cost of safety</td> </tr> <tr> <td>phenaproxima</td> <td>Not a big cost, I think the tradeoff is worthwhile, but it&rsquo;s worth being aware of.</td> </tr> <tr> <td>Andr&eacute; Angelantoni</td> <td>@phenaproxima ok, good to know&hellip;checking the issue, it appears that the option is only on D11-dev currently, yes?</td> </tr> <tr> <td>phenaproxima</td> <td>@Andr&eacute; Angelantoni No, it&rsquo;s in 10.4.x too</td> </tr> <tr> <td>Andr&eacute; Angelantoni</td> <td>Excellente.</td> </tr> <tr> <td>alexpott</td> <td>I think I prefer the current situation. We make people think about the safeness of the assumption. I think it is keeping with our try not to break stuff wish for recipes.</td> </tr> <tr> <td>alexpott</td> <td>It&rsquo;s like the listing of config to install. Awkward the first time, annoying, but then you realise we have no other choice once you&rsquo;ve used the system for a while.</td> </tr> <tr> <td>phenaproxima</td> <td>@alexpott I think that the very existence of the option will backfire - people are inclined to just set strict: false and forget about it. That said, we need to document why you&rsquo;d want to use strict checking, and what some useful cases for it are (field storages being a major one)</td> </tr> <tr> <td>phenaproxima</td> <td>Regardless of whether we change the default behavior</td> </tr> <tr> <td>alexpott</td> <td>That might be - but then that&rsquo;s still an argument to keep the current behaviour. Why? Because then strict: false is a sign of a potentially problematic recipe.</td> </tr> <tr> <td>phenaproxima</td> <td>@alexpott Related - I think we should look into making strict comparison more meaningful. I can see a way to do it using existing core tools.</td> </tr> <tr> <td></td> <td>$a != $b is too simplistic. I think if strict mode was more meaningful, it would be more comfortable as a default.</td> </tr> <tr> <td>alexpott</td> <td>Yeah this is getting in to the preconditions thing we&rsquo;ve discussed before</td> </tr> <tr> <td>phenaproxima</td> <td>How I&rsquo;d approach this is by introducing the idea of comparators that operate at the typed data level</td> </tr> <tr> <td>phenaproxima</td> <td>So like, a thing that can say &ldquo;this sequence is equal to this other sequence&rdquo;</td> </tr> <tr> <td>phenaproxima</td> <td>IIRC, field items already sort of have this</td> </tr> <tr> <td>phenaproxima</td> <td>But sheesh, the amount of work it would take in core&hellip;</td> </tr> <tr> <td>thejimbirch</td> <td>My understanding is that I can'tstrict: falseand then strict a specific config.&nbsp;(edited)</td> </tr> <tr> <td>thejimbirch</td> <td>is that correct?</td> </tr> <tr> <td>phenaproxima</td> <td>Correct. If you strict a specific thing, then everything else is automatically non-strict.</td> </tr> <tr> <td>thejimbirch</td> <td>Oh, that is not obvious</td> </tr> <tr> <td>phenaproxima</td> <td>Perhaps that calls for a documentation update! &#128578;</td> </tr> <tr> <td>thejimbirch</td> <td>yeah, at least not to me.</td> </tr> <tr> <td>thejimbirch</td> <td>Then I guess its a 6 of one, half a dozen of the other.</td> </tr> <tr> <td>phenaproxima</td> <td>There are three ways strict can operate:Everything is strict!Nothing is strict!Only some stuff is strict! (Which implies, by definition, that anything else isn&rsquo;t.)</td> </tr> <tr> <td>thejimbirch</td> <td>I did not grok that implication, but do now.</td> </tr> <tr> <td></td> <td>So should we decide to close the issue and accept the current defaults?</td> </tr> <tr> <td>phenaproxima</td> <td>I think we should maybe update it with this discussion and see if there is any more feedback.</td> </tr> <tr> <td>phenaproxima</td> <td>But if there&rsquo;s not, we can close it.</td> </tr> </table> <h2>2&#65039;&#8419; Whoops, jumped right into it and didn't make a thread for input.Post here to ask a question or start a thread.&nbsp; Or go ahead and grab the next number and add it yourself!</h2> <table> </table> <h2>3&#65039;&#8419; :tada: :tada: :tada:&nbsp; New Config Action: cloneAs - <a href="https://www.drupal.org/project/drupal/issues/3481238">Add a config action to clone a config entity</a></h2> <table> <tr> <td>phenaproxima</td> <td>Little caveat here - it doesn&rsquo;t work on entity view displays, or form displays, properly. Yet. There&rsquo;s an issue open to correct that.</td> </tr> <tr> <td>phenaproxima</td> <td>@alexpott Take a look - your idea worked but there is a catch.<span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/drupal/issues/3481695" title="Status: Closed (fixed)">#3481695: Entity displays cloning requires special config action</a></span>#comment-15826155</td> </tr> <tr> <td>Rajab Natshah</td> <td>Oh my God, this is so helpful.</td> </tr> <tr> <td>Rajab Natshah</td> <td>A replacer and renamer could give the cloneAs a boost.</td> </tr> <tr> <td>Rajab Natshah</td> <td>A config_templates can have the default base configs for ( agreed, or best practice )Then when cloning to other entity typesSomething like what in this <a href="https://git.drupalcode.org/project/vmi/-/tree/3.0.x/src/assets/config_templates/CONTENT_TYPE_NAME?ref_type=heads">example</a>A <a href="http://ViewModesInventoryFactory.php">View Modes Inventory Factory</a>could need to handle a messing field, in the other entity typeor replace or rename some parts before cloning.In my case, I'm using a string manipulation in the VMI factory.doing a replacer and renamer could allow for cloning between different entity types.</td> </tr> <tr> <td>alexpott</td> <td>@phenaproxima <a href="https://git.drupalcode.org/project/drupal/-/merge_requests/9874#note_396142">https://git.drupalcode.org/project/drupal/-/merge_requests/9874#note_396142</a></td> </tr> <tr> <td>phenaproxima</td> <td>@alexpott So I thought about doing that - I&rsquo;m only wondering if that would constitute an unpleasant surprise from a DX perspective, since set() is a very general purpose method and you&rsquo;d expect it to always do what it says, regardless of newness.</td> </tr> <tr> <td>alexpott</td> <td>Well the way id() works on entity displays is all full of surprise. I think this is okay</td> </tr> <tr> <td>alexpott</td> <td>You&rsquo;re you&rsquo;re going to get an immutable error anyways</td> </tr> <tr> <td>phenaproxima</td> <td>If you validate, yes.</td> </tr> <tr> <td>phenaproxima</td> <td>But I agree, the whole thing is wonky</td> </tr> <tr> <td>alexpott</td> <td>And if you don&rsquo;t you&rsquo;re on your own!</td> </tr> <tr> <td>phenaproxima</td> <td>Alright, let me give this a shot</td> </tr> <tr> <td>phenaproxima</td> <td>@alexpott Changes pushed.</td> </tr> <tr> <td>phenaproxima</td> <td>@alexpott OK, a thought - we probably need follow-ups to do this same &ldquo;the ID is meaningful if changed&rdquo; logic in things like, I dunno, field and field_storage config entities. Otherwise people will try stuff like this:field.storage.node.foo:<br> cloneAs: node.barAnd that will go pear-shaped.</td> </tr> <tr> <td>alexpott</td> <td>Let&rsquo;s do that in follow-ups</td> </tr> <tr> <td>phenaproxima</td> <td>Yeah agreed</td> </tr> <tr> <td>alexpott</td> <td>I wonder if we should consider generalising this ID building for config in some way</td> </tr> <tr> <td>alexpott</td> <td>But we discuss that in the issue.</td> </tr> <tr> <td>phenaproxima</td> <td>Everything else look okay in the issue?</td> </tr> <tr> <td>alexpott</td> <td>So the current cloneAs works in a non-strict way - ie. doesn&rsquo;t fail if the thing exists. How does createCopy work?</td> </tr> <tr> <td>phenaproxima</td> <td>:thinking_face:&nbsp; That&rsquo;s a good question. I would imagine it is a hard fail because the config with that ID will already exist and violate the unique ID requirement.</td> </tr> <tr> <td>phenaproxima</td> <td>But that said, createCopy and cloneAs are two completely distinct things.</td> </tr> <tr> <td>alexpott</td> <td>Also I wonder if the cloneAs behaviour should be configurable&hellip;</td> </tr> <tr> <td>phenaproxima</td> <td>I wondered about that, but I think it should be a follow-up.</td> </tr> <tr> <td>phenaproxima</td> <td>Follow-up #1 opened:<span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-1"><a href="https://www.drupal.org/project/drupal/issues/3482771" title="Status: Active">#3482771: Config entities that have IDs which are built from other properties should update those properties when the ID changes</a></span></td> </tr> <tr> <td>phenaproxima</td> <td>Follow-up #2 opened:<span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/drupal/issues/3482783" title="Status: Closed (fixed)">#3482783: Consider making the cloneAs config action optionally fail if the clone already exists</a></span></td> </tr> <tr> <td></td> <td>@thejimbirch @artem Any chance of an RTBC in the main issue? I think all feedback is addressed.&nbsp;(edited)</td> </tr> <tr> <td>thejimbirch</td> <td>To clarify, it is this, correct[#3481695]</td> </tr> <tr> <td>phenaproxima</td> <td>That&rsquo;s the one.</td> </tr> <tr> <td>artem</td> <td>I will try to check today and test with search recipe, thank you!</td> </tr> <tr> <td>phenaproxima</td> <td>@artem For your case, you&rsquo;ll want to use the createCopy action.</td> </tr> <tr> <td>phenaproxima</td> <td>@thejimbirch CR written</td> </tr> <tr> <td>thejimbirch</td> <td>Amazing! Marked as RTBC</td> </tr> <tr> <td>phenaproxima</td> <td>:checked:</td> </tr> <tr> <td>thejimbirch</td> <td>Docs issue added to follow up on after its merged.</td> </tr> <tr> <td>artem</td> <td>I also confirm that it works as expected, already with latest Drupal 10.4.x-dev</td> </tr> <tr> <td>artem</td> <td>thank you all!</td> </tr> </table> <h2>4&#65039;&#8419; :tada: :tada: :tada:&nbsp; New Config Action: createForEach and createForEachIfNotExists&nbsp; - <a href="https://www.drupal.org/project/drupal/issues/3464550">Create config action which can create an entity for every bundle of another entity type</a></h2> <table> <tr> <td>phenaproxima</td> <td>Here&rsquo;s the documentation: <a href="https://www.drupal.org/node/3481714">https://www.drupal.org/node/3481714</a></td> </tr> <tr> <td>benjifisher</td> <td>The Slack preview cut off a little too soon:A classic use case is making every content type translatable. This requires creating a language.content_settings.node.TYPE entity for each node type.</td> </tr> </table> <h2>5&#65039;&#8419; @penyaskito is makings some cool progress on config actions for layout builder! <a href="https://www.drupal.org/project/drupal/issues/3475115">Provide a Config Action to add/edit a component in a layout</a></h2> <table> </table> <h2>6&#65039;&#8419; @robert-arias Added more work to <a href="https://www.drupal.org/project/distributions_recipes/issues/3355485">Dependencies should be 'unpacked' to the root composer.json and merged/resolved</a></h2> <table> </table> <h2>7&#65039;&#8419; Recipe browsing on <a href="http://Drupal.org">Drupal.org</a>, Project Browser and other places. We most likely need a UX lead for this.&nbsp; We have open issues, and the Drupal Association is at the ready to support, but we need to formulate a user experience journey/plan first.&nbsp; Inquire within if you are interested.</h2> <table> <tr> <td>dww</td> <td>I'm interested, but don't have much / any time. :sweat_smile:&nbsp; I'm following[#3447063] now, which is where I assume the action should be...</td> </tr> <tr> <td>Rachel Hart</td> <td>Interested to learn more!</td> </tr> </table> <p>Participants:</p> <p>hestenet, aangel, sonfd, eclipsegc, benjifisher, b_sharpe, thejimbirch, ltrain, realityloop, ultrabob, dww, guptahemant, markie, phenaproxima, alexpott, rajab natshah, artem, rachelh_design</p>