Deprecate text_with_summary

If this is still desired what would the alternative be?

The alternative would be to have two fields, a teaser/intro field and a text field. That gives you more control, like separate text formats and you can display them both on a page if you want.

That said, I have no idea how we'd achieve this today with our BC approach, we would need an upgrade path which could be absolutely massive for large sites.

I do agree that this would have been a good idea, but I think we should consider to close it, there are more important tasks.

I've been neglecting text module so trying to play catch up.

I'm for closing it

But could the upgrade be the summary goes to a auto generated text field and actual text goes into a regular non summary text field?

For display 0 idea how to handle that.

Yes exactly, that's how you'd do it. New field, move all summary content over to that. There are a bunch of differences though, like the text with summary has the summary as optional, so we'd need to include the runtime fallback of the summary to a cut of part of the regular text on migration.

But most sites that use paragraphs, layout builder and so on already deal with that, because text with summary is not something that you can really use there.

The problem is the amount of data that we're dealing with here. There are sites with a million nodes and they might have millions of revisions, we wouldn't just need to update the default revision but the full history as well. That would require either a very long downtime or a separate migration process that will gradually move data over while the site continuous to be used. But that also means that the site needs to be able to support both fields for that time.

So essentially the cost to reward is too great.

Seems this kind of update would be super problematic for a lot of sites at this point.

If anyone disagrees please reopen explaining how. Thanks

How to deprecate it:

1. Move the field type, formatter and widget to a module
2. Switch standard + umami to using 'long text'
3. Deprecate the module and move it to contrib

Existing sites would then need to use the contrib module, or do a custom update/migration to long text.

That would technically work, but we'd be forcing _every_ existing site to use that. body is a non-deletable storage field, even if you don't use the body field on any node type, you wouldn't be able to remove it (we could do some shenanigans and replace an unused storage field in an update I guess.

Updating standard and umami seems like something that we could do anyway. Probably should also introduce separate teaser fields then?

That would technically work, but we'd be forcing _every_ existing site to use that. body is a non-deletable storage field, even if you don't use the body field on any node type, you wouldn't be able to remove it

I think we could update the body field to persist_with_no_fields: false as one of the deprecation steps? Then sites that don't use it could delete it.

Updating standard and umami seems like something that we could do anyway. Probably should also introduce separate teaser fields then?

Umami doesn't use the summary, at all:

MariaDB [db]> SELECT body_summary from node__body;
+--------------+
| body_summary |
+--------------+
| NULL         |
| NULL         |
| NULL         |
| NULL         |
| NULL         |
| NULL         |
| NULL         |
| NULL         |
| NULL         |
| NULL         |
| NULL         |
| NULL         |
| NULL         |
| NULL         |
| NULL         |
| NULL         |
| NULL         |
| NULL         |
+--------------+
18 rows in set (0.001 sec)

The tags/articles/recipe pages use a cards/grid layout (although checking this, I just opened 📌 Umami views should use responsive grid Active because it doesnt use that), so don't show anything from the body field at all.

Standard still has various pages with teasers - we could do the two fields thing, or use the trimmed formatter, or possibly got further and add a card view mode + responsive grid in standard.

Opened 🐛 Don't use text_with_summary in Umami Needs review because for me that's a straight bug in Umami that it includes a black hole field in the content creation UX that doesn't show up anywhere if you try to use it.

> Updating standard and umami seems like something that we could do anyway. Probably should also introduce separate teaser fields then?

If we have time to update Standard, then a better use of that time would be 📌 Change Standard profile to use Media instead of image fields Active , where it's painful how out-of-date the architecture is.

So updating 🐛 Don't use text_with_summary in Umami Needs review I actually had to change a lot to use "field_body" since body seems to be hardset to be text_with_summary. This the approach we are going to want and take?

Would we then move that hardcoded storage to a contrib module?

Started a new META to track decisions that will be needed for this 🌱 [Meta] Deprecate text_with_summary Active

Closing as duplicate for the new META which is getting started :)