Clean up the "Long text and summary" field

+1

I don't think that you can replicate the behavior of the long text and summary functionality easily or in a reasonable amount of time.

We've (unintentionally or not) killed the --break-- splitter tag already. By removing this field type, we're removing the last simple option for users that achieves this very common functionality.

I agree with @sun; it's not clear how removing this makes things simpler. You'd have to create two fields, then go to Manage Display and configure one to be hidden on teasers and the other to be hidden by default... that's a number of non-obvious steps.

Plus, that's not even a complete replacement, is it? With "long text and summary", I can, for example, create two blog posts on my site and allow the summary to be auto-generated for the first one but decide I want to give the second one a special, custom-written summary. That seems like important functionality, and I don't immediately see how you can do that with two separate fields.

@sun and @David_Rothstein,

So why not move this functionality to contrib and let people intentionally decide they want to ADD the functionality.

Automation has its costs.

Replicating the end result without the automation is conceptually very simple when the fields are separate. In order to create "show summary in full view" you simply copy and paste from the body into the summary.

I think the UI is much better in Drupal 7 than 6, but it's still conceptually very hard for many of my clients.

Why not make it contrib?

Shai

As @David_Rothstein already mentioned,

"Add two separate fields" is not the purpose of the text_with_summary field type.

If that was the purpose, it would be kinda silly, and yes, if that was the case, we'd better remove it.

No, text_with_summary solves a couple of use-cases, that cannot be solved easily otherwise; e.g.:

1. You write an article. One full text body. You want to see an automatically generated summary out of the body in article listings.
2. You write another article. This time, you realize that it directly starts to talk about in-depth details. You want and need an explicit summary that is shown instead of the automatically generated summary in article listings, but only for this article. The body is not shown in listings.
3. You write a third article, but it's a short notice only. The body is going to appear as summary. Summary and body are identical.

The only way that would allow to "easily" replicate that functionality would be the introduction of field-instances-per-entity — i.e., if you need an explicit summary, you add explicitly add the summary field to a particular entity (not bundle) on the fly. However, work on that hasn't even remotely started yet.

And even with that (larger challenge), the body wouldn't be automatically hidden in article listings, so end-users would have to configure a lot to get their content to show up as commonly expected.

Interesting discussion.

1. I have heard from multiple content editors that the automatically generated teaser is mostly useless there. The first x characters of a post usually do *not* capture its essence. It's convenient to have an automatic cut-off + read more link, but beyond basic blogging it doesn't really answer the 'needs a summary' goal.

2. A custom summary. I agree it may be a bit more work to set up the display for body and summary across display modes, but at least that would make it consistent with how things work in Field UI instead of the current custom behavior. Only for this article is handy to have, but debatable if core should provide it.

3. I don't understand this one. If summary and body are identical then why talk about there being two things? This is same as 1. where body length is within auto-teaser length, right?

Lets chew on this a bit more, I don't think the extra work in initial setup weighs up against the current, relatively obscure implementation.

@sun in #6, you are presenting the use-cases to be much more complicated than they are.

One could use any of the following work-flows for any individual node of a particular content-type which has the same generic set-up of two long-text fields, one for body and one for summary. The numbering follows @sun's use-cases:

1. Enter body. Select, copy and paste desired summary from body field and paste into summary field.
2. Enter unique summary. Enter unique body.
3. Enter summary. Select all from summary, copy and paste into body field.

[Personally I would put the summary field after the body field on the node/add form, but this is a minor point.]

Shai

-1 as I'm not at all convinced.
The rationale asserts the field had "outlived its usefulness" without any explanation why that should be. The five issues referred to in the initial post certainly don't underpin this argumentation - they're just calling for some UI refinement. So I'd say this complex field is still as useful as it has ever been.

And as sun and David said, the functionality is not something users can configure instead. Configure display settings here and there might be okay, but then there's still the need to copy and paste.
In the end, the functionality could certainly live in contrib, were it not used by articles in the standard install. So Shai's other comment proposing instead

to add to the standard installation profile an imitation of the long text with summary functionality using only two long-text fields.

just turns into another argument against this move. Can't see why this would make things more straightforward - just less convenient or at least less flexible.

The rationale asserts the field had "outlived its usefulness" without any explanation why that should be.

@colan can speak for himself. But my answer to this is connected to the slow but steady tendency of Drupal to move from a complete application to a framework for building applications. By assuming less about what site builders and their customers need, Drupal will be easier to use.

