[wp-trac] [WordPress Trac] #10490: paragraphs inserted round shortcodes by wpautop not working properly for tag-end-tag paits
WordPress Trac
wp-trac at lists.automattic.com
Sun Jul 26 15:57:48 UTC 2009
#10490: paragraphs inserted round shortcodes by wpautop not working properly for
tag-end-tag paits
--------------------------+-------------------------------------------------
Reporter: alanjohndix | Owner:
Type: defect (bug) | Status: new
Priority: normal | Milestone: Unassigned
Component: Shortcodes | Version:
Severity: normal | Keywords: shortcodes, wpautop
--------------------------+-------------------------------------------------
The regex returned by get_shortcode_regex() had a back-reference
'\[\/\2\]' to match balanced tag-end-tag pairs such as "[x]text[/x]". 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/
--
Ticket URL: <http://core.trac.wordpress.org/ticket/10490>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list