Plain text format does not honour filter processing

+1
this is very annoying
i want to use plain text for blog comments, removing the text format choice for any user
but then the text is unreadable

'Convert line breaks into HTML' is offered as a filter for the 'plain text', anyway it have no effect in the output. I created a new input format for comment box just to make the 'line breaks' work.

Also, the option for selecting plain text or filtered html means, filter is only available for 'filtered html'. Am I right?

It works for me. You have to make sure your filter processing order is correct - if it's filtering out HTML after creating line and paragraph tags, and those tags are not on the allowed list, then they will be filtered out.

@Carolyn, it works when it is 'filtered text'. It wont work when it is 'plain text'. Filter order is same for both.

I can't reproduce the issue of line breaks not working properly on the plain text filter (which comes with the standard install profile) in 7.4 or 7.x-dev (as of this comment).

Admittedly for production I use the minimal profile and create a plain text format. However to try and sort out this issue, I installed drupal 7.4 and drupal 7.x-dev in the standard profiles and still couldn't reproduce the issue discussed in here.

Same issue. very annoying. This means I can't dictate plain text vs. other formats in my content type fields. I have to set them all to "filtered text" where they choose.

This is a huge problem for forcing content conformity.

I just tested this on one of my older sites, and it wasn't a problem. I'm going to compare installed modules and versions and see if I can track down the specific problem.

I found the problem, and have replicated with a 7.7 core version. Here are the steps from a fresh install (on MAMP):

1) Create an article, and put the following as the body text:

test

test

2) Edit the article body CCK field and change its text processing to plain text.

3) View the article you previously created. Its line breaks will be gone.

4) Optionally, edit the article, to see that the line breaks are still there in the text area (they are!!).

This occurs for any and all "Long Text" and "Long Text with Summary" fields. I created 4 with different workflow steps, and they all exhibited identical behavior.

VOILA! Do I need to report this somewhere else?

Shifted to bug report.

My impression was that plain text is just that, plain text. Thus all HTML tags would be stripped including but not limited to line breaks which would include <br> <br /> and <p>.

My understanding of the plain text format, with reference to how it is supposed to act/react could be wrong.

I've never expected any HTML tags to work in plain text and have always expected that they would be stripped on output.

I'm not in front of an install at the moment to look at any, if there are any, filters included on the plain text text format.

VM: By default, the plain text format in D7 has a box checked for converting line breaks to HTML.

Here's my argument as to why it SHOULD work that way:

Long text content type fields only give me two preset options for text processing: filtered text and plain text. This is the only control I have over content uniformity, since the filtered text option doesn't allow me to specify a particular type of filtered text (e.g., "Full HTML", "Filtered HTML", "Plain Text with Line Breaks").

As a result, without the functionality we're asking for here, there's no way for me to limit a user role that has access to the "Filtered HTML" format from using that format on a content type field where I only want "Plain Text" used.

At the same time, I can't expect users to operate in an environment without line breaks, and thus limit all roles to line breaks only.

The "text processing" option on long text CCK fields is the only way I have to limit roles with access to multiple formats, to one format.

By default, the plain text format in D7 has a box checked for converting line breaks to HTML.

Couldn't one also enable the HTML filter and add the necessary line break tags? and only those tags?

The above may only be seen as a workaround.

It's still not a workaround for the scenario where "Role 1" has access to both "Filtered HTML" and "Line Break HTML", and I have a content type field where I only want "Line Break HTML" to be available.

The user would be able to choose between the two, but I don't want them to be able to choose between the two. I want them to only have access to the one, singular format: plain text.

If there's a module for this.. that'd be a workaround.

only module I'm aware of at this point that may try and tackle that is the better_formats module. However, I don't know where that module stands with reference to a D7 version. Though I've been involved in the issue queue over there.

So if I understand correctly you want to be able to choose specific default text formats based on content type? And remove a users ability to select a text format based on permissions?

based on #14 I'm moving back to support request because I don't see where this has been established as a bug let alone a major bug.

