🇺🇸United States @carsoncho

hestenet → credited carsoncho → .

hestenet → credited carsoncho → .

So in 📌 Decide on naming convention on recipes Active a concern that was brought up was that there's nothing stopping a developer from changing types between releases. So in the 3 legged approach (foundational, kit, site) one release a recipe could be "foundational" and in the next it could be changed to "site". To me the "type" property for a recipe.yml serves the same function as the "package" property for module .info.yml files and shouldn't impact how recipes are discovered on Drupal.org

I think for actual classifications those should be handled on the Drupal.org project page. If we go with a 3 tiered approach we may have different categories per type so having those conditional fields mentioned in #16 makes a lot sense.

carsoncho → created an issue.

After reviewing the module category list I would argue those are categories would best be suited for recipes that we're calling "kits". These "kit" recipes provide functionality that I believe would fall into one of those module categories since these recipes often require at least one module and does some initial configuration to provide a working starter-kit for some functionality like these "Functionality specific recipes" → .

"Foundational" recipes are small scoped configuration items pertaining to a particular subset of config and there's documentation in MR 107 that I believe we have a good amount of sub-types for:

• - Block type
• - Contact form
• - Content type
• - Editor
• - Field
• - Media type
• - Responsive image
• - Site
• - Taxonomy
• - Text format
• - User role
• - User type
• - Workflow

"Site" recipes in my mind would eventually replace what we have here on the distributions page https://www.drupal.org/project/project_distribution → . There's no categories to interact with there, but we should think about coming up with those as part of this. I get the sense that because "distributions" or install profiles will be easier to achieve with recipes that we'll be seeing an influx of those soon.

I do agree with #37 in that because there's nothing stopping a developer from changing types between version of recipes I do think it makes sense to manage them all in one place and I do think D.O is the better place to do that. There's really no value in a "type" being set in a recipe.yml right now as it serves no purpose.

@chrisfromredfin where would the best place to review those categories be? The module search page on D.O?

We're starting to get there. A bit more discussion happened on the the Nov 5th thread and I'm in agreement with a lot of what was being talked about there.

Based on what I'm reading I believe we're all in agreement that we need some amount of sub-typing for further categorization to be used in Project Browser or on D.O. The sub-typing can be a bit more freeform then what I think we're wanting with a more concrete "type".

I like "approach B" from this last comment in the Nov 5th thread

... B)
What do you think of this approach:
- In recipe.yml, we only define one level: foundational | kit | site.
- On drupal.org, we add “tags” to each recipe project page, where we can assign multiple tags.
This way, I could filter by types (e.g., foundational+kit) and tags (e.g., SEO) to narrow down the search.
I haven’t been involved in the entire analysis process, so I may be missing some assumptions, and this idea could be off, but it’s what came to mind after reading this thread.

This aligns with what I was expecting. In my mind we set a "type" at the code level in the recipe.yml, but utilize "tags" on the recipe project page for further categorization.

I have checked out the MR in 110 to make the code change to make the "type" required and be exactly one of the following: `foundational`, `site`, or `kit`, but I still need to go through and update the core recipes to adhere to these concrete types. Figured before I commit and push those changes to make sure it is what we want. I'll hold off on committing that for now.

Re #28:

1. Do we need a second classification type to cover the Foundational descriptive types that we currently have defined? (Text format editor, Content type, Taxonomy, etc)

- or -

2. Do we assume that if it is one of the existing type (Text format editor, Content type, Taxonomy, etc) that it is Foundational?

If we think about how a user will search for Recipes within the context of Project Browser and/or eventually on D.O we'd want to think about these through the lens of the Ambitious Site Builder and what makes the most sense to them. I know I have a jaded/biased lens as a developer, but to me it seems the persona we're targeting for wouldn't find much value in searching for a single "foundational" recipe by itself, but I'm happy to be wrong on that if folks think otherwise.

I'm with Gábor on #32 -- these sub-types don't make sense being tagged as part of a "kit" or "site". To me it seems like these sub-types "Text format editor", "Content type", "Taxonomy", etc. are all sub-types or 'tags' of "foundational" recipes. Kind of analogous to the "Module Categories" on the module search page.

These foundational recipes seem more useful to a developer who doesn't want to potentially reinvent the wheel if a recipe already exists to serve their needs vs. the ambitious site builder.

Have we brought this proposal of the three types to the initiative meeting to discuss? If so, was there any consensus or changes we should make based on that discussion?

I think unfortunately due to the way CK5 was rebuilt to not utilize any dialogs there's no way to make alterations without creating your own custom CK5 plugin to do what you need. It's a pain not being able to make quick alterations via a form alter anymore.

pameeela → credited carsoncho → .

This was mostly working, but we're using autocomplete widget so I've modified the selector to also target the autocomplete widget as well. Additionally, I added an align-self to fix the group listing title to also be centered.

