Add a flag and listing page for recipes

A flag isn’t needed, we already have data on what’s a recipe since ✨ Add composer release type field Active

Any listing will not have a chance to be good until ✨ Add tracking for when recipes from Drupal.org are applied Active moves forward. We can only sort by data we have, like alphabetical or last updated date.

Thanks @drumm, FWIW I definitely think there is value in having the listing page before that lands, as most recipes will be brand new for now. But I will try to move that forward as well.

@pameeela - Is there any part of 📌 Decide on naming convention on recipes Active that could move forward with this? For example, a way for recipe maintainers to select “Site starter” or “Site feature”?

I see categories in the issue summary, does this mean they have the same https://www.drupal.org/docs/develop/managing-a-drupalorg-theme-module-or... → categories as modules?

The immediate next step will be adding a hidden field on general projects in D7 which rolls up the project’s releases’ composer types into a multivalued text field in anticipation of conditional field(s) for projects that have releases that are recipes. I initially thought this would be done only for search indexing, but we’ll likely want this data always available on general project nodes without rummaging through all releases.

We’re tentatively planning on taking a little extra time to build the actual browsing pages on new.drupal.org from the start, rather than building it twice.

@drumm great question re: category, I was not even thinking, but of course the field is not on general projects.

I'll try to get consensus on this. I do think the module categories will be applicable, as in many cases recipes are providing an optimised setup for a single module or a few modules.

The separately, we can try to resolve the classification. I wouldn't block this on those tasks, but I think we should be able to decide at least on reusing the categories pretty quickly.

I’m thinking the same module categories would be good to have for consistency in browsing projects, whether there is a unified module & recipe search, or switching between the two modes.

Agreed, no objections raised on Slack either.

The work in D7 is done, maintainers with a release that is a recipe can select categories when they edit their project. (We are getting away from “project types” whenever we can, projects change types between releases.)

We are building the recipe listing in new.drupal.org, so that part does not have to be built twice. The next step is ✨ Migrate new project_general fields for recipe browsing Active

Fields added to the new site (private repo for now):
- Composer types: https://gitlab.com/drupal-infrastructure/sites/drupalorg/-/commit/b19914...
- Project categories: https://gitlab.com/drupal-infrastructure/sites/drupalorg/-/commit/7e7ebd...

The rest will be done in the migration issue.

Going to leave this open for building the browsing UI on new.drupal.org. That will need to be backed by search API for full text search, so there might be additional steps to getting all the requirements ready.

I’ve started work on the next phase here - configuration updates to get general projects indexed.

Discussion mentioned in #7

https://drupal.slack.com/archives/C2THUBAVA/p1743738585491189