Further elaboration in #14 suggests this may be a feature request which would have to go into 8.x-dev and probably wouldn't be able to be back ported to 7.x due to feature/string freeze.

VM, the one thing I'd note is that it makes no sense for Drupal 7 to install with preselected options for converting links and line breaks to HTML for the plain text filter, if this is not possible. Also, I'm fairly certain that Drupal 6's plain text filter does not behave this way. (Edit: My mistake, Drupal 6 doesn't even have a plain text filter by default. My company uses better formats, so it's likely they've set up more usable behavior with a custom plain text format.)

Ultimately, my goal is to be able to force a user who may have access to both the plain text filter and other text filters, to only be able to use plain text with line breaks on certain CCK fields.

Right now I can only force them to use plain text (with no line breaks, which is a huge hinderance) and/or any other text filter they have access to.

I honestly don't see why the plain text filter should not have line breaks - if I open a "Plain Text" file, or any file in the .txt format, it's not robbed of all line breaks. I realize there's a disconnect in that line breaks must be HTML in order to show up on web pages, but this is both expected and important behavior in most web applications.

Here's an example of how I see this as a problem.

I give the role "manager" access to the text filter "Full HTML". I create a content type called "Author". This content type has its body field set to plain text, so that the user cannot use any text formatting (bolding, etc..). All of the sudden, they also can't use line breaks, which isn't intended at all.

So, I go and create a text filter "Plain Text with Line Breaks", and give the "manager" role access to that filter. I then change my body field to "filtered text". Now, the user can choose EITHER "Full HTML" or "Plain Text with Line Breaks" for that field - and there's nothing I can do to stop it.

My content uniformity just got murdered.

as you stated the plain text filter is new in D7. It is still unclear to me as to whether your argument is that this is a bug against a new feature or a feature request that you want included in D8.

Yes. This area changed in D7 with the addition of a plain text format.
Yes. If using a contrib module in D6 that isn't available in D7 (better formats) then there may also be issues there.

plain text files and what drupal does are two different animals. Drupal strips HTML tags (it shouldn't show) on output. Line breaks as far as Drupal is concerned are HTML and are in the form of the tags I've previously mentioned whereas line breaks in a .txt file aren't HTML.

How are your filters ordered on your plain text format?

Though, the order doesn't at all alter the secondary issue you are proposing here. which is that user roles, with permissions to use more than on text format have the option to use each format they have access to. Core has never provided a default input format/text format per content type. Contrib has done that.

I looked at other bugs/issues filed against the plain text format in D7 and D8, and couldn't locate something that I thought duplicated this report. If you feel it's a bug, then my all means mark it as such and move it to D8 - dev. Personally I'd close this issue since it's kind of cloudy at this point and open a new one. A single issue for each specific issue rather than a salad of issues this thread has seemed to become. Either way, bug fixes go into Drupal 8 -dev first and are back ported from there. Thus make sure you file it where core dev's are currently working.

Understood. I guess my argument is three-fold:

1) A text format which is entered with line breaks should be viewable with line breaks.
2) A multi-line text format with no support for line breaks isn't very usable.
3) There should be a more robust core mechanism for selecting which format is used by a given CCK field, since there is already an arbitrary selection of either "plain text" or "filtered text". If those two options are already exposed, why should not all options be exposed? Why is plain text treated in a special way compared to all other input formats?

I'll give some thought to whether or not I'd like to move these into proper issues, but I'd like to get your thoughts on #3. It seems odd that this is exposed for plain text, but not for any other formats.

My assumption on #3 is that because text formats are now set per field, and those same fields can be shared on multiple content types, it may be difficult to find a way to set a "per content type" text format. I've commented to this effect in the better formats issue queue where users are asking for the same feature set as provided by D6 (with reference to better formats). Don't quote me but it may be what's holding up progress with BF moving to D7.

The fields api in core has changed the approach from the "per content type" perspective. Essentially what it looks like is needed is a permission, per role, per content content and possibly per field (or an admin to know not to share fields across multiple content types) and I just don't know how anyone is going to get there.

