Model core's Umami install profile as recipes

I'd like to postpone this on #3417835: Convert the Standard install profile into a set of recipes. If we can convert Standard to recipes, then we can attack Umami, which is a far more complicated install profile that even touches on the need for default content. :)

Not only that, it's possible that a recipized(?) version of Umami could reuse some of the recipes that make up Standard.

Not only that, it's possible that a recipized(?) version of Umami could reuse some of the recipes that make up Standard.

Shouldn't we take this into account while converting Standard to a Recipe? 🤔 For example for the article and page node types, as well as the various media types?

Shouldn't we take this into account while converting Standard to a Recipe?

Well...sure...but IMHO, converting Standard to recipes is a big enough undertaking even without having to think about Umami. We can keep Umami in the back of our minds, but it's not a priority right now.

Let's get Standard converted, and committed, first. Then see what we can reuse from it without any modifications. (I'm guessing most of its tangible content and media types will fall into that category.)

Just fixing what looks like copy-paste hangovers in the summary - Standard ➡️ Umami in text and standard ➡️ demo_umami in config links.

#5 👍

The Umami profile substantially extends the editorial workflow compared to what's in Standard, so I think we'll probably want to have some config actions available to manipulate Content Moderation workflows before we do this. The only one currently open is #3422821: Add a config action to add entity types and bundles to a Content Moderation workflow, and we'll need that one, so blocking this on that.

Hey, look...#3417835: Convert the Standard install profile into a set of recipes is in!

Umami also ships content, of course...but #3292287: Extend recipe runner to create content provided in the recipe's /content folder is in a reviewable state, now. So blocking on that one too.

I was thinking about this a bit and it occurs to me that converting Umami to a set of recipes is a much different circumstance, and therefore has different goals and design decisions, than converting Standard.

The recipes that make up Standard are meant to be generic, reusable parts -- the kind of things you'd likely need on any site. Umami is a lot more specialized. Do we really expect, for example, that most (or even many) sites will want to have a "recipe" content type, set up in the specific way Umami does it?

To me, this means we should take a different approach in reconstructing Umami as a recipe. Namely - I think the Umami recipe can be less composable, because it's intended more to be a self-contained demo than a set of reusable parts. We should carefully consider which parts of Umami should be extracted into smaller, useful recipes that could be cherry-picked into other sites...but I suspect it will yield fewer building blocks than Standard did, and the main Umami recipe can and will be quite large and complicated.

But that's okay, because an architecture like that is in line with Umami's purpose.

Some thoughts on how to split up Umami:

• The block types (banner, basic, disclaimer, and footer promo) should be reused from Standard (basic_block_type) if possible, but should all be individual recipes.
• The Page content type, and all media types, can probably be reused from Standard (or lightly modified, if needed, by the main Umami recipe).
• The "card" view mode for nodes should be its own recipe. I can imagine that being very useful.
• The recipe content type should be its own, well, recipe. Although we might want to call it umami_recipe_content_type, to make it very clear that this content type was specifically designed for Umami.
• All of Umami's image styles and associated media view modes should be part of a single recipe called umami_image_styles (or similar). It should include the responsive image styles.
• The "author" and "editor" roles can be part of the main Umami recipe.
• Umami's Article and Page content types use Layout Builder. This, to me, is a great chance to have a layout_builder_content recipe, which applies LB to all content types! (We could use the new "add field to all bundles" config action for this; we'd probably also need a new LB-specific one that flips the enableLayoutBuilder() switch on entity view displays.)
• Every Umami content type has translation settings. I think this calls for a new config action, similar to "add field on all bundles" - "make all bundles translatable"!
• Everything about the Umami front-end -- blocks, theme configuration, etc. -- should be part of the main Umami recipe. So should all the content.

More ideas may be forthcoming, but this is just an initial brainstorm.

#12 sounds like a nice proposal to me! 😊

#3422821: Add a config action to add entity types and bundles to a Content Moderation workflow is in.

The final blocker -- the ability to import default content -- is in!

Let us continue here. :)

The recipes that make up Standard are meant to be generic, reusable parts -- the kind of things you'd likely need on any site. Umami is a lot more specialized. Do we really expect, for example, that most (or even many) sites will want to have a "recipe" content type, set up in the specific way Umami does it?

I'm in two minds about this - I agree that there are very few bits of Umami that would be re-usable.

However, Umami is also supposed to be a showcase of what can be done with Drupal core and a bit of theming, so if we include recipes in 'what can be done with Drupal core', it might make sense to have the recipes more composable so that it's easier to see how it was put together? I don't know if we'll show installed recipes in a UI somewhere, but if we do, then having Umami made up of smaller recipes would appear in that UI for example, or just if people are looking through the code base to see how it was done.

fwiw I don't think #3425104: Umami views should use responsive grid needs to be a hard blocker here, we could do it after a recipe conversion too, but also it's nearly ready and just needs review. Didn't realise there was already progress on this issue.

#3425104: Umami views should use responsive grid is in.

Seems like this would need https://www.drupal.org/project/default_content/issues/3160146
As the latest version of umami has layout builder on by default though it does not use it much since most of the content is in the body field.

Are there any nodes in Umami that customize their layout? I think not:

MariaDB [db]> SELECT * FROM node__layout_builder__layout;
Empty set (0.001 sec)

I think that means that, in its current state, Umami does not need #3160146 in order to have its content saved in the default_content format used by recipes.

I was hoping that Umami would configure its display modes to "Use Layout Builder" but not "Allow each content item to have its layout customized." Unfortunately, the Full Content display mode of each content type has both options selected.

Added a default content recipe that replaces the demo_umami_content.
To test it one can comment on this line.
\Drupal::service('module_installer')->install(['demo_umami_content'], TRUE); on demo_umami.install
and then run a
ddev drush site-install umami
ddev recipe ...
It's missing these blocks added to the block layout. Those I will probably add to the config install folder or even better as a config action. they are a custom block that's placed on the block layout.
# block.block.umami_banner_home
# block.block.umami_banner_recipes
# block.block.umami_disclaimer
# block.block.umami_footer_promo

There's one little glitch left where exported entities that have translated content end up with different IDs for the same resource (image, pdf). This results in the Spanish version of Umami having no images. Even though the English one has them all. This seems like a default content bug though.
Seems related to this.

https://www.drupal.org/project/default_content/issues/2947220

It would be really great if the work is not lost here but can be applied to the contrib copy of Umami following #3523324: Deprecate and remove the Umami demonstration profile from core, make it a contributed site template, would that still be possible? It would be sad to need to restart this and Umami as a contrib site template would need it to be based on recipes.

Umami contrib for me means one of two things:

1. It moves under Drupal CMS as a default/example template there

2. It moves fully to contrib and is maintained there, then appears in the site templates section.

It should be possible to open a contrib umami recipe project with the contents of the recipe. The really challenging thing regardless of where it lives will be updating the Umami theme + layouts to be based on experience builder.

I think the theme + layouts update to XB should be done later assuming we can lift and shift Umami to contrib in a working way :) Especially if the recipe conversion works. I don't think we need to build it necessarily to have reusable components outside of it. But food blog is not a site template currently being built for Vienna, so it could be a great contrib one. It could be one of the first if not the first contrib template since we already have the site itself figured out all with images and sample content :) It would be unfortunate to not to rescue it in the tumult around Drupal CMS and site templates :)

I think the way to do that then would be to create a new demo_umami contributed theme, and a new umami general project recipe based on the work here. Once the policy issue is agreed, that could start alongside the gradual deprecation of Umami in core (which probably will have to work differently to how we've deprecated modules/themes anyway).