Switch the body field back (again) to text_long

I’ve replaced all instances of text_with_summary with text_long across the site. The necessary field display and teaser settings have been updated. Please review and let me know if any further adjustments are needed.

Hi, I'm still unsure how to apply this patch. I think there should be separate patches for different recipes.
However, when I tried to apply the patch's changes on my local machine, they did not work.
Attaching a screenshot for more reference.

For more reference on the changes to be made - we should follow https://www.drupal.org/project/drupal_cms/issues/3488706 📌 Switch the node body field back to a text_with_summary field, and hide the summary everywhere it appears Active

Moving to need work.

Now that the release candidate is out, this should be unblocked.

Unfortunately a0ef7458 no longer reverts cleanly.

Ready for a review!

I discussed this with @pameeela in Slack: https://drupal.slack.com/archives/C07G41EUJP4/p1733715878609979

As I understand it, "compatibility with Standard" is not a mission-critical aspect of Drupal CMS -- but I think it's something we need to anticipate and support because our recipes are available as individual components, and part of the appeal of using recipes is the potential to mix and match those components into existing sites, many of which will be built on Standard. Therefore, we have to think about how our content type recipes will interact with existing content types that come from Standard (or indeed, existing content types at all).

My feeling is that the correct approach is to respect existing content types as much as possible. Because recipes are unconditional by design, we can't stop the recipes from adding their additional fields to the content types...but we don't have to expose those fields on entity forms or displays.

So if you have a site built on Standard and it already has a Page content type, and you apply the drupal_cms_page recipe, what will happen? Well, the Page content type will get several new fields (field_tags, field_featured_image, etc.), but they won't show up on your entity forms or view displays. That at least keeps the existing editorial experience, at the cost of creating a messier set of fields. But the fields don't need to be used; they will just sit there until they are deleted by the site builder. Not an ideal situation, but better than imposing strong opinions into the preexisting editor experience.

So I think this is about as ready as it's going to be. I can add some test coverage to drupal_cms_page to confirm what happens when you apply this recipe on top of Standard, since Page is the only content type that we provide which is also part of Standard.

We will need to change text_with_summary to text_long in standard if we're going to deprecate text_with_summary.

And fairly soon, maybe as soon as 11.2, deprecate the standard profile (or remove the content types from it) in favour of Drupal CMS.

We will need to change text_with_summary to text_long in standard if we're going to deprecate text_with_summary.

And fairly soon, maybe as soon as 11.2, deprecate the standard profile (or remove the content types from it) in favour of Drupal CMS.

Since recipes are experimental, and ephemeral, couldn't we adjust core's recipes to the new content structure Drupal CMS has defined? Then Drupal CMS could be rewritten to extend those. That would lead to a bigger benefit for the community for standardization and entity conformity without forcing all users into Drupal CMS, which is being built specifically for marketers.

I'm sure we could alter core's recipes, and Drupal CMS could build on those when it's feasible, but I think that would be a longer-term thing that would happen on core's "schedule", which is obviously much slower than Drupal CMS's. We are faster-moving and indeed, the ephemeral nature of recipes means that we have some freedom to improve things into the future without being tied down by past compromises.

Right now the standard profile isn't using the standard recipe, they exist in parallel, but there is also test coverage to ensure they're identical, so we'd need to change a fair bit.

Yep I'm happy with this, it's kind of a weird compromise but still moving in the right direction.

Merged into 1.x, thanks everyone!