How was that accomplished for plain text vs. all other formats?

Also, do you think it makes sense to remove the default checked status for converting URLs and line breaks to HTML, if the consensus is that the plain text format does not, and will not do that?

I don't understand your follow up question. Granted my misunderstanding could have be due to being in the process of editing my previous comment.

How was "what" accomplished?

When I need line breaks, I not only enable the line break filter, I add the necessary HTML tags to the HTML filter. ie: <p> <br /> <br>

I do this so that when the line break filter is enabled and adds the tags drupal does not strip them on output.

You were saying there's a hitch with assigning specific text formats to specific CCK fields, but this has already been done. When you create a long text field, you can select either plain text or give the user the ability to choose any other text format.

I was just wondering what makes the plain text format "special", such that you can select between it and other text formats when making a long text cck field.

My comment regarding removing defaults, is because if I install Drupal 7 and go to my text formats, and configure the plain text format, it has the checkboxes turned on for converting URLs and line breaks to HTML. This is misleading, since the plain text format will not ultimately put out any HTML, regardless of these checkboxes being checked.

It sounds like this is due to some "behind the scenes" stripping of all HTML, which should probably also be shown on the configuration page as a checked, read-only checkbox with a label like "Strip all HTML".

Let me know if this doesn't make sense..

You were saying there's a hitch with assigning specific text formats to specific CCK fields, but this has already been done.

please block quote what you are talking about me saying. So that I can reread the "hitch" you speak of. Note: CCK is now the fields api in core. It's not quite the same animal. It is true that it is said, CCK went into core but it's not quite the same animal you are used to with reference to working with CCK in D6 and previous versions of Drupal.

My assumption on #3 is that because text formats are now set per field, and those same fields can be shared on multiple content types, it may be difficult to find a way to set a "per content type" text format.

I never really got into Drupal 6.. I'm primarily familiar with Drupal 7.

I guess, aside from any feature changes, all I'm saying is that the configuration options for the plain text format should probably be modified to reflect the fact that no HTML will be output. See this screenshot:

http://dl.dropbox.com/u/15528/Screen%20Shot%202011-09-01%20at%2011.47.25...

At that point you may want to file a feature request against D8 -dev as previously mentioned with some indication on where or how you want this change reflected. ie: be it in help text in the plain text text format description, core help files in the help.module or in the documentation on d.o. for text formats in general.

core help files, and descriptions in core, require string changes and as such are required to be filed against D8. Strings don't get back ported as this would create issues with translations in other languages due to those changes.

If d.o. documentation requires changing and you can't make these changes to the pages on your own, file an issue against documentation for the doc team to look into.

Prior to filing an issue you should sort the D8 issue queue and check into any/all existing issues which are already dealing with text formats to guage current discussion and ideas already being presented. I only looked at D7 issues which were logged.

Thanks for the head's up.

Comments on my website only allows plain text no matter what settings I try. It will not turn line breaks into HTML, it will not convert URLS into links, etc. Even logged in as administrator it is no different when I submit a comment with full or filtered HTML, with or without the CKeditor. I tried disabling the CKeditor, and still nothing changed. I have tried enabling and disabling different filters under plain text, and nothing changes.

A detail that may help in troubleshooting is that I get dozens of log messages every day that say the following:

Type: filter

Missing text format: 3.

I have the 3 normal text formats. (Plain text, Full HTML, Filtered HTML). I deleted the Full and filtered formats several months ago, and I recreated them using "add text format" hoping to start fresh. It didn't help, and that may have been a big mistake. Currently when I click on configure plain text, it says "Machine name: 5." The anonymous authenticated, and Webmaster user checkboxes are selected and cannot be unchecked. This format also cannot be deleted. Under Filtered HTML, when I go to configure, it says "Machine name: plain_text" which doesn't seem right, although it allows me to uncheck or check any user roles. It allows me the option of deleting that text format. Under Full HTML the machine name is "Machine name: 2," and it allows me to uncheck or check any user roles, and delete that text format.

