Full HTML in WYSIWYG editor breaks Quote

See the top line of admin/settings/quote:

The quote filter will need to be enabled for each input format (as required). Please make sure that the quote filter is arranged after any HTML filters and before the line break filter. 

Re-opening this issue instead of creating a new one because this appears to be the issue I'm having, however the solution in #2 doesn't appear to fix it.

I'm using the CKEditor library with the WYSIWYG module. It appears that when hitting the quote button, there is a paragraph tag getting wrapped around the [quote=username] and [/quote] tags inside the wysiwyg editor.

Original post
<p>So... when is this survey coming out to vote on cost-cutting sugestions?</p><p>Are only paid union members going to get to vote on this?</p>

Quoted Response
<p>[quote=harlow]</p><p>So... when is this survey coming out to vote on cost-cutting sugestions?</p><p>Are only paid union members going to get to vote on this?</p><p>[/quote]</p>

I have the quote filter second to last in the filter list, followed by line break filter. So I'm not sure what would be wrapping the paragraph tags around the quote tags.

Any other thoughts on configuration changes?

This is still present in the latest beta, changing Version with this post.

I don't believe that the behavior is caused by the Quote module, however. I can debug this by changing the comment_body field Text Processing to Plain Text. When this is done, and the textarea is no longer injected with any JavaScript processing, the output becomes:

[quote=admin]<p>idk</p>[/quote]

Instead of the undesired behavior noted in this issue:

<p>[quote=admin]</p>

<p>idk</p>

<p>[/quote]</p>

Now, I'm using CKEditor, and tackling this from the Text Formats configuration in admin/config/content/formats/filtered_html, where we can disable:

"Convert line breaks into HTML (i.e. <br> and <p>)" 

Disabling this does not prevent the issue behavior. In fact, none of the text filters there are causing this.

So I go into CKEditor configuration at admin/config/content/ckeditor instead, and for the Filter Profile I'm testing with I change the option "CLEANUP AND OUTPUT" -> "Enter mode" to:

<br>

Then I get the following output on a comment quote in that CKEditor textarea:

[quote=admin]<br />
idk<br />
[/quote]

And there we have it. Quote module is not causing this behavior, at all. The chosen WYSIWYG editor is, and as #3 notes, this makes two issue respondents that have pointed at CKEditor as their cause.

The one facet of this where Quote can change to fix the issue is to not inject newline characters around the quoted data. That should close this, since CKEditor is probably just matching the newlines and dutifully performing a regex.

With Enter Mode set as in #4, I'm getting fairly normal behavior from Quote + CKEditor, now. I've tested some stupidly deep quote nesting, and one of the less stupid results comes out like this:

[quote=admin][quote=admin]This is a test<br />
<br />
A test of the<br />
<br />
Emergency debug system[/quote]<br />
<br />
Consider that tested.<br />
<br />
Yes.[/quote]

The first [quote=admin] line is going to grow into eternity, and I've seen that in plenty of forum software. However, the important bit here is that we aren't getting the issue behavior with this configuration. It also means that we don't get to use paragraph styling for the comment content.

The DOM semantics of this method are far better than without it.

I'm leaving the issue open, but lowering it's priority.

Great find!

Any idea how / where we could patch the newline in the quote module?

I've looked into the module where [quote] and \n are used, and \n appears only once, and only at the end of:

$quote = "[quote=$author]" . trim($content) . "[/quote]\n";

I believe that $content is getting \n before and after it from somewhere else, perhaps upstream from the Quote module.

Ultimately, this really is an issue for the WYSIWYG module, or even the individual editors, to handle. The vectors from which this issue can come from are far too numerous, and we're already doing a silly amount of string manipulation in Quote.

One vector which we'd have absolutely no control over here is the JavaScript of the WYSIWYG editor in the browser. I suspect that the database field for Enter Mode on the CKEditor configuration is being used in a conditional statement somewhere in CKEditor's JavaScript to choose conditionally which of the methods to use on the textarea contents. I expect it to be there because the JS code needs to know that fact every time you press the enter key, and the same behavior is fired (like an event) when data goes into the textarea at page load.

Considering that, then we know that every time the user presses enter key with cursor positioned after [quote], we are going to trigger the WYSIWYG JavaScript event. Now, do we want that event to cause a BR or a P tag when it fires? I will choose BR. The only way around that is to change the JavaScript logic, not the PHP logic.

Now that the issue is understood more deeply, with a viable workaround published, I'm changing status again and renaming for clarity.

Starting with a nested quote that was posted through Filtered HTML with fairly tight tag limits, and also following lessons from #4 and #5:

[quote=admin][quote=admin]This is a test<br />
<br />
A test of the<br />
<br />
Emergency debug system[/quote]<br />
<br />
Consider that tested.<br />
<br />
Yes.[/quote]<br />

Then switching the comment Text Format to Full HTML, I produce this in the text area:

<p>[quote=admin][quote=admin]This is a test<br />
<br />
A test of the<br />
<br />
Emergency debug system[/quote]<br />
<br />
Consider that tested.<br />
<br />
Yes.[/quote]<br /></p>

The result output when posted to the forum will not match. It will actually be:

<p>[quote=admin][quote=admin]This is a test</p>
<p>A test of the</p>
<p>Emergency debug system[/quote]</p>
<p>Consider that tested.</p>
<p>Yes.[/quote]<br></p>

The screen rendered result will look like:

[quote=admin][quote=admin]This is a test

A test of the

Emergency debug system[/quote]

Consider that tested.

Yes.[/quote]

Although the source content being quoted was rendered correctly by Forum and parsed correctly (under a different Text Filter) by Quote, this time the whole nest of quotes will completely break. That's just another case that isn't covered by Quote's string manipulation.

This shows that Full HTML WYSIWYG is simply incompatible with the module. We're going to waste CPU cycles fixing it as-is. It could be fixed, but probably shouldn't be done with another minor patch that adds more string manipulation. There are already too many stacks of filtration applied to this content field, and layout HTML tags are the root cause, anyway.

I think that the correct solution is two-fold:

1) We don't apply the Quote module to any field where P, DIV, or any page layout/structure tags are allowed (why would we?)

2) Anyone who REALLY wishes that they could post and quote whole Full HTML Forum Topic Nodes should be looking at coding a way to leverage the node revision history system, so that the revision of the node, at the time that the user selects to quote that node, is stored and used as the reference for their reply node. This is probably the best way to objectively work with the quoted node data so that it can handled cleanly in the destination node.

The root problem here is that users of Quote want to allow use of HTML tags that Quote itself needs to control tightly, in order for Quote to do what it is trying to do with the quoted content. Quote views the entire content data as one long string, and has to deal with every edge case we throw at it.

HTML within HTML string manipulation ALWAYS gives us these fun fights. You can't get what we want without very foresighted objective separation of the HTML data around the quoted material, and the quoted content itself. Part of that is scrubbing the quoted content of things that will break the surrounding content.

The solution is to not allow users to input any HTML tag that Quote, Forum, Drupal, et. al. require in order to safely and accurately render the page.

This is why BBCode even exists.