Verify all Drupal CMS recipes should be available in Project Browser post launch

drupal_cms_search is a weird one because it appears in the drupal_cms_starter recipe's composer.json file but not in the recipe.yml file - maybe this is an oversight?

I agree that drupal_cms_ai, drupal_cms_analytics, and drupal_cms_multilingual should all be available in Project Browser.

-mike

These things aren't oversights.

• drupal_cms_ai and drupal_cms_analytics need input at apply time, and Project Browser has no UI for that yet. (There is a proof of concept in progress but it hasn't been committed or released in Project Browser.) AI in particular is tricky because its API keys need special handling that isn't supported by the recipe system.
• drupal_cms_search might be applied by the starter recipe, which is why it's in the composer.json file. I think there are one or two blockers before we do that, though. If it doesn't make it into the starter recipe by release time, I'm guessing it will either be added to Project Browser, or hidden outright. This is a product-level decision.
• drupal_cms_multilingual is not released at all, and it isn't part of the current Drupal CMS build. There is no project for it. This was due to reasons very much beyond our control (the track lead became indefinitely unavailable and hasn't, as far as I know, been replaced yet).

Thanks, Mike and I were chatting and we didn't want to assume.

1. So is https://git.drupalcode.org/project/drupal_cms/-/tree/1.x/recipes/drupal_... from the prototype? Should we remove that altogether?

2. Probably a product-level decision, but do we want to allow for the recipes that have already been applied to be re-applied? This could be useful if you (or your AI agent) messed something up.

So is https://git.drupalcode.org/project/drupal_cms/-/tree/1.x/recipes/drupal_... from the prototype? Should we remove that altogether?

It's largely from the prototype. There may have been a few changes since then. I discussed removal with @tim.plunkett and we decided against it, since once a new track lead is found, work on that track should hopefully resume. There didn't seem to be much sense in removing it; it's not doing any harm by its presence.

Probably a product-level decision, but do we want to allow for the recipes that have already been applied to be re-applied? This could be useful if you (or your AI agent) messed something up.

Well...there's no way to prevent a recipe from being reapplied. Project Browser doesn't expose the functionality, but that's a bug which is going to be fixed by ✨ Allow recipes to be re-"installed" (re-applied) inside PB Active .

So is the plan that both drupal_cms_ai and drupal_cms_analytics will be apply-able in Drupal CMS 1.0 only via the command line? Or is that TBD?

-mike

TBD but this is all currently by design. Search works functionally but has no styles, so we don't want users applying it until we've fixed that. Ideally we will have the recipe inputs available for v1 but even if we don't, I think we'll expose the recipe, perhaps just with a prompt telling them what to do next.

But, definitely not an oversight. What is in PB now is what we want users to see. We will never want to expose the starter/base recipes in PB as part of Drupal CMS, it would be extremely confusing. Recipes that require them will depend on them behind the scenes. Perhaps at some future date when we have a killer UI, we would show recipes that come pre-applied (e.g. basic page) for users to browse or reapply, but this is not a priority for v1.

As for multilingual, this definitely is out of scope for v1 but I think @phenaproxima wanted the project created for infra reasons. Whether we remove the reference to it altogether is a tech decision I guess.