Also, when I go to Content types › Article › Manage fields › Comment it tells me "Comment has no field settings."

Is there somewhere where I'm supposed to be able to choose which text format is to be used in comments?

I have probably spent about 20 hours off and on over the last few months trying to get to the bottom of this. Any help would be appreciated.

with reference to the text formats that you deleted, was any content created with them? if so, did you edit those content types to switch their input formats to the newly created ones?

I'm sure I had created content with text formats I deleted. Problem is, when I deleted the original text formats and then recreated them from scratch, I gave them the same names as before (full & filtered HTML) so I can't tell right off which ones were created with a deleted text format. Should I try to make a new text format with a different name, and then manually change all content on my site one by one to that new text format? I only have about 30 articles in my site, so it would not take forever to do. I just created a new filtered text format with a different name, I saved content with that new text format, but when I tried a comment on that very page, it still turned out plain text. But perhaps all content originally done with a deleted format needs to point to a current text format before I can expect things to be fixed. Please advise if I should convert all content to a current text format. Thanks for trying to help.

Pretty sure the name of the filter isn't what's used in the DB, it's likely a format id of some sort. Checking the db may aid.

another aid may be to edit an early piece of content or flip them all. Seems to me that deleting a text format that is in use by content, wouldn't stop the content from trying to use the deleted text format. Thus every time the content is pulled from the DB an error would occur.

As far as your comment issue and plain text goes, I can't reproduce the issue.

I picked one of the oldest nodes on my website and attempted to change the text format (to filtered and plain text). When I clicked on preview, it gave me the following error message:

•Notice: Undefined index: taxonomy_term in taxonomy_field_formatter_view() (line 1419 of /home/username/websiteurl/modules/taxonomy/taxonomy.module).
•EntityMalformedException: Missing bundle property on entity of type taxonomy_term. in entity_extract_ids() (line 7389 of
/home/username/websiteurl/includes/common.inc).
The website encountered an unexpected error. Please try again later.

In the database I found two old text formats listed as disabled. It lists both the name and the machine name for each text format under filter_format. If it would be helpful for me to upload screenshots of certain tables of the database or anything, just let me know. Thank you again for trying to help.

The taxonomy issues as reported by the above errors is unrelated to text formats. What did/were you doing with taxonomy at any point?

I just witnessed a very similar issue (if not the same) on a site and after some investigation found that the issue was instigated by settings on the manage display tab. The referenced site also had display suite.module installed and may have aided in making the issue more difficult to narrow down.

The above said, insure to check the manage display tab for the fields which are having issues. Admittedly it can get confusing bouncing back and forth checking the text format, the filters on the text format, the setting on the field, AND the setting on the manage display for the field.

I'm having this problem too... Plain text simply runs everything together, no matter what.

Under manage display, I see 3 options under "label:" Above, inline, and hidden. Then I see 4 options under "format." Default, Plain text, trimmed, and hidden. The Comment field can also be hidden. What are the proper settings here to enable HTML in comments?

Under manage fiels>comments, it allows me to choose a number of rows, and then under "text processing" either plain text or filtered text only (I have filtered selected). Then under "text format" it allows me to choose any one of the active text formats (I have Full HTML selected).

Under manage fiels>comments>field settings, it tells me "Comment has no field settings." Is this normal?

It's unbelievable to me all the different places where there are settings for text formats in addition to Configuration>Content Authoring>text formats. It seems that Drupal is making this matter much harder than it should be.

Marked #1019042: Convert line breaks into HTML doesn't work as duplicate.

I created a workaround for this by doing the following:

1. Create a Text Format almost identical to Plain Text and ensure its line breaking
   • Convert line breaks into HTML
   • Limit allowed HTML tags
   • Display any HTML as plain text
