[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.

I imagine if we keep the body field and change it to create a text long storage we will have to update umami and standard at the same time.

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

It definitely would be far less. Think for umami it would of been a fraction of the file changes needed

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.

Slightly sad to see the auto creation go away but fully get it. I usually end up deleting it for new content types anyway. I do wonder about the contrib impact though.

hopefully not too massive at least outside tests

I'm scared to look

Will let @laurii or @gaborhotjsy chime in, once they do I suppose we can un-postpone the Umami ticket.

Open a ticket for updating Standard to use field_body instead

Open a ticket to drop the auto storage creation of body (sure this will be a large ticket).

Open a ticket for creation of a new module (text_with_summary) and move the formatters to that.

Sound like a good order?

Anything with migration that needs it's own ticket?

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 📌 Stop automatic storage creation of body field Active . I think this boat is ready to push off gently.

Remaining tasks

2. Update Umami - 🐛 Don't use text_with_summary in Umami Needs review
3. Update Standard - 📌 Update standard profile to use field_body Active
4. Stop automatic creation - 📌 Stop automatic storage creation of body field Active
5. Move text_with_summary to new module - TBD
6. Deprecate that module - TBD

#2 for Umami is up for review, that one was easy

But while working on the Standard profile removal ticket discovered a TON of migration failures are now happening. And after speaking with @larowlan seems that we will need to

1. Create the deprecated module that will house the special "body" field and text_with_summary plugin.
2. Update migrations to use that deprecated module instead
3. Then we should be good to remove the auto creation and from Standard profile.

Thoughts?

wanted to bring this up again which would be the next ticket that needs to fall?

📌 Stop automatic storage creation of body field Active or 📌 Change automatic body field creation to use formatted text field instead of text_with_summary Active

📌 Stop automatic storage creation of body field Active landed already.

The most active issue at the moment is 📌 Deprecate node_add_body_field() Active . 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 📌 Stop automatic storage creation of body field Active .

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

So working on 📌 Stop automatic storage creation of body field Active but imagine we will still need to do 📌 Change automatic body field creation to use formatted text field instead of text_with_summary Active after so we can then deprecate the plugin right?

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

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 📌 Change automatic body field creation to use formatted text field instead of text_with_summary Active and 📌 Stop automatic storage creation of body field Active , 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 📌 Tasks to deprecate Migrate Drupal Active 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.