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.

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 in an indirect way. IMHO, converting Standard to recipes is a big enough undertaking even without having to think about Umami.

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, then 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 specifically the way they are set up in Umami?

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 can be extracted into smaller, useful recipes that could be cherry-picked into other sites...but I suspect the main Umami recipe can and will be very large and complicated. That's okay, though, since 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), and 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.)

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. :)

We should set a precedent here for having default content in its own recipe. Of course, it can be applied as part of umami/recipe.yml, but it should also be able to be applied independently.

Why? I can apply a recipe on my local machine, export the config, unpack and remove a recipe (if contrib), and then push all my changes to a development, staging, or live environment. In that workflow, the content would not get pushed with it.

If we define the idea of a recipe that is content only, that could get pushed up as part of the code base and applied on subsequent environments.

I see many benefits from this, from prepopulating demos, to configuring baseline functionality, and content for quality assurance.

@catch wants 📌 Umami views should use responsive grid Active merged into Umami before the recipe can be completed.

Other work can be done to this issue, just not that view.

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 📌 Umami views should use responsive grid Active 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.

📌 Umami views should use responsive grid Active is in.

Seems like this would need https://www.drupal.org/project/default_content/issues/3160146 ✨ Add a Normalizer and Denormalizer to support Layout Builder RTBC
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
It's missing. Those I will probably add to the config install folder later.
# 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 into different files. This results in the Spanish version of Umami having no images. Even though the English one has them all. This might be a default content bug though.

Moving to Drupal core. Merge request will need to be moved also.