Install fails in Drupal CMS

A little more information, applying the recipe will fail when run against Drupal CMS, but will work when applied to a site installed from the standard install profile.

The reason, is that the Locations recipe is dependent on a "Body" field existing with the machine name "body". That field no longer exists in Drupal CMS thanks to #3489785

The changes in this merge request should fix sites that don't have an existing text_with_summary body field, for example if they were created using the minimal profile.

If the goal is really compatibility with Drupal CMS, that may require a separate branch, or even a separate project. Unfortunate.

Compatibility with CMS recipes for recipes is ideal.

In theory, if a recipe works with minimal, it should work with CMS, although the types added will have body as a field name instead of content. An ideal solution would be to update standard from body to content rather than to do it in CMS.

@mandclu, what would you think of using recipe inputs → to give options when applying the recipe.

As I look through the change record, I'm not fully convinced it will be a better user experience, but it feels like we need something in this space to prevent the creation of an old style "body" field on new Drupal CMS install that is trying to apply the recipe.

This is kinda an interesting conundrum. If you did split it to a separate repo, would it be assumed that we would need a drupal_cms_locations for compatibility—and possible inclusion—with Drupal CMS. (Are projects within the drupal_cms_* namespace restricted somehow? 🤔

Just a drive by comment, but there might be a completely different "solution" for this: Don't include a body field at all.

The reason Drupal core is phasing out the (automatically added) body field is that it's in many, many cases replaced with a different content building mechanism. Paragraphs, layout builder, experience builder and so on.

Is a body field crucial to this recipe? Or could you just say that site builders likely know how to add such a field if they want to add more content to their locations and will do so using whatever tools they are used to.

For the Locations recipe, the field is called "Description". It could easily be field_description, body (if present), field_content, or something else clever and less common. Regardless of the name, I doubt all sites would want paragraphs/layout builder/experience builder for a location description that is typically a few paragraphs of text.

To counter the argument for using page building on many/most Drupal sites, some sites just need the ability to insert structured HTML, the last three government sites I architected used a strict landing page model and a few simple templates in CKEditor for most other content types. CKEditor can do that pretty well if you stick to common HTML and maybe a few alignment styles for media.

I have built more than a few sites with page builder and layout builder variations. While they have their place, I don't used them for more than a page or a landing page content type if I can help it. The performance costs of comparing content or using the usage module or just dealing with the editor experience slowness are often not worth putting those solutions on every content type.

Now that CMS exists and it's the primarily promoted way to use Drupal on the home page, it's important that projects work on CMS.

Hopefully we can solve for small machine name mismatches between Standard profile and CMS. If we can't solve it in a single release, then a CMS specific release for Recipes would be a start.