WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 4 years ago

Last modified 4 years ago

#10490 closed defect (bug) (duplicate)

paragraphs inserted round shortcodes by wpautop not working properly for tag-end-tag paits

Reported by: alanjohndix Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Shortcodes Keywords: shortcodes wpautop
Focuses: Cc:

Description

The regex returned by get_shortcode_regex() had a back-reference '\[\/\2\]' to match balanced tag-end-tag pairs such as "[x]textx". The regex assumes it will be used 'bare' as a regular expression. However, wpautop adds extra enclosing brackets to be able to refer to the entire matched tags and content. This means that the back-reference instead matches the (optional) preceding letter which is usually blank and thus the closing tag does not match properly.

In the case of single tag-end-tag pair, this means that

[divtag]
abc
divtag

ends up as

<div class="mydiv">
<p>abc</p>
<p></div></p>

This gets more complicated when there are internal tags such as:

[mytag] some [specialsymbol] text mytag

As in some cases the existing .*? for attribute matching chomps everything while it tries to find a '/'.

A simple fix would be to add an optional parameter to get_shortcode_regex($nested=0) and use this to modify the regular expression. This would give the intended match for the shortcode regex, but in fact makes things worse. Looking at the same source:

[divtag]
abc
divtag

it would generate (assuming [divtag] generates a div):

<div class="mydiv"></p>
<p>abc</p>
<p></div>

The attached patch addresses this by adding two new functions to shortcodes.php returning regular expressions for matching begin and end tags separately. wpautop then has two separate preg_replace lines doing the <p> fixes.

At the same time I swopped the .*? for attribute matching to [\]]*?
I guess slightly slower, but doesn't risk chomping the entire post as an attribute.

Note: Sorry, the end tags above all come out odd, but don't know the TRAC editor so don't know how to tell it to treat them as literals. I've done a nicely formatted version of the report at:
http://www.alandix.com/blog/2009/07/26/fix-for-wordpress-shortcode-bug/

Attachments (1)

shortcodes_wpautop_patch_2009_07_26.diff (2.2 KB) - added by alanjohndix 5 years ago.
suggested patch

Download all attachments as: .zip

Change History (6)

alanjohndix5 years ago

suggested patch

comment:1 Denis-de-Bernardy5 years ago

  • Milestone changed from Unassigned to 2.9

see #10082 (dup of this one, in that it's related to the opening/closing shortcode escape), and related bugs.

comment:2 markjaquith4 years ago

  • Milestone changed from 2.9 to Future Release

comment:3 spathon4 years ago

  • Cc spathon added

comment:4 danorton4 years ago

  • Resolution set to duplicate
  • Status changed from new to closed

Duplicate of #10082

comment:5 nacin4 years ago

  • Milestone Future Release deleted
Note: See TracTickets for help on using tickets.