Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Are there any plans to allow overriding of the text format of the summary field? In general I want my body to be Full HTML but the summary to be be Plain Text or Filtered HTML, something that I can use the line break converter on and strip images from.
Comments
Comment #1
nestor.mata CreditAttribution: 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 CreditAttribution: 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 CreditAttribution: 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 CreditAttribution: 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 CreditAttribution: swentel commentedThat will be D9 material
Comment #6
ExTexan CreditAttribution: 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 CreditAttribution: 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 CreditAttribution: ao2 as a volunteer 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 CreditAttribution: smustgrave at Mobomo commentedClosing as duplicate of #2671162: Also use text editor (CKEditor) for "summary" of a text field
Comment #28
mstrelan CreditAttribution: mstrelan at PreviousNext 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 CreditAttribution: smustgrave at Mobomo commentedShould this be postponed then on the other?
Comment #30
mstrelan CreditAttribution: mstrelan at PreviousNext 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 CreditAttribution: 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. 😅