2. Alter the form using the hook_alter function to override the dropdown list by creating an input variable with type '#hidden' and set it to the new plain text format. Ensure the weight drops the new value underneath the old dropdown list so the new value will set after the old.
3. In CSS turn off the old div (e.g., #edit-field-contenttype-comment-body-und-0-format) or dropdown using display : none.

This works for me! :-) <-- I'm happy.

This is silly. Here's the problem, and I believe what might be the cause of confusion between @runeasgar and @VM above- the word "Plain text" is overloaded. In a content type's textarea field it is both a Text format AND a text processing option. In a content type's body field settings, under "Text processing", if I select "Plain text", then I expect the "Plain text" text format's settings to be used. But they're not. So why even have a "Text processing" option? Let me answer- because that's the way you decide whether a user gets to select from multiple text formats. Ug! So if you want the user to be able to enter any amount of HTML, you must present them with an extra drop down where they have to choose the text format of their post. The extra dropdown only appears if you allow your site's regular users to have access to more than one text format. So this is only a problem on sites where you want to allow users to enter two types of text formats into different forms, but you want to restrict one form to a certain text format.

Please correct me if I am wrong in any of this.

SOLUTION (short term):

(option 1)
Choose one text format for regular users of your site to use. Then they don't ever have to choose.

(option 2, to keep multiple text formats for regular users)
Do something similar to BrooklynCoder. Set the content type's body field to have its "Text processing" set to "Filtered text (user selects text format)". Then set the default filter format to Plain text (if you don't see this, save the field settings then go back and edit again). Then in CSS, hide the div that contains the selection drop down. I didn't bother with hiding anything via hook_alter. I *think* this works with the default "Plain Text" text format, but I was having trouble saving settings on my text formats (NO idea why, but enabling or disabling the Webforms module would allow me to save the settings once, but future saves would not work) and I'm not sure if my current Plain text filter reflects the vanilla install's settings.

SUGGESTION (long term): I completely agree with runeasgar in that there should be a way to allow a user to not have to choose what text format he/she wants if they are allowed to do something other than plain text. It's confusing. Get rid of the "Text Processing" option and have each text format be a check box, where you can enable or disable it on that content type. If multiple boxes are checked, and the user has the privileges for those content types, then they will be presented with a drop down for Text Formats. In short, yes this should be a per-content-type setting.

My short term solution is to throw this inside my theme's template.php:

<?php
/**
 * Implements template_preprocess_field().
 */
function THEMENAME_preprocess_field(&$vars, $hook) {
  // Add line breaks to plain text textareas.
  if (
    // Make sure this is a text_long field type.
    $vars['element']['#field_type'] == 'text_long'
    // Check that the field's format is set to null, which equates to plain_text.
    && $vars['element']['#items'][0]['format'] == null
  ) {
    $vars['items'][0]['#markup'] = nl2br($vars['items'][0]['#markup']);
  }
}
?>

Thanks for sharing csdco, works well.

In #1152216: (Long) text field (textarea) with "Default" formatter does not retain newlines there is a lot less discussion and a lot more patching.

