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

So once 📌 Stop automatic storage creation of body field Active lands I'm thinking next steps would be to

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
2. Opened 📌 Stop automatic storage creation of body field Active .
3. Then would imagine we are good to move the text_with_summary plugin to it's own module to be deprecated.

Thoughts?

Got 3 issues up for review lets land those then figure out next steps

Just thinking next after these 3

1. Convert all profiles and recipes to not use text with summary
2. 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?

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.

Makes sense and actually means probably can start it soon once we do a few more steps!

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, 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. ✨ Add a basic but usable install profile for building a site from scratch Active 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 📌 The body field on the Basic Page content type should not allow a summary to be input Needs work .

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

That’ll be my next step.

Do we think we are at a point we should start the text_with_summary module and move the plugin to that? We can make text depend on it for now