HTML elements contained within <pre>/<code> elements should be displayed not used as inline styling

[Sadr]

First posted here . Similar to #1874.

This is the problem: ​http://i.imgur.com/TWMBl.png, ​http://i.imgur.com/DSEIk.png

The importer could prevent this by ignoring all pre tags, leaving them as plain text.

I think maybe there's a bigger problem at large here though. These posts shouldn't be populated with a bunch of br tags to begin with. bbPress ignores these and makes paragraphs out of every new line anyways, while content inside pre tags is correctly ignored and would display fine if it wasn't for the importer.

[alexvorn2]

what you insert into pre is what is shown, if you insert <br> than <br> will show, look in html editor before posting

[johnjamesjacoby]

Could be possible, though it comes down to what the code used to be, and what WordPress expects it to be now.

I imagine there are cases where stripping and balancing tags will need to be done on a case by case basis. Would be nice had we kept the XHR converter, but I think the direct database connection is faster and smoother for what most of our users expect.

I'm pushing this to Future Release, and it'd be great if someone that has an installation they can test with could own this and fix any formatting issues that come up.

[Sadr]

btw @alexvorn2 I realize I formulated myself rather poorly. I'm talking about code blocks that were inserted without any <br> tags used, and so they first appeared once bbPress1 posts had been converted into bbPress 2 posts. Also I don't want <pre> tags to be ignored all together, I just want the content inside of them to be left unformatted.

Thanks for the reply @johnjamesjacoby. At least we know where this stands.

[netweb]

Import from bbPress 1.x or BuddyPress results in the same behavior (BuddyPress minor markup changes) though the core of the problem is bbPress 2.x is rendering the HTML components <br> & <p> within <code></code> and <pre><code></code></pre> elements when it should not be.

Currently the importer is importing the post_content in a valid form but bbPress 2.2.3 is not rendering as expected.

bbPress 1.2 Topic/Reply using front end editor

`
first line with br<br>
second line with p<p>
third line with br<br>
`

bbPress 1.2 Topic/Reply displayed HTML

first line with br<br>
second line with p<p>
third line with br<br>

bbPress 1.2 raw data via bb_posts.post_test

<pre><code>first line with br&lt;br&gt;
second line with p&lt;p&gt;
third line with br&lt;br&gt;</code></pre>

bbPress 2.2.3 imported post from bbPress 1.2 displayed HTML

Code:

first line with br

second line with p

third line with br

bbPress 2.2.3 imported post from bbPress 1.2 via wp_posts.post_content

<pre>
<div class="bbcode_code">
 <div class="bbcode_code_head">Code:</div>
  <div class="bbcode_code_body" style="white-space:pre">first line with br<br>
  second line with p<p>
  third line with br<br></div>
 </div>
</pre>

bbPress 2.2.3 Topic/Reply using front end editor

<pre><code>
first line with br<br>
second line with p<p>
third line with br<br>
</code></pre>

bbPress 2.2.3 Topic/Reply displayed HTML

first line with br 

second line with p

third line with br

bbPress 2.2.3 via wp_posts.post_content

<pre><code>
first line with br<br>
second line with p<p>
third line with br<br>
</code></pre>

If the extra <div>'s classes and 'Code:' headings need to be ignored/overriden use the 'nbbc' variable BBCODE_VERBATIM to import the 'code' array verbatim with no style changes or define a custom rule using BBCode::RemoveRule and BBCode::AddRule

[netweb]

This can also be replicated on bbpress.org

[netweb]

Possibly related to #1932

[johnjamesjacoby]

This issue exists in WordPress posts and pages also. Closing this as wontfix on our end. We'll need to lean on other code formatting plugins to solve this problem for us.

[johnjamesjacoby]

(In [4640]) Improve the output of code between pre and code HTML tags. Fixes #1967.

[johnjamesjacoby]

(In [4641]) More thorough regex for pre and code tags and HTML entities. Props Corey Worrell. See #1967.

[johnjamesjacoby]

Addressed in 2.3. Will want to keep an eye on this, and look out for any oddities.

[johnjamesjacoby]

(In [4642]) Formatting:

• Rename kses.php to formatting.php.
• Port bbPress 1.1 code and pre tag handling. Comes with filters and callbacks to allow code wrapped in pre & code elements, and backticks.
• Revert r4641, r4640,
• See #1967.

[Sadr]

Thanks for following up on this. Just to be clear, this bug is also the cause of the issues reported here right?

​http://jmonkeyengine.org/forum/topic/pasting-java-code-in-forum-possibly-corrupts-code/

​http://jmonkeyengine.org/forum/topic/theme-updated-sorting-out-some-bugs/page/2/#post-201630

[netweb]

@Sadr Have you tested the above changes from r4642 by downloading /trunk/ and testing it to make sure it is now resolved?

[Sadr]

Replying to netweb:

@Sadr Have you tested the above changes from r4642 by downloading /trunk/ and testing it to make sure it is now resolved?

You know, I was just about to, but I just learned that my personal site (which I also use for testing) has been hacked... No biggy, but this'll have to wait I'm afraid

[johnjamesjacoby]

Reopening to address for 2.3.1.

[johnjamesjacoby]

Audit procedure for posting pre-formatted code in topics and replies:

• Invert code-trick & code-trick-reverse filters to happen pre-save and on output.
• Use esc_html() filter rather than esc_textarea() for textarea output when editing content, to prevent double escaping after above code-trick-reversal.
• Introduce bbp_rel_nofollow() and callback, to handle this on output rather than input, to prevent mucking up preformatted code, and replace wp_rel_nofollow() usages with this.
• Disable visual-editor by default. It's causing code formatting issues when switching between editor types (enable at your own risk in a plugin for now.)
• Fixes #1967

[jeffr0]

Is there anyway we could check and see if this issue occurs today with the Visual editor enabled? At the very least, could we discuss the prospects of returning the visual editor without having users needing to install a plugin or add code to a theme's functions.php file?

It can still be disabled by default but users should have an easy way to turn it on if they so please. Also, just like WordPress, it could be controlled on a per user basis.