Sub +1. I confirm the issue. Quite annoying. :(

It may be annoying but think about it this way... If you were to enter this into a plain text field:

<p>A paragraph</p>
<p>Another paragraph</p>

and then convert newlines into <br>'s, you'd get:

<p>A paragraph</p>
<br />
<p>Another paragraph</p>

which is probably not what you want. I think what I really want is to be able to set an input format that cannot be changed for a field, then I can apply filters like normal.

Hi csdco, thank you, that worked well for me too. Do you know a way to also retain the line breaks in views?

As of the 7.15 release, this is still an issue it seems. I have implemented 40 as a short term solution as well, and it seems to be working fine.

This would be easily solved for me if I could just use filtered as default but turn off 'plain text.' The problem there is that Drupal forces that to be available for all users and it cannot be disabled.

I simply don't want that ugly 'select filter' box where people can choose via the drop down. Following. Note, I don't understand why this was switched from a D7 issue to D8. Is there no intention on fixing it in D7?

Try this patch from sun & jhedstrom.

+1 that this is a problem.

I would like my users to have different text formats on a per field basis defined in content type. I would like one field to be filtered plain text and another field to be filtered HTML.

I would also like my users NOT to see the choose text format drop down when editing, but only be allowed to use the one text format that I choose for them.

I have found a workaround to this problem for now.

First, go through your content types and indeed set them to use filtered texts.

Then, to go the configuration for filtered texts and only allow br and p tags. Note, if you are using filtered for another purpose and need more tags there, simply create a new input type and give it br and p tags.

Finally, set the permissions for filtered input so that no one can use it. This will prevent it from showing up as a selection option.

Voila, plain text with preserved breaks and paragraphs, and no selection box under the form element.

Needs issue summary

Needs issue summary

HTML entities

Addition of issue summary

Cleaned up Jon's original message

Added steps to reproduce

Reworded Problem/Motivaiton, added note about patch (#47)

Updated issue summary.

Cleaned up spacing and breaks in Jon's original message

Per @rhawkins's comment in #39 there is no functional bug here. The plain text format works fine.

There is definitely a usability issue in that the Field UI uses the phrase "plain text" to mean "this content does not have a text format", but Drupal core also ships with an actual text format whose name is "plain text". Somehow we need to deal with that in the user interface and use better terminology (and/or explain the existing terminology better).

This issue is kind of muddled so perhaps we could close it and create a new issue focused on fixing that usability problem. But for now, I'm just repurposing it.

Recategorizing this (since Text module is the one that uses this terminology).

Also, the patch in #47 was taken from #1152216: (Long) text field (textarea) with "Default" formatter does not retain newlines which is a separate issue, and the same patch shouldn't be reviewed in two places. Moving back to active.

I also noticed that another issue discussed in the comments above was restricting the text formats displayed to each user on a particular field. For Drupal 7, see modules such as http://drupal.org/project/better_formats for that functionality (it was already mentioned above). For Drupal 8 core, see #784672: Allow text field to enforce a specific text format and other issues linked to within that.


Convert line breaks into HTML is showing up weird - encased in "code" to keep original message

Added issue summary.

For users with Drupal 7 and having this issue there is a workaround. Add some CSS for your fields to get the output of the field to display with line breaks. The snippet below is for a long text field with the field name of 'field_description' that is attached to the node type of 'page'. It's working for me just fine.

<style type="text/css">
.node-page .field-name-field-description {
  white-space: pre-line;
}
</style>

@therainmakor - nice!
yeah, users just want to see the output look like what they put into the textarea. Doesn't need to be overly complex.

JFTR
Linking this issue to "Plain text format" applied to every content by default in "Cutting through the input format clutter" (Usability User Group).

EDIT
The problem reported there seems to be related to the content being created by an import script, so probably not relevant here.

Added two more tasks for "remaining tasks" section

Changing title to match summary.

Marked #1152216: (Long) text field (textarea) with "Default" formatter does not retain newlines as duplicate of this one.

@David_Rothstein: the issue is still about textareas with "Plain text" Text processing (rather than formatter) not retaining newlines.
The fact that other people get confused and drag text formatters into the discussion does not change that. You are right in that that should be a separate usability issue where the term "Plain text" in the "Text processing" options should be changed into something like "stripped text" or "raw text".

#47 changes the behaviour of the textarea processor to retain newlines, which is what I and the OP want. Setting this to needs review.

Sorry, double-clicked the save button :(

#47: drupal-text_plain-1095838-47.patch queued for re-testing.

Issue #1017662: Different meanings for "plain text" (Field UI text processing vs. default Filter module text formats) is for the confusing term "Plain text".

The original report here and most of the subsequent discussion is about people who configured the "plain text" text format to have line breaks and then expected the "plain text" processing option in field settings to respect that setting...

You're right that #1017662: Different meanings for "plain text" (Field UI text processing vs. default Filter module text formats) looks like it deals with this confusion too, and it's also older plus easier to follow at this point.

For making the "plain text" text processing setting retain newlines on its own, #1152216: (Long) text field (textarea) with "Default" formatter does not retain newlines is the issue for that; the patch was posted there originally and has received reviews there, etc. (and it's already been reopened by @sun).

So, let's close this one as a duplicate (of one or both of the above).

@csdco's solution worked for me. Thanks a lot!

Updated issue summary.

csdco #40 - thank you.

simple and fast solution.

"The rainmakers" css solution #56 worked for me (thanks!)

(theme solution did not for some reason,but I didn't fully persue it). I was wanting to display line breaks within plain text field displayed in a view. Rainmakers solution perhaps seems to suggest it is a solution for D7 but obviously the css code can be applied to any field etc. Worked fine for me in D6 and I can't see any reason it wouldn't work for any Drupal version. So someone might want to rephrase the "For users with D7" bit...

Actually I maybe prefer this solution as it maybe gives more control as to how "plain text" is displayed in different areas

I updated the workaround for D7 from csdco #40 with a better markup. Every plain text field gets wrapped into at least one paragraph. Single line breaks get converted to <br>. Two and more line breaks get converted to </p><p> which creates a new paragraph:

/**
 * Implements template_preprocess_field().
 */
function THEME_preprocess_field(&$vars, $hook) {
	// Add line breaks to plain text textareas.
	if (
		// Make sure this is a text_long field type.
		$vars['element']['#field_type'] == 'text_long'
		// Check that the field's format is set to null, which equates to plain_text.
		&& $vars['element']['#items'][0]['format'] == null
	) {
		$vars['items'][0]['#markup'] = '<p>' . preg_replace(
			['/[\r\n]{2,}/', '/[\r\n]/'],
			['</p><p>', '<br>'],
			$vars['items'][0]['#markup']
		) . '</p>';
	}
}

I found that the format index does not even exist for plain_text fields in my instance so along the lines of https://www.drupal.org/node/1152216#comment-8575081 I amended the condition to the following:

...
  if (
    // Make sure this is a text_long field type.
    $vars['element']['#field_type'] == 'text_long'
    // Check that the field's format is set to null, which equates to plain_text.
    && (!isset($vars['element']['#items'][0]['format']) || ($vars['element']['#items'][0]['format'] == null))
  ) {
...

This code results in a parse error for me: Parse error: syntax error, unexpected '[', expecting ')' in this line:

['/[\r\n]{2,}/', '/[\r\n]/'],

I decided the use the CSS solution as in #56. This works fine.

This is the code as I have placed it in my template.php.

<?php
function MYTHEME_preprocess_field(&$vars, $hook) {
    // Add line breaks to plain text textareas.
    if (
        // Make sure this is a text_long field type.
        $vars['element']['#field_type'] == 'text_long'
        // Check that the field's format is set to null, which equates to plain_text.
        && (!isset($vars['element']['#items'][0]['format']) || ($vars['element']['#items'][0]['format'] == null))
    ) {
        $vars['items'][0]['#markup'] = '<p>' .preg_replace(
        	['/[\r\n]{2,}/', '/[\r\n]/'],
        	['</p><p>', '<br>'],
        	$vars['items'][0]['#markup']
        ) . '</p>';
    }
}
?>

I am getting this error with template.php trick

Notice: Undefined index: #markup in gratis_preprocess_field() (line 33 of

I do not know how to use the css. I have a "Bio" field under account settings which shows on user profile. How to use the css?

I see this is still an issue in Drupal 8, the plain text format does not honor the filtering checkboxes. I had chosen plain text for a new field in a paragraph type wanting to not have a wysiwig editor but wanting to be able to configure it to allow html tags, or at least mailto links and line breaks. Turns out the filtering check boxes for the plain text format simply DO NOT WORK. Why are they there if they're broken, doesn't that give the false impression that those are configuration options? Now I'm stuck with a great deal of content in that field that is set to plain text with no way to change it to an html-allowing format. Shouldn't we at least remove options that are broken and do not work? Thoughts? Thanks and best.