(Long) text field (textarea) with "Default" formatter does not retain newlines

Makes sense. Right now, 'long text' fields set to 'unformatted' are useless without being able to handle newlines.

Assuming this tag was missed, if not feel free to remove it.

Makes sense, but let's get some tests added.

This patch updates test.text so that the existing tests account for new lines in the text_plain format.

The changes to the existing tests make them test against the patch in #0...if you apply the patch from #4, revert changes to text.module, and run the tests, they fail. They pass with the patch re-applied to text.module. Is it preferable to write an entire new test method to test for line breaks?

+++ b/core/modules/field/modules/text/text.moduleundefined
@@ -316,7 +316,7 @@ function _text_sanitize($instance, $langcode, $item, $column) {
-  return $instance['settings']['text_processing'] ? check_markup($item[$column], $item['format'], $langcode) : check_plain($item[$column]);

I reckon both places where we're using nl2br could use a comment to explain why?

Hi

I think it is wrong problem discussed and fixed here. It's not about converting new lines to <br /> on every plain text format. There's an option in text formats configuration called "Convert line breaks into HTML (i.e. <br> and <p>) " and the problem is that it's not honoured. Sorry if I'm wrong but this is my opinion after seeing the patch.

Please see this:
http://drupal.org/node/1095838

Yep, you are right Sun. Thanks for patch.

Marking as duplicate of #1095838: Plain text format does not honour filter processing.

I closed that one as a duplicate.

In a fresh installation of Drupal 8.x-dev on March 6th, 2013, the problem in the original issue was verified. In a content type, adding a field of:
- a "FIELD TYPE" long text "WIDGET" text area (multiple rows) of "Text processing" plain text, and multi-line content -- when viewed, the content is on one-line.
- a "FIELD TYPE" long text "WIDGET" text area (multiple rows) of "Text processing" Filtered text (user selects text format), and multi-line content -- when viewed, the content is on multi-line. See screenshots.

After applying patch text.plain_.16.patch in #17 by sun,
- a "FIELD TYPE" long text "WIDGET" text area (multiple rows) of "Text processing" plain text, and multi-line content -- when viewed, the content is on multi-line.
- a "FIELD TYPE" long text "WIDGET" text area (multiple rows) of "Text processing" Filtered text (user selects text format), and multi-line content -- when viewed, the content is on multi-line. See screenshots.

Committed to 8.x. Thanks!

Note that #1932382: Use DrupalUnitTestBase for Field API tests., which was committed shortly after, introduced FieldUnitTestBase, which contains its own (slightly different) versions of assertRaw(), assertNoRaw(), assertText(), assertNoText().

D7 patch (without tests)

Has this been ported to D7?

It seemingly has been ported, yes. :-) It is not part of the Drupal 7 development branch, though, yet.
Let's let the bot have a go.

The patch from #24 applies perferctly against drupal-7.22

Also applies cleanly to and works on 7.23

The patch from #24 works and produces the result I expected.
so I second @jyee and say RTBC

That's got me WTFing for a moment there. I mean - you have 'convert newlines' checked, and it is simply ignored.
Yep, RTBC too.

path from #24 working for me too. using d7.23. now my address text field is all with break, not inline anymore.. tqvm

*oh one thing.. if there is core update available. if i apply new update exampel d7.24.. i suppose to apply that patch again?

Patch #24 works for me

what needs to happen for this to go into D7, with clear instructions I would be happy to help.

Why weren't the tests backported to Drupal 7?

Also, I don't see how we can commit this to a stable release as is. People could certainly have line breaks in the database that they expect not to display (for example, using the Migrate module to pull in content from who-knows-what source with who-knows-what kind of broken formatting). Maybe a checkbox to control the behavior?

Also not sure about the idea of changing the meaning of the "plain text" formatter (removing the strip_tags behavior) in a stable release...

Since this will never make it into D7 core, here's a simple (but inefficient) way to convert newlines to br tags on text_plain formatted fields using template_preprocess_field in your theme (remember to replace "template" in the function name with the name of your theme):

function template_preprocess_field(&$variables, $hook) {
  if (
    isset($variables['element']['#items'][0]) && (
      !isset($variables['element']['#items'][0]['format']) ||
      $variables['element']['#items'][0]['format'] === 'text_plain'
    )
  ) {
    foreach ($variables['items'] as $index => $value) {
      $markup = isset($variables['items'][$index]['#markup']) ? $variables['items'][$index]['#markup'] : '';
      $variables['items'][$index]['#markup'] = nl2br($markup);
    }
  }
}

I would suggest adding a condition to the code suggested by figureone: $variables['element']['#field_type'] !== 'ds'.
In this way you don't mess with Display Suite fields.

Patch #24 works for me
Thanks.