Problem/Motivation

#1378350: Clean up the "Long text and summary" field has a list of some of the issues with text_with_summary

#2725415: Text Editor module fails to track usage of images uploaded in text_with_summary fields, allows uploaded images to be deleted is a current example of it causing data-loss - editor module has to hard-code support for the double-column field.

We've had usabiity problems with this ever since #107061: Add jQuery Teaser Splitter, and then with the <!-- break --> tag before that.

Display modes didn't exist when this was originally added, and the field type for me is a case of 'port the feature verbatim to the new API' without necessarily taking the time to consider whether the feature should still exist. With display modes, this isn't really necessary any more.

Long-standing issues:

It's also been responsible for data loss in the past with #2725415: Text Editor module fails to track usage of images uploaded in text_with_summary fields, allows uploaded images to be deleted which required special handling in editor module.

Proposed resolution

How to deprecate it:

1. Switch standard + umami to using 'long text'
2. Change the body field to persist_with_no_fields: false so it can be deleted on sites that don't use it.
2. Move the field type, formatter and widget to a module
3. Deprecate the module and move it to contrib

Remaining tasks

User interface changes

API changes

Data model changes

Comments

catch created an issue. See original summary.

Berdir’s picture

Berdir
Primary language German
Location Switzerland
CreditAttribution: Berdir at MD Systems GmbH commented

This was also discussed a bit in #2150511: [meta] Deduplicate the set of available field types and I thought I've seen another issue about it too

Interested in this, but there are going to be a lot of things to figure out. For example, the body field.

Body is automatically created, we can't just switch that. We also can't really make it configurable, since the field storage for body is default config of node.module and always created, very early.

I know the install process is not part of the API (although it's not exactly clear to me how much that includes), and we could also argue that configurable fields aren't. But while code does have to cope with the fact that body may or may not exist (and at least in 7.x, we still have core bugs in comment.module about that AFAIK), if it exists, there is lots of core, contrib and custom code assuming that ->summary exists.

I guess we'd have to keep body as text with summary but don't allow to create more fields of that type?

catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch at Third and Grove commented

But while code does have to cope with the fact that body may or may not exist (and at least in 7.x, we still have core bugs in comment.module about that AFAIK), if it exists, there is lots of core, contrib and custom code assuming that ->summary exists.

You can quite reasonably delete the body field, recreate it as text long with no summary, and then assign it around. I've done that before in 7.x, so that code is already broken no?

However I think we should definitely make this a multi-stage issue, and make worrying about that bit the last stage.

Wim Leers’s picture

Wim Leers
Location Ghent 🇧🇪🇪🇺
CreditAttribution: Wim Leers at Acquia commented

In the name of the flying spaghetti monster, yes please!

yoroy’s picture

yoroy CreditAttribution: yoroy at Roy Scholten commented

I'm all for it! It's a weird Drupalism, superseded by fields + view modes, which is the right way to do this now.

Bojhan’s picture

Bojhan CreditAttribution: Bojhan as a volunteer and commented
Issue tags: -Needs usability review
yoroy’s picture

yoroy CreditAttribution: yoroy at Roy Scholten commented
Assigned: Unassigned » webchick

@webchick, what do you think?

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
CreditAttribution: webchick at Acquia commented
Issue tags: -Needs product manager review

Sure. :)

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

joel_guesclin’s picture

joel_guesclin CreditAttribution: joel_guesclin as a volunteer commented

What to do about an existing site?
I'm beginning to ramp up to migrating to D8 from a D6 site with upwards of 4000 nodes (book pages mostly) which of course uses the Body+Summary.
What to do?
If the summary is deprecated (and anyway not very usable because it doesn't get the CKEditor), then if I migrate my present site into D8, and follow Wim Leers' advice by creating a special field for the summary, what will happen when the body_summary gets not merely deprecated but removed? Ideally, when that happens, I think I would like to be able to choose the field that the summary gets moved into. But at least for a while it seems that the summary presently held in "body_summary" will have to co-exist with the new "Summary" field.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

smustgrave CreditAttribution: smustgrave at Mobomo commented

If this is still desired what would the alternative be?

Berdir’s picture

Berdir
Primary language German
Location Switzerland
CreditAttribution: Berdir at MD Systems GmbH commented
Assigned: webchick » Unassigned

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.

smustgrave’s picture

smustgrave CreditAttribution: smustgrave at Mobomo commented

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.

Berdir’s picture

Berdir
Primary language German
Location Switzerland
CreditAttribution: Berdir at MD Systems GmbH commented

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.

smustgrave’s picture

smustgrave CreditAttribution: smustgrave at Mobomo commented

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.

smustgrave’s picture

smustgrave CreditAttribution: smustgrave at Mobomo commented
Status: Active » Closed (won't fix)

If anyone disagrees please reopen explaining how. Thanks

catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch at Third and Grove commented
Title: Deprecate text_with_summary and hide it from the UI » Deprecate text_with_summary
Status: Closed (won't fix) » Active

How to deprecate it:

1. Switch standard + umami to using 'long text'
2. Move the field type, formatter and widget to a module
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.

Berdir’s picture

Berdir
Primary language German
Location Switzerland
CreditAttribution: Berdir at MD Systems GmbH commented

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?

catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch at Third and Grove commented
Issue summary: View changes

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 #3425104: Umami views should use responsive grid because it doesnt use responsive grid yet), so don't show anything from the body field at all. This is a very good example of how it's not useful on a lot of sites, and introduces confusion on sites that don't change the defaults but end up not actually using the feature - we've even done it ourselves in what's supposed to be a demo/showcase.

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.

catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch at Third and Grove commented

Opened #3425105: Don't use text_with_summary in Umami 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.

catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch at Third and Grove commented
Issue summary: View changes
catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch at Third and Grove commented
Title: Deprecate text_with_summary » [meta] Deprecate text_with_summary
Issue tags: +Needs product manager review
joachim’s picture

joachim CreditAttribution: joachim at Factorial GmbH commented

> 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 #3258492: Change Standard profile to use Media instead of image fields, where it's painful how out-of-date the architecture is.

smustgrave’s picture

smustgrave CreditAttribution: smustgrave at Mobomo commented

So updating #3425105: Don't use text_with_summary in Umami 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?

smustgrave’s picture

smustgrave CreditAttribution: smustgrave at Mobomo commented
Title: [meta] Deprecate text_with_summary » Deprecate text_with_summary
Status: Active » Postponed

Started a new META to track decisions that will be needed for this #3427095: [Meta] Deprecate text_with_summary