but then there's still the need to copy and paste

Fewer than 25% of the sites I build use the teaser object anywhere in the installation. We've bloated the importance of the teaser because of how important the teaser was at the beginning of Drupal's history. That history makes it all the more difficult to get rid of, but it still needs to be done, in my opinion.

I never studied programming in school. I'm a site-builder who can dabble in code. I got involved in Drupal from the content side, when I had web management responsibilities for a non-profit that was looking for a content management system. From my perspective, it seems to me that coders consider a decision to not automate as a personal defeat. At the same time, I find that coders can rarely see how, at times, even clean code can obfuscate what is necessary to be seen by end users to make the task conceptually simple. Long-text with summary is a perfect example. What it does is slick and cool if you understand what is going on and a complete mind-bending mess if you don't.

Requiring copy and paste to implement teaser functionality does not suggest a failure by coders. Rather it would reflect needed restraint by coders to make transparent the underlying structure so as to not confuse end users.

Shai

Most of the issues in the summary are about inconsistencies in the UI text, which is hardly a justification for ripping it out of core. The long text type is quite useful, and (I would hypothesize) widely used. I don't see a case for removing it here. So a -1 from me.

My company has built between 3 and 5 Drupal sites per year for the past 4 years. With one exception in that time, all have been configured such that the primary content types had custom summaries, not summaries that were truncations of the Body field.

The reason is that for a marketing-oriented site, a summary that's a truncated version of the page is almost always going to be unsatisfactory, because it entails repeating information verbatim from summary views and RSS feeds at the top of each page. We will almost never want to do that: In order for copy to be effective, it should be tailored to its context and its medium, and copy that has a short length should be tailored differently from medium-length or long-form copy. Similarly, the SEO case is different for body copy and teaser copy.

The current function of the "Long text with a summary" type partly meets this need, but fails in 2 critical ways:

1. It's not displayed by default, which makes it easy for lay users to ignore. (We always require that all of our sites be client-maintainable, and this fails the client-maintainability test in that regard.)
2. There's no way to make the Summary field required. (We almost always do this.)

So what's puzzling me about this is why the Body field has to be defaulted to "long text with summary." If we could choose between that and "long text", this issue would not need to exist: those of us who need to create required summary fields without the added confusion of a mandatory Summary field attached to the body field would have the option to do so; those of us for whom the partial solution offered by the current configuration could continue to use that.

@escoles, if you want to use "long text" fields, you can create them and use them, right? Nothing is forcing you to use the default Body field that appears on new content types; you can delete it if you don't need it.

Changing that default behavior may or may not make sense, but I don't really see how it's related to this issue.

I find @escoles' comment spot on and very helpful to the discussion at hand. It shifts the consideration from 'remove or not' to 'should this be the default formatter for the body field in the core content types or not'. He even provides a nice data point that acknowledges that choice.

Providing long text and summary as the default is very much forcing things upon people, especially in the initial evaluation phase. 'You can delete it if you don't need it' is not a viable answer if most of the times that's what people should be doing anyway.

Keeping in mind that this is a default we can change makes it much clearer to me that we can focus on cleaning up the feature instead of discussing wether to remove it or not.

Changing the default would indeed be a different but very welcome issue.

I can get behind that idea. But it's missing scope. ;)

More specifically, the Standard profile sets up the Article and Basic page content types. Both get a Body field of type text_with_summary.

Now, for the Basic page content type, the summary is pretty much pointless, since the use-case of a Basic page content is to only appear on a page on its own (commonly accessed through an associated menu link), but not in node listings.

Thus, it would make sense to change the field type on the Basic page content type.

Looks like the scope for this issue is to be the meta for the teaser functionality domain :)

Please revise #1396170: Change the default body formatter for Page content type from 'long text and summary to 'long text' as necessary.

Le sigh! Which is what #626546: The body field on the Basic Page content type should not allow a summary to be input is all about already, so hope to see you there :)

Added 1396170

Moving to text module - there are probably other ones still in the field system component.

and remove again because its a duplicate.

There's also the simple UX glitch that a field who's sole existence is to allow customization of a summary portion has an option to not even make the summary available. What is the point of even having that option?

(See #2906282: No summary option showing for "Text area with a summary" widget for where I ran into the UX glitch)

This seems to be a duplicate of #2726497: Deprecate text_with_summary

Can't remove but deprecate (if we go that route)