Change profiles/recipes to not use text_with_summary

Did a first pass here.

Lots of things here that I didn't expect in here from the title. At least migration IMHO really should be a separate issue, that's some complex stuff on its own.

I only skimmed over the actual profile/recipe changes, I've two bigger questions that I think we need to figure out:

1. What exactly is the scope of this? Just changing the type means we lose functionality. The ability to have a teaser text different from the content. In my opinion, This is a valuable feature that's worth keeping. We always add a separate teaser field in our node types (even for something like page, for metatags, search results and so on). But doing so will explode the number of changes we have to make here. New fields, form/view display changes, test coverage. It will also be a change from an optionally different teaser/summary (on HEAD, or an always automatically trimmed summary of the body) to an always different separate field. I honestly don't know what's better.

2. I've asked this in an earlier issue, but I don't think I got an answer. What is the BC policy for recipe configuration? For install profiles, I think it's fine, it can change. But for recipes, it's IMHO more complicated. They are meant to be building blocks, things that other recipes can build on (we specifically and explicitly support depending on core recipes). Does that make them an API? Does changing the field type of the body field make it an API break? If yes, this is going to be get complicated. Do we need new recipes? Versioned recipes? If no, then that makes things easier at first. But I think we might also break our promise on "recipes" being stable and reliable. As a distribution maintainer, I would not be comfortable relying on core recipes going forward and build my own. But I think that would again possibly be detrimental to the goal of recipes. IMHO, we need shared, standardized recipes and common concepts, so that we can for example also get to a point where we can have more and better standard themes that support a typical event or article node type. Long rant, goes way beyond this issue, as I think nobody really relies on core node type recipes, so maybe we can just close both of our eyes in this case. But in some ways, I think Drupal CMS already answered this question. Maybe core shouldn't ship recipes, not in the same package. Maybe that hardcoded special case that makes it possible to depend on core recipes, when everything else needs to be its own namespaced and separately versioned package shouldn't exist? Because if article_content_type were its own package, we could just make it v2.0.

I found it unusual that an Options module test fixture has Body field configuration. So I stripped the body field out of the fixture module and ran the Options tests. They all passed. I'd say we should get rid of the field entirely. My suggestion is that you revert the changes to the Options test config here and we open a separate issue for removing the field. Since I already have the changes pending here on my local environment I'd be happy to create the MR.

The rest of the changes look good to me, but when I ran a check for any missed text-with-summary-related stuff in core/profiles and core/recipes I found some mentions in demo_umami template docblocks. The files are:

• core/profiles/demo_umami/themes/umami/templates/classy/field/field.html.twig
• core/profiles/demo_umami/themes/umami/templates/components/field/field--node--field-cooking-time--recipe--full.html.twig
• core/profiles/demo_umami/themes/umami/templates/components/field/field--node--field-difficulty--recipe--full.html.twig
• core/profiles/demo_umami/themes/umami/templates/components/field/field--node--field-number-of-servings--recipe--full.html.twig
• core/profiles/demo_umami/themes/umami/templates/components/field/field--node--field-preparation-time--recipe--full.html.twig

You can also find them with a regex search for "text[-_]with[-_]summary".

Sure if you want to spin up the separate issue I can revert here tomorrow

I created the issue #3558939: options_config_install_test has unnecessary Body field.

Fair enough. I thought they might have been in-scope.

Feedback was addressed.

I think the options field removal could also fit here, but it's already RTBC, so that's works too.

It still feels wrong to me that we lose the ability to customize the teaser text with this on standard/standard recipes (No tests, which isn't surprising as we only have minimal test coverage of standard profile/recipes) I'm also still unclear whether or not this is a BC break for the recipes and whether or not recipes even have BC (and if they belong in core if not). We want to remove the node types and fields from core, and this change would be easier if they already were, but that's an even trickier change that will require more discussion. But I'm not going to push back on this and will leave it to others to find answers on that ;)

> I always understood the recipes for the standard profile to be more examples then anything.

That is valid take and possibly how it_should_ be. But the thing is that recipes explicitly support depending on core recipes.

See https://git.drupalcode.org/search?group_id=2&scope=blobs&search=core%2Fr...

This approach *only* works with core. Any other recipe dependency must be in the same folder or a standalone recipe project.

Various recipes out there specifically depend on core/recipes/basic_block_type or page/article node types, which we are now changing.

The blocker is in. I updated the fork to pull in those changes. Unfortunately, tests are failing due to changes introduced by #3551308: Combine single cardinality fields into a single database query when loading entities.

The latest change is just a simple removal of the summary subfield from the new queries, which is the whole point of this issue. The tests are back to passing. I'm setting this back to RTBC, per my prior review in #22.

I just updated credit.

On the content types, they will likely be removed from core as part of #3159848: [Policy] Always install Drupal with Standard on the UI, pared down of use case specific elements (content types, node listing, commenting, theme). I think it's OK to change them here, but could use a change record.

Committed/pushed to main and 11.x, thanks!