Closed (won't fix)
Project:
Drupal core
Version:
main
Component:
text.module
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
12 Apr 2012 at 02:14 UTC
Updated:
26 Jun 2026 at 16:35 UTC
Jump to comment: Most recent
Comments
Comment #1
nestor.mata commentedThinking about this, I'm not sure this needs to be actually implemented, you can easily theme the summary as plain text.
Do you really think this is necesary?
I think this is part of the options we has to theming things.
Let me know what do you think, or anybody else too.
Regards,
Nestor
Comment #2
nestor.mata commentedI mean, the main question is, if we really should implement the feature even knowing that we can achieve this with theming?
Nestor
Comment #3
mstrelan commentedI guess I could do that, I wonder what would be the best way to do it wherever the summary is displayed. It would become problematic if #741606: Teaser splitter / text fields with summary support gets in to Wysiwyg, because I believe the Wysiwyg profile for the selected text format of the body would be applied, and therefore the Wysiwyg would enter all sorts of HTML, and trick users in to thinking the rich text will be displayed, but really I would be stripping the formatting. Obviously that would have to be something that's resolved in contrib, but wouldn't be an issue if you could change text format for summary fields.
Comment #4
extexan commentedTo add my two cents... In my site, none of my content is created by end-users, only by administrator(s). I use WYSIWYG for the body, so I can add bolding, change font colors, etc. (for selected bits of text). It would be nice to have the ability to do the same when editing the Summary, so that what the user sees on the teaser is the same as the first part of the actual article.
Comment #5
swentel commentedThat will be D9 material
Comment #6
extexan commentedSeriously?!? D9?!? For something that should have been implemented at the same time the summary was made into a separate textarea?
I have to say, the rules governing what can and can't be implemented before/after a "code freeze" really needs to be revised. Drupal is getting WAY too restrictive, thus putting off fairly simple, yet much-needed "fixes" that could (and should!) be done in *current* versions. And I'm not just talking about this one instance.
Comment #7
mallezieNo need to be rude, if this is very important to you, you could try to implement this, and provide a 'start' patch with this functionality.
At this moment in the release cycle, it's even possible if you provide this feature to get it in. It has to have a broad consensus, and most important no follow-up issues. More info on http://buytaert.net/drupal-8-apis-are-freezing-but-not-frozen
Comment #8
extexan commentedNot rude at all. Just expressing shock and dismay at how easily things get pushed to later and later versions.
Two more examples I can think of...
1) The "confirm_form" *still* asks its question in the title. Not only does that break MANY themes, but it doesn't follow semantic html practices that seem to be so important to Drupal and the community.
2) It is still difficult just to add classes to fields/forms/pages. This should be (could easily be) built-in to Drupal core, but we have to find and install custom modules just to accomplish this simple task.
[Climbing down off of soapbox.]
Re: getting this into D8, how would one go about getting "broad consensus"?... and how would one ensure there are "no follow-up issues"? If I understand "follow-up issues", that means bug list, correct? I don't know of *any* programmer who can guarantee there won't be any bugs in his/her code after being implemented in thousands of different configurations.
Comment #9
catchFeatures can be added in minor releases of 8.x now, so moving back.
Comment #10
charles belovUse case is that the summary is supposed to be simple, and we don't want staff using formatting there. Some staff know HTML and some don't.
It's not that easy to add in theming because I would have to add it every place the summary is displayed, including views.
Comment #15
ao2 commentedAFAIU the current behavior of having the same format for the body and the summary is a limitation of the fact that they are part of the same field and this field is not going to change.
When discussions like this come up usually Drupal core devs suggest to have two separate fields for the summary and the body when different formats are desired, see:
This has also been experimented with in https://www.lullabot.com/articles/replacing-the-body-field-in-drupal-8 where the synchronization between the two fields is also discussed.
Having two separate fields could be how this would be solved in D9 but I have not found an official issue which tracks that development.
Comment #17
bkosborneDownside of two separate fields is that it complicates views. The single combined field as a formatter that will use the explicit summary text if available, and if not, will use the full body and trim it. Not easy to do the same thing when there are two separate fields.
Comment #27
smustgrave commentedClosing as duplicate of #2671162: Also use text editor (CKEditor) for "summary" of a text field
Comment #28
mstrelan commented@smustgrave there is a slight difference in that this issue is suggesting that the summary could use a different text format whereas the other issue is just about attaching the wysiwyg to both textareas while sharing the same text format. I still think there is a use case for this, like restricting images etc from being used in the summary.
Comment #29
smustgrave commentedShould this be postponed then on the other?
Comment #30
mstrelan commentedGood question. I think if we're happy to proceed with this issue then it needs ckeditor to work, but I'm not sure if a decision on this issue would influence the implementation of the other issue.
Comment #31
dalemoore commentedI'm looking for this feature as well. I'd like to restrict the summary to a specific text format, e.g., allowing B, I, and a link maybe or something like that. No images or other things. Some content types might be fine plain text only while others would need a little more formatting. I could have sworn I had a way of doing this in Drupal 7 but can't remember how I did it/what contrib module or if I hallucinated it being possible. 😅
Comment #34
smustgrave commentedSo circling back to this and kinda leaning towards this is a won't fix, mainly because I don't think this should be configurable because then someone could select a format thats using ckeditor and 100% don't think we should be doing #2671162: Also use text editor (CKEditor) for "summary" of a text field and not sure how to do one without doing the other. But still leaving open for discussion.
Comment #35
smustgrave commentedPossible duplicate over in #3067124: text_summary() returns a plain string, even if passed a MarkupInterface object ?
Comment #36
mstrelan commentedCan probably close due to #3427095: [Meta] Deprecate text_with_summary, or move to contrib when/if that finally makes it there.
Comment #37
smustgrave commentedGoing to close this out as the summary field was just meant to be a simple text field without formats. Hence why also closed #2671162: Also use text editor (CKEditor) for "summary" of a text field.
The plugin is being deprecated and moved to contrib but even then can't imagine this functionality being added. Would recommend someone start a text_with_ckeditor_summary contrib project.