Aaron D. Campbell
aaron at xavisys.com
Thu Jul 29 22:13:33 UTC 2010
Honestly it sounds great. Can we see the code? How does it perform
with long posts or sites with lots of registered shortcodes (I run
against #8553 <http://core.trac.wordpress.org/ticket/8553> fairly often)?
On 7/27/2010 12:40 PM, Jacob Beauregard wrote:
> I wrote my own implementation of shortcodes. It does things a bit
> differently, has nested evaluation, and allows self-nesting. Since
> there are some significant differences to the existing implementation,
> I thought I'd post here to discuss them before trying to convince
> anyone to use my implementation. A lot of the changes are borrowed
> from definitions in the HTML specification (particularly name and
> attribute matching). The following are the comments at the top of my
> shortcode file. I tried to keep track of all the differences (and
> questions) there. If you reply to this, CC me for a more prompt
> response since I'm currently on digest.
> From Test Cases
> Shortcode Statuses (to implement, or not to implement?)
> enabled = the shortcode works as normal (default)
> strip = the shortcode will be parsed and removed. e.g.
> '[shortcode foo="bar"]' produces ''. '[shortcode]foo[/shortcode]'
> produces 'foo'.
> faux = the shortcode will be abbreviated. e.g. '[shortcode
> foo="bar"]' products '[shortcode]'. '[shortocde]foo[/shortcode]'
> produces '[shortcode]'
> disabled = the shortcode is not parsed at all. e.g.
> '[shortcode foo="bar"]' products '[shortcode foo="bar"]'
> Major Differences/Improvements:
> I. Addressing http://codex.wordpress.org/Shortcode_API#Limitations
> 1. You can nest any tag at any depth regardless of ancestors
> (Ticket #10702)
> 2. Tag and attribute names may match
> /[A-Za-z][-A-Za-z0-9_:.]*//* (trialing /* because that comment ends),
> with case-insensitive interpretation
> 3. Interpretation doesn't get tripped up by things like hyphens
> II. Addressing Ticket #12760,
> 1. Changed from fix in #6518
> Reasoning: balancing double-square-brackets can have
> misleading results with nesting
> 2. Shortcodes escapable by using [[, ]]
> 3. ']]' is escaped "right to left", so '[shortcode]]]' would
> evaluate to 'result]'
> 4. '[[' is escaped left to right '[[[shortcode]]]' => '[result]'
> III. Enhancements
> 1. Only matches valid shortcode for registered hooks,
> everything else will appear as text
> 2. Can register multiple hooks to single shortcode, uses
> priority (default: 10)
> IV. Conflicting Design Changes
> 1. Quoted literals are escaped by entities rather than cslashes
> 2. Inline (self-closing) shortcodes get passed content to
> accomodate multiple callbacks
> 3. No equivalent to shortcode_parse_atts function
> (Not marked private in function reference, but not
> documented in shortcode API page)
> 4. Boolean attributes take the place of positional attributes
> [foo bar] gets attributes array('bar' => 'bar') instead of
> array('0' => 'bar')
> 5. Disallows attribute and tag names that don't match
> 6. Disallows unquoted attribute values (also boolean
> attributes), unless they match /[-A-Za-z0-9_:.]+/
> Basic Interpretation Method:
> 1. If an open tag is encountered, it is added to the stack
> 2. If a close tag is encountered and there is no matching open tag on the stack
> the close tag is ignored
> 3. If a close tag is encountered and there is a matching open tag on the stack
> all opened tags on the stack before the matched tag will be
> implicitly self-closed
> 4. If text or an inline tag is encountered, it will be evaluated to its parent's
> content immediately
> 5. If tags are not closed by the end of the interpretation, they will
> be implicitly
> 1. Haven't written new unit tests to reflect new functionality added,
> functionality differences
> 2. Documentation is not as good (though I hope most of the code is
> 3. Not 100% backwards compatible
> I look forward to hearing this list's opinions.
> -Jacob Beauregard
More information about the wp-hackers