[Meta] Deprecate text_with_summary

The current logic was added in #553306: Make nodes have no body field by default. Remove deprecated APIs for body field as part of the field API conversion in Drupal 7. I personally think we could retire the auto-creation of the body field, and add a message to encourage people to create some fields after adding a new node type instead, but that's a fairly significant UX change so tagging for product manager review.

If we want to keep node_add_body_field() then to deprecate text_with_summary we'd need to change the field type it creates for new sites.

In both cases, we need to allow the field storage for 'body' to be deleted, so that sites with no instances are able to remove it and not rely on the eventual text_with_summary contrib module.

@smustgrave yes although there might not be much to update in that case?

Discussed this with @lauriii and @gaborhojtsy in slack. Both are in favour of removing the automatic creation of the body field for content types in general. That will need its own issue too (hopefully not too massive at least outside tests), but will also mean that the Umami changes made already are likely what will be needed, since the 'body' field won't be repurposed in general but just go away. Leaving the tag for now in case they want to add anything.

That all sounds good, I think we'll find out about migration when we get there!

In slack we discussed how the automatic body functoinality needs to be removed in starshot, that's #3447617: Stop automatic storage creation of body field for node. I think this boat is ready to push off gently.

Remaining tasks

1. Agree on what to do with 'body' special field, if it should be updated to use text_long storage or new one created.
2. Update Umami - #3425105: Don't use text_with_summary in Umami
3. Update Standard - #3447615: Update standard profile to use field_body
4. Stop automatic creation - #3447617: Stop automatic storage creation of body field for node
5. Move text_with_summary to new module - TBD
6. Deprecate that module - TBD

Adding the “Needs documentation updates” tag per Slack discussion with @lawrolan

#3447617: Stop automatic storage creation of body field for node landed already.

The most active issue at the moment is #3489266: Deprecate node_add_body_field(). I think it would probably make sense to get that one done first (haven't reviewed it yet though), and then see what's left for #3447617: Stop automatic storage creation of body field for node.

If we do those, we shouldn't need #3477043: Change automatic body field creation to use formatted text field instead of text_with_summary.

I'll admit though no idea how to change the storage type without breaking all the migration fixtures.

migrate fixtures are about setting up the *old* site. That doesn't change, D6/D7 will always use text_with_summary, unless we invent time travel. So we don't have to.

what we would need to change is to what we migrate it *to*, we'd need to split it up into separate fields, summary into a field and main body into another. Including the special marker in content and split off from there. But since migrate_drupal is also being deprecated, we can just let contrib deal with that. That can continue to depend on a text_with_summary contrib module or it can attempt to do this.

We can't do both #3477043: Change automatic body field creation to use formatted text field instead of text_with_summary and #3447617: Stop automatic storage creation of body field for node, they're mutually exclusive. BUT, what we need is an issue for standard profile to create a separate teaser and body field instead, same for the recipes, umami and so on.

Given #3315257: [meta] Tasks to deprecate Migrate Drupal I think it would be fine if we continue to migrate into the deprecated field, then the field itself could only be removed in Drupal 13 at this point, and migrate_drupal will already have been removed in Drupal 12 at that point.

Can we start the new module that will hold the plugin but not deprecate it yet? So we can move any migrations and tokens to it? Or does the module need to be added deprecated?

I would think it cannot be deprecated until there is a replacement, and that replacement would be the contrib module. The contrib module would not exist until the core module exists.

1. Convert the storage.body fields we just moved to be text_long vs text_with_summary. Probably can do this in one ticket but can see the argument to breakup. But 0 idea how to address migration

It's not just changing the type. We do want a comparable feature of having teasers I think, even on standard. Also as an example on how you'd do that. Not sure if umami has something like that too. That means we need a separate new field_teaser_text or something like that, set up form and view displays, update tests. Should that be a plaintext field or one with a format? Not sure. In our distribution, we plan for customization and make it a text with format, but by default limit it to plaintext. That feature is in core now.

Not sure if umami has something like that too.

Umami completely avoids this by using field_body fields (not body), a separate summary field for recipes, and card layouts instead of teasers. text_with_summary isn't used at all.

For the standard profile, I think we should be removing the content types (because Drupal CMS has content types), although this needs product manager review. #3159848: [Policy] Always install Drupal with Standard on the UI, pared down of use case specific elements (content types, node listing, commenting, theme) is the closest issue I could find this morning.

There's already an issue to remove text_with_summary from the page content type though at #626546: The body field on the Basic Page content type should not allow a summary to be input.

sounds like umami already does exactly what I'm proposing for standard, so that shouldn't need changes at all, makes sense. we also didn't have to change it in the field storage issue I think.

Yes, I would assume that standard would only add such a teaser field to articles and not page, solving the page node type summary issue you referenced.

Removing those node types completely does sound like a sensible direction considering we have Umami and Drupal CMS, but also sounds like a more complicated change than adding a teaser field. you can still somewhat use standard as an evaluation of the basic capabilities of Drupal. Removing Page and Article would definitely add many non-trivial steps to that. So I'm certain that's going to result in some concerns.

I think a separate summary field for standard is fine, it's just that if/when we remove the content types it will be gone again, but yes that might be an easier/quicker change to make to unblock further progress here.

Will the new contrib use this namespace?

https://www.drupal.org/project/text_with_summary