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

nestor.mata’s picture

nestor.mata CreditAttribution: nestor.mata commented

Thinking 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

nestor.mata’s picture

nestor.mata CreditAttribution: nestor.mata commented
Issue tags: +#drupalcr

I mean, the main question is, if we really should implement the feature even knowing that we can achieve this with theming?

Nestor

mstrelan’s picture

mstrelan CreditAttribution: mstrelan commented

I 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.

ExTexan’s picture

ExTexan CreditAttribution: ExTexan commented

To 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.

swentel’s picture

swentel CreditAttribution: swentel commented
Version: 8.x-dev » 9.x-dev
Component: field system » text.module

That will be D9 material

ExTexan’s picture

ExTexan CreditAttribution: ExTexan commented

Seriously?!? 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.

mallezie’s picture

mallezie
Primary language Dutch
Location Loenhout
CreditAttribution: mallezie commented

Seriously?!? D9?!? For something that should have been implemented at the same time the summary was made into a separate textarea?

No 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.

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.

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

ExTexan’s picture

ExTexan CreditAttribution: ExTexan commented

Not 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.

catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch commented
Version: 9.x-dev » 8.1.x-dev
Issue summary: View changes
Status: Active » Postponed

Features can be added in minor releases of 8.x now, so moving back.

Charles Belov’s picture

Charles Belov
he/him
Primary language English
Location San Francisco, CA, US
CreditAttribution: Charles Belov at San Francisco Municipal Transportation Agency commented

Use 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.

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

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.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.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.

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.

ao2’s picture

ao2 CreditAttribution: ao2 as a volunteer commented

AFAIU 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.

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.

bkosborne’s picture

bkosborne
Primary language English
Location New Jersey, USA
CreditAttribution: bkosborne at Princeton University commented

Downside 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.

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.

smustgrave’s picture

smustgrave CreditAttribution: smustgrave at Mobomo commented
Status: Postponed » Closed (duplicate)

Closing as duplicate of #2671162: Also use text editor (CKEditor) for "summary" of a text field

mstrelan’s picture

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.

smustgrave’s picture

smustgrave CreditAttribution: smustgrave at Mobomo commented
Status: Closed (duplicate) » Needs work

Should this be postponed then on the other?

mstrelan’s picture

mstrelan CreditAttribution: mstrelan at PreviousNext commented

Good 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.

dalemoore’s picture

dalemoore CreditAttribution: dalemoore commented

I'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. 😅

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.