linebreaks after a line that ends with <strong> are lost

Thanks for the report! I don't think I've ever run into this, so I'll take a look at it and see if I can figure out why this is happening.

I'm trying to make this happen on my local test site, and I'm using WYSIWYG, with the Force Linebreaks option checked, along with TinyMCE, but it works fine for me - the paragraphs stay separate, even if they're completely <strong>'ed throughout.

Please see the attached screenshot for my WYSIWYG profile's cleanup and output settings. Perhaps one of those settings is different, and is causing this?

Also, if you disable the WYSIWYG for the textarea in question, does the markup look like <strong>Para 1</strong><strong>Para 2</strong>, or does it only jumble the paragraphs on page view (after you're finished editing the content)? Might be a text format filter setting...

I'm unable to reproduce this problem. @rickvug you need to post your filter settings.

I assume this is the same issue. I am able to consistently reproduce it. My site is using ckeditor, wysiwyg, and wysiwyg_linebreaks.

This works fine:

<strong>Author</strong>, organization
<em>talk name</em>

But the following has an issue:

<strong>Author1, Author2</strong>
<em>talk name</em>

After saving and re-editing, or disabling and re-enabling richtext it gets converted to: <strong>Author1, Author2</strong><em>talk name</em> (no line break).

note, the following is not effected:

<strong>Author1, Author2</strong>&nbsp;
<em>talk name</em>

So it really seems to just be lines that end in </strong> that are effected.

And, just to confirm, if you disable the wysiwyg_linebreaks module and do this same experiment again, does it work correctly (the lines are not combined)?

@geerlingguy,

I just went to disable the module on my test server and noticed that the same issue isn't happening on that server, so I am continuing to investigate what's the difference between the two (the test server has a bunch of newer modules).

I will try temporarily disabling wysiwyg_linebreaks on a copy of our production server but that will take a bit of time to get setup.

Marking postponed until I can get you more details.

Thanks!

Okay, sounds good!

I'm going to mark this issue as closed for now—if you can ever figure out what was going on and reproduce the problem, please let me know. Thanks!

I experienced the same issue, I recorded reproducing this problem on this youtube video

What I am doing is :

1) Adding text "test", then "shift+enter", then "test"
2) I save and can edit it back in that state
3) I bold the first "test", save, but when I edit it the line break disappears
4) I disable force linebreaks
5) I bold the first "test", save, and the line breaks are preserved

My Versions of everything are:

Drupal -- 7.28
LineBreak -- 7.x-1.6+0-dev
WYSIWYG -- 7.x-2.2+46-dev
CKEditor -- CKEditor 4.4.1.568b5ed

@mcpuddin - can you do the exact same thing as you did in the video, but instead of using the editor's "Source" button, use the "Disable rich text" link and save the node without enabling the editor again? I'm wondering if the editor itself (which potentially alters the markup when you toggle the source button—wysiwyg linebreaks doesn't do anything at that point) might be causing this issue.

Also, thanks so much for the details and video—you have no idea how much more helpful that is than a vague description of the problem or a 'me too'... do you happen to be a QA engineer? :)

Haha not a QA engineer, just someone who wishes other people would do the same if I were in their shoes =)

I clicked "Disable Rich Text" and the same issues happens as clicking the source button. I did some javascript debugging and found out that it happens because of the wysiwyg plugin event 'detach'. I went into linebreaks.js inside the linebreaks_detach function and removed this line:

content = content.replace(new RegExp('\\s*<br ?/?>\\s*', 'gi'), '\n');

And the issue no longer happened.

It seems like the 'detach' event happens on clicking 'source', 'saving', or 'disable rich text'.. so I assume that when 'detach' happens, that line above converts all
from the WYSIWYG to \n, however, when it reattaches, it doesn't add the
back for the WYSIWYG editor

However, there is no problem if the first line does not have a bolded character..

That lead me to look at the attach function in linebreaks_attach, to this line specifically

content = content.replace(new RegExp('([^>])\\s*\\n', 'gi'), "$1<br />\n");

And basically that says, do not inject a
if the line previously has an html element, which is great except for inline html elements like and .

I think the appropriate solution might be to have a list of inline_html_elements to add the \n back to

Hopefully this rambling makes sense...

Thoughts? Happy to create a patch assuming I'm on the right train of thought.

Attached is a potential fix. I basically added 2 lines.

A list of allowed typical inline HTML elements to insert a add a
to:
var allowedlist = 'strong|em|span|u';

and a regex to replace it:
content = content.replace(new RegExp('<\\/('+allowedlist+')>\\s*\\n', 'gi'), "</$1><br />\n");

I'm sure there are more inline HTML elements and not sure of the bigger implications, but I'm open to ideas to improving it

Thanks for the patch, and yes, it looks like you may be going down the right path here. I'll have to work on testing this a little more thoroughly, but it's definitely a bug that needs fixing.

Let me know if there's anything I can do to test it more and make it more complete.

I added anchors to this patch as well because I needed it. Who knows I may even add more as they become necessary..

I think the next steps are:

1. Creating an extensive allowed list manually
2. Creating an extendable allowed list via the UI
3. Implement this without an allowed list and do it for all HTML elements

I'd prefer #3 if there is a better way than this allowedlist

Okay, here's a slightly different take on this. This issue actually didn't exist for me before the patch in https://www.drupal.org/node/1905798 got committed. (I only know because I'm just now updating a site... *sigh*).

In that commit, this line
content = content.replace(new RegExp('\\s*\\n', 'gi'), "<br />\n");

is replaced with this line
content = content.replace(new RegExp('([^>])\\s*\\n', 'gi'), "$1<br />\n");

Is it possible that fix was actually over aggressive? Specifically:
What it intended to do: Add a line break except when the previous line ends in <br />
What it actually did: Add a line break except when the previous line ends in any HTML tag.

If I could understand half of what's going on in that regex section, I'd take a stab at a patch. Unfortunately, I can't :(. Perhaps some inline comments could make it clearer what each line is doing and prevent similar confusion in the future? Again, I wish I were up to the task, but I think I'd do more harm than good by trying.

For now, using an earlier version of the module (in my case, 6.x-1.4) appears to resolve it.

I'm at DrupalCon this week, working on cleaning up issue queues. I promise, I'll take a look at the patch here and see if it fixes the problems. Then I'll work on making the allowed list a variable, editable in Wysiwyg's admin UI.

Oops, sorry, just saw geerlingguy's latest comment. I'm changing status back to 'Needs Review' again since that seems most appropriate. Thanks in advance!

This works, and we'll take a look at any other elements that may be needed as we see fit. Going to merge this for D7, then work on porting forward to D8 and back to D6.