[wp-trac] [WordPress Trac] #14481: Shortcode Enhancements

[WordPress Trac]

#14481: Shortcode Enhancements
-------------------------+--------------------------------------------------
 Reporter:  deadowl      |       Owner:                 
     Type:  enhancement  |      Status:  new            
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Shortcodes   |     Version:  3.0            
 Severity:  normal       |    Keywords:  has-patch      
-------------------------+--------------------------------------------------

Comment(by deadowl):

 Replying to [comment:18 aaroncampbell]:
 > I'm assuming we'd still need to keep a stack of registered shortcodes so
 we can use those names in the regex? I've not a regular expressions guru
 by any means (I'm fine at writing them to meet my needs, but it ends
 there), so how advantageous is it to create the regex using the list of
 registered shortcode names?  Also, at what point (if any) does it become a
 problem (what if there are 1,000 shortcodes? 10,000?)? I know that the
 problems it may create are probably edge cases, but I'm curious.

 I factored out most added look-around assertions (since your original
 response), which results in one (not worrisome) change in intended
 behavior. For the expression "[tag]]", the shortcode will be evaluated
 followed by a ]. The expression "]]" is now evaluated in a left to right
 manner, with tag expressions taking precedence. Trying to do assertions
 that a tag ends followed by an even number of right-square-brackets was
 hurting. I can't think of any instances in which extensive backtracking
 may occur now except for the assertion of the tagname being registered.

 With enough elbow grease, that can probably get factored out without
 implying any change in behavior. The problem would be preserving the
 original input that created the tag while still separating the name from
 the attribute list. I think this is more of a goal than tracking whether a
 tag name is valid when it's hooked to remove only the look-around.

 I had originally changed name from shortcode to tagcode because I want to
 call callbacks in a way that's more fluid with apply_filter, and that
 would just about destroy backwards compatibility. I changed to content_tag
 because it's a lot more intuitive and descriptive.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/14481#comment:21>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software