Skip to:
Content

bbPress.org

Opened 7 years ago

Closed 7 years ago

Last modified 5 years ago

#1967 closed defect (fixed)

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

Reported by: Sadr Owned by:
Milestone: 2.3.1 Priority: normal
Severity: normal Version: 2.1
Component: General - Content Creation Keywords:
Cc: e.soghe@…

Description

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.

Attachments (1)

1967.patch (11.9 KB) - added by johnjamesjacoby 7 years ago.

Download all attachments as: .zip

Change History (19)

#1 @alexvorn2
7 years ago

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

Last edited 7 years ago by alexvorn2 (previous) (diff)

#2 @johnjamesjacoby
7 years ago

  • Milestone changed from Awaiting Review to Future Release

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.

#3 @Sadr
7 years ago

  • Cc e.soghe@… added

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.

#4 @netweb
7 years ago

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

#5 @netweb
7 years ago

  • Component changed from Importers to Content Creation
  • Milestone changed from Future Release to Awaiting Review
  • Summary changed from bbPress1 importer populates posts with redundant br tags to HTML elements contained within <pre>/<code> elements should be displayed not used as inline styling

This can also be replicated on bbpress.org

#6 @netweb
7 years ago

Possibly related to #1932

#7 @johnjamesjacoby
7 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

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.

#8 @johnjamesjacoby
7 years ago

  • Resolution changed from wontfix to fixed

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

#9 @johnjamesjacoby
7 years ago

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

#10 @johnjamesjacoby
7 years ago

  • Milestone set to 2.3

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

#11 @johnjamesjacoby
7 years ago

(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.

#12 @Sadr
7 years ago

  • Cc e.soghe@… removed

#13 follow-up: @netweb
7 years ago

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

#14 in reply to: ↑ 13 @Sadr
7 years ago

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

#15 @Sadr
7 years ago

  • Cc e.soghe@… added

#16 @johnjamesjacoby
7 years ago

  • Milestone changed from 2.3 to 2.3.1
  • Resolution fixed deleted
  • Status changed from closed to reopened

Reopening to address for 2.3.1.

#17 @johnjamesjacoby
7 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

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

#18 @jeffr0
5 years ago

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.

Note: See TracTickets for help on using tickets.