[Meta] Plan for recipe

... just day dreaming on the UX features:

Can a recipe have: icon, project URL, category tags, etc?
This info would need to be either in the project or in a global registry, maybe both.

My head goes towards being able to add all the project details into the recipe.yml.
(maybe we can already do this?)

Imagine if a site could use Feeds or some other tool to grab a recipe_starshot_index.json or recipe_community_index.json. Then a flexible cookbook page could be built with Views.

Start me off with the Starshot cookbook, but let me run other Recipe Feeds if I want to opt in to community software.

Hear me out on why I say Views, because they're flexible. Just like /admin/content, /admin/recipes would be easy to customize.

Use case, I needed a Department field on my content overview page. Boom, Drupal let me add this easily. Maybe I want to theme a fun card View of my personal recipe cookbook?

Feeds, or some other task, could scan my local /web/recipes/contrib/* and make theses available too.

Feed sources: Global Default (starshot), Global Opt-in (community), Local (contrib)

Wherever we land, I'm sure it will be awesome.
Thanks to the Devs making this happen!

I've added the wireframes supplied in #starshot on slack.

#3447749: Added the optional ability to apply recipes from the core installer UI → is part of this I think. I think the Project Browser part will need to be resolved in Project Browser :D

https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... → has been helpful for me in seeing an initial split between “Site starter recipes” & “Functionality-specific recipes”, which tells me that might be something to track in metadata fields.

Would the module categories https://www.drupal.org/docs/develop/managing-a-drupalorg-theme-module-or... → make any sense to use? Is there different categorization.

How can we help someone looking through what will be hundreds of recipes find something that matches their needs?

I think recipes have the potential to be huge, just comparing what happened with Features. I'm worried that even with our collective experience we might not be able to pull off a user friendly recipe browser. We should expect that vendors will want to funnel users to their recommended recipes, and that we should welcome duplication of recipes (eg multiple "contact us" recipes) in a healthy competitive ecosystem.

Stories brain dump

I don't think all of these need to be in scope, seeing what i can scrape out.

As a builder I want to browse recipes by organisation.

As a builder I want to filter to a specific organisation who i work for, or who I pay to support my site.

As a builder I want to find recipes which help harden or prepare my site go-live.

As a site builder I want to apply a functional thing like (per Drumm's link in #9)

As a builder I want to see recipes which are similar to the one i'm looking at.

As a builder I want to see recipe ratings (like chrome store etc)

As a builder I want to use natural language searches.

More examples:

• The builder is advised by a consultant to turn off page cache module because there is a reverse proxy but to set specific timeouts. Is the consultant able to point them to a specific recipe?
• The builder is having trouble with Stripe and wants to try one of, oh, 40 available payment gateway modules for Commerce API

Working on updating recipe naming and classification in the recipes code in 📌 Decide and update recipe naming and classification standards Needs review

I think we should also give some thought as to how someone will choose between recipes, if there should be an explosion of available recipes. The wireframe shows a "Popular" tag on a particular recipe, but how would this be determined if recipes are not left "installed" in any way? Should there be a rating system?

Some marketplaces / app stores allow users to curate their own lists, which could potentially provide indication of preferred solutions, or at least a standardized way to provide input on some specific options to consider.

Some marketplaces / app stores allow users to curate their own lists,

This makes me think of the game Civ6 in the Steam store. You can browse curated lists of mods in Steam. If you follow a streamer they will have a link to the Steam store showing the plugins they recommend. I would definitely create and shared a curated list if this was available and I'm 100% sure this would appeal to every organisation that creates new sites regularly.

A rating system would be a large lift, see #50605: Add user ratings for projects → for some background. In short, there are a lot of details to figure out like:

• Are the ratings on the most recent version more important or the only ones to consider?
• Or use all the ratings across all versions? Some sort of weighting?
• Need to establish additional moderation for new user generated content - handling spam and low-quality ratings

We can get Composer download counts working, but there’s not a good way to distinguish a real download for a site vs. a CI system or something else.

I would definitely create and shared a curated list if this was available

I think this would be good for project browser in general. A curated place to start if you don't know what to search for, and more ability to highlight things that work together. However, this would also be a new type of user-generated content to establish community guidelines for - who gets to make lists (probably many people), who gets to decide which lists to highlight, with what criteria?

Since #3317618 is closed as a duplicate of #3446257, I am replacing it in the "Related tasks" section of the issue summary.

With ✨ Add composer release type field Active we now can list general projects which are recipes, according to their composer.json:

• Velir Base →
• Locations →
• Events →
• Events Calendar →
• Events Locations →
• Events Registration →
• Tour Core →
• Test JSON:API Reference →
• Tour Core Language →

The query used was SELECT DISTINCT n.nid, n.title FROM field_data_field_composer_type fdf_ct INNER JOIN field_data_field_release_project fdf_rp ON fdf_rp.entity_id = fdf_ct.entity_id INNER JOIN node n ON n.nid = fdf_rp.field_release_project_target_id WHERE fdf_ct.field_composer_type_value = 'drupal-recipe';

📌 Decide and update recipe naming and classification standards Needs review is still the most important next step. We can add conditional fields which appear for project maintainers when they have a recipe release. We need to know what organization will help site maintainers narrow down recipes which might be right for them.

As that comes together, we can make sure the indexing has a quick way of querying projects with recipe releases and get the API ready for project browser.

I’m not sure if this belongs here or 📌 Decide and update recipe naming and classification standards Needs review . That issue looks like it's about categorization that will land in the recipe code itself, which we can certainly parse and make searchable for browsing, if needed. Something like module categories might not be relevant to the code, and easier done as a field on Drupal.org.

A couple notes from Slack conversations:

Recipe browsing is likely going to stay separate from Module browsing. People searching for added site functionality need to first pick where to search, and results will be only recipes or only modules. This means we have more freedom to make the recipe & module filters different from each other.

In addition to the “site / starter / feature” distinction, we can also have the Access Control / Accessibility / Administration Tools / … → categories used for modules. Some common filters should remain as people will likely be flipping back and forth between recipe & module search.

https://drupal.slack.com/archives/C01UHB4QG12/p1728564448019179?thread_t...

📌 Decide and update recipe naming and classification standards Needs review has a decent three legged proposal for types, let's discuss there if there is anything in the way to adopt that :)