[wp-trac] Re: [WordPress Trac] #8553: preg_replace_callback in
do_shortcode returns empty for large posts
WordPress Trac
wp-trac at lists.automattic.com
Wed Jun 17 10:54:49 GMT 2009
#8553: preg_replace_callback in do_shortcode returns empty for large posts
---------------------------+------------------------------------------------
Reporter: AaronCampbell | Type: defect (bug)
Status: new | Priority: high
Milestone: 2.9 | Component: Shortcodes
Version: | Severity: normal
Keywords: needs-patch |
---------------------------+------------------------------------------------
Comment(by Denis-de-Bernardy):
Adding a /x param to make things more readable... The current one is:
{{{
"/
(.?) # optionally catch an extra bracket used to escape
shortcode
\[($tagregexp)\b # begin shortcode
(.*?) # optional attributes (non-greedy, stops on close
bracket)
(?:(\/))? # optional slash to indicate a closing tag, not always
set
\] # closing bracket
(?: # optional content and closing shortcode
(.+?) # the content
\[\/\2\] # close shortcode with a back reference
)?
(.?) # optionally catch an extra bracket used to escape
shortcode
/x"
}}}
you're suggesting:
{{{
"/
(.?) # optionally catch an extra bracket used to escape
shortcode
\[($tagregexp)\b # begin shortcode
([^\]]*?) # optional attributes (non-greedy), equivalent to
using a dot
(\/)? # optional slash to indicate a closing tag, always set
\] # closing bracket
(?: # optional content and closing shortcode
(.+?) # the content
\[\/\2\] # close shortcode with a back reference
)?
(.?) # optionally catch an extra bracket used to escape
shortcode
/x"
}}}
the suggestion in #9264 is the following:
{{{
"/
(.?) # optionally catch an extra bracket used to escape
shortcode
\[($tagregexp)\b # begin shortcode
(.*?) # optional attributes (non-greedy, stops on close
bracket)
(?:(\/))? # optional slash to indicate a closing tag, not always
set
\] # closing bracket
(
?(4) # stop if we already have 4 back references
# it would mean we've a slash bracket
| # else
(?: # optional content and closing shortcode
(.+?) # the content
\[\/\2\] # close shortcode with a back reference
)?
)?
(.?) # optionally catch an extra bracket used to escape
shortcode
/x"
}}}
A few notes:
- Using your patch would remove the possibility for the optimization in
#9264 (since we'd always have.
- Your attribute-related regex might be a bit more efficient from a
performance standpoint.
Personally, I was hoping that the optimization in the other ticket would
allow you to do [foo/] in order to optimize your way through the mess.
All of these patches, however, leave a few fundamental issues behind:
1. Something like [foo[bar] get treated as a foo shortcode with [bar as
an attribute
2. We can get brackets in a shortcode's content, which can potentially
lead to nested shortcodes:
{{{
[foo]bar[][/foo]
[foo][bar/][/foo]
}}}
3. A non-closed shortcode can gobble up an entire document before the
regex bails and decides that it has no closing shortcode:
{{{
[foo]
long document that runs into the backtrack limit starts here
}}}
It's the two last points which I believe are troubling. I take it that
some users actually want brackets in shortcodes, so fixing point 2
probably isn't an option. Bailing after, say, 1000 characters after the
start of the content might be a good bet.
Would you mind attaching your post's source in a text file, exactly as it
is in the WP editor, and specify the plugins you're using?
--
Ticket URL: <http://core.trac.wordpress.org/ticket/8553#comment:36>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list