carsoncho → made their first commit to this issue’s fork.

hestenet → credited carsoncho → .

We had a conversation around this a couple weeks ago in slack at the Distribution Modernization Initiative meeting. Posting here for posterity.

As a TL;DR for the naming convention for recipe names some of us liked the idea of [drupal_entity_type]_[unique_name], i.e content_type_blog, content_type_event, etc. We also had the thought of trying to stick close to what core provides for it's config naming scheme as that will help us as developers mentally keep track of things. One thought was to even include periods in the name like core does, for example node_type.event as a recipe. We hadn't tried it out, but maybe recipes will allow folder names to include periods in their names? TBD.

Also, from a developer perspective imagining them in a list in a yaml file where you have to maintain that is something I think we want to keep in mind as well. It will get hard to tell what recipes are doing if we don't have a standard.

I personally like the idea of where [#10] is going, but we would really need to align on the verbiage used. Allowing for folks to mix-and-match will make it very difficult to quickly determine what a recipe is doing.

Regarding the Recipe types and classification portion of this IS I think needs to be broken off into a separate issue from the naming convention discussion of this issue.

To add my thoughts though, I'm personally a fan of [#18] with the concept of providing "kits" to get folks off the ground quickly. A great example is the module Smart Date Calendar Kit → that @mandclu maintains. This to me is what an ambitious site builder is going to look for and gravitate to more. They don't want to think about node types or setting up views. What they want is functionality that will provide them value out of the box with little to no additional configuration needed.

Recipes can be any shape and size and that is part of the problem we're running into when we talk about how we classify them. As developers we should want to and probably start looking at having small recipes to establish generic content / paragraph types quickly and then look to extend those in more functional kit-like recipes.

At a high level I see we have 3 basic categories:

1. Scaffold / Skeleton / Foundational Recipes - These are the low level "provides XYZ content/paragraph type" recipes
2. Functional (Kit) Recipes - These build on top of the lower level recipes and provide additional functionality (event calendars, workflows, etc.)
3. Site Recipes - These include everything above, like what Standard recipe provides

There's lots of room for additional sub-types within these 3 basic categories, but in my head that's where I see big distinctions between the size and scope of recipes.

I've added docblock info for those new methods. Ready for review.

What quality signals for recipes can we use to promote the 'best' ones in the project browser?

I believe there should be a governance group that would validate and promote 'best in class' recipes. These ones I would envision show up on the homepage of Project Browser when browsing available recipes or when creating a new site from scratch as these ones would be "verified" (maybe even with a badge in their recipe thumbnail to show this) by the governance group/community to work well out-of-the-box.

Another metric I presume we can use would be a "sites installed" count like we have for modules. This is one metric I was taught when staring out as a Drupal dev when validating quality and support of a module and I presume the same would apply for recipes as well. I'm not certain how D.O calculates the "sites installed" metric on module pages, but presumably we'd have that same capability as well?

Trying to put myself in the shoes of a brand new person to Drupal but an ambitious site builder looking to start using Drupal having something that tells me "this will work well and has been tested" would certainly give me a vote of confidence when trying to choose a recipe.

How do we manage duplicated effort on recipes? (For example, having multiple recipes for building a news site)

Maybe we start with a Meta page discussing what folks would find valuable as a recipe and create child issues that would be in the individual recipes themselves? If we start from what the wireframes showed in us Project Browser we'd have a couple we could start to look at immediately. Then would need to determine what exactly comes with those recipes.

One of the issues I keep coming back to regarding this is how do we prevent running into duplicate machine names of field names. This seems like something we'll constantly run into without a managed effort to prevent it.

Another area I think needs thought around is the size and scale of recipes. A recipe could be something as small as a paragraph component with fields while another could be effectively a fully built out site with multiple content types, views and various view modes. And in that scenario how do we keep from re-inventing the wheel when it comes to those smaller components, i.e simple "card" paragraph type effectively duplicated across multiple recipes?

Maybe the best way to prevent that duplicated effort is to create small bite-sized recipes like what Standard install recipe has done for each content type and make those available ASAP to the Cookbook Page →

I'm very curious to hear other's thoughts on this.

What I think is remaining is the tests updates. I see there's a few failing due to configuration tests as it's noting that the core.entity_view_mode.* config files have been changed and updated. This is to be expected given the hook_post_update_NAME() being included here.

Drupal\FunctionalTests\Installer\InstallerExistingConfigMultilingualTest::testConfigSync
Failed asserting that two arrays are equal.
--- Expected
+++ Actual
@@ @@
 Array (
     'create' => []
     'update' => Array (
-        0 => 'system.mail'
+        0 => 'core.entity_view_mode.node.teaser'
+        1 => 'core.entity_view_mode.node.se...result'
+        2 => 'core.entity_view_mode.node.se..._index'
+        3 => 'core.entity_view_mode.node.rss'
+        4 => 'core.entity_view_mode.node.full'
+        5 => 'system.mail'
+        6 => 'core.entity_view_mode.user.full'
+        7 => 'core.entity_view_mode.user.compact'
     )

Is the right thing to do here update the tests so they expect all those view mode configuration changes? Testing is an area I'd like to be able to contribute to more so any information folks can provide is much appreciated.

carsoncho → made their first commit to this issue’s fork.

This all looks correct to me. Config inspector is reporting this at 100% now. Is the reason this is back to Needs work because of the pipelines failing?

[#3] The idea would be to extend Symfony's Constraint rather than copy and duplicate. Extending it would then allow for us to have the generic functionality and would be BC.

Just got to testing and it all looks great to me! I'm no longer getting the duplicate markup that I noted above. Apologies for the delay on that. Thank you for your prompt response to fixing the issue!

RTBC!

carsoncho → created an issue.

I certainly can! Thanks for getting on this so quickly! I'll report back later today with my findings.

carsoncho → created an issue.

carsoncho → changed the visibility of the branch 3392621_3168966_combined_10.1.x to hidden.

carsoncho → changed the visibility of the branch 3392621_3168966_combined_10.1.x to active.

I've started a issue fork against 11.x and have re-rolled #6 against it. I haven't added any test coverage for this yet. That's a little out of my wheelhouse, but I would love to learn!

Additionally here a patch for 10.2.x

carsoncho → made their first commit to this issue’s fork.

Add Schema:Article field for Thing->url

carsoncho → created an issue.

carsoncho → created an issue.

Adding some clarification to the summary.

carsoncho → created an issue.

carsoncho → made their first commit to this issue’s fork.

Is it possible to support both CKEditor 4 and 5 within the same module version? I see now there's a 3.x and 4.x version that both support Drupal 10, but support ckeditor versions separately. Is there any reason we couldn't have both ckeditor versions working in the same version?

carsoncho → created an issue.

Reroll of #58 against the latest 1.x version

carsoncho → made their first commit to this issue’s fork.

@heddn now that Groups has a proper Drupal 10 release → would you be able to review the MR?

Uploading patch that resolves this for the 3.x branch.

carsoncho → created an issue.

I believe this issue is related to 🐛 TCA is causing entities to be save twice Active .

We were running into this on a Drupal 10.1 site with version 3.0 of TCA and TCA node enabled along with core's workflows and content moderation modules. With TCA enabled I was running into issues where I was not able to edit the current revision. It kept loading the published revision although in the revisions tab it showed revisions being made. Secondly each revision that was saved after enabling TCA caused the revision ID to increment by 2 which I found odd. I believe this is caused by the node being saved twice which is noted in 🐛 TCA is causing entities to be save twice Active . Once the patch was applied from 3375544 these issues were resolved.

This patch does not appear to work with. I'm attempting to get a multivalue term reference field to output the term names in a list with this [webform_submission:values:multivalue_term_reference:array:entity:name] and it's being output as "Term 1 (1)entityTerm 2 (2)".

I am doing this via custom code with a custom WebformHandler that's calling on the webform submission handler's token service.

Any thoughts?

Is it also expected behavior that a content author can create an invisible anchor like what appears in #71? It appears that the invisible anchor can only be deleted via editing the source.

Closing. This appears to be fixed in latest dev.

carsoncho → created an issue.

carsoncho → created an issue.

Adding patch which is based on the open MR. Further work still needs to be made, but much closer to supporting CK5 now.

What still needs to be resolved:
1. Creating our own `drupalInlineMedia.toolbar` plugin rather than extending it. Current implementation clobbers selected view modes together
2. After changing the view mode the preview displays, but doesn't replace the old media inline item causing the same item to be displayed multiple times.

carsoncho → created an issue.

I'm running into the exact same issue using Drupal core 9.4.12 and svg_image 3.0.1. Here's a patch based off the MR.

Hi @jurgenhaas, I was curious about the status of this. Is there any help that can be provided to push this forward? I was about to create a separate issue to ask how one might go about achieving a view showing notifications for the currently logged in user.

In my case I would like to utilize the danse_content_moderation module to create Events for users when nodes transition through their various workflow states. To that end, I would like to create a view that shows the user their recent notifications and provide a link to the node revision. I'm not sure how to go about that currently.

It's my understanding that the Event stores a reference to the entity that triggered the creation of the Event as well as including the relevant info as part of the Payload. However, there's no way to utilize the Reference or Payload as a relationship so I don't have a way to create a link to the node's revisions.

In my head I see this as a view of Notifications with a relationship to the Event. The event relationship could then open up a relationship to the Payload's reference (in my case a content moderation state) which in turn can be used for a relationship to get the node's revision. Is there a better way to implement this or is my thinking here correct in your mind.