[wp-hackers] Shortcodes

[scribu]

This looks like a big step forward.

I think you should open a ticket on trac with your imppementation as a
patch, so we can discuss specifics.

On Tuesday, July 27, 2010, Jacob Beauregard <deadowlsurvivor at gmail.com> 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
> (http://svn.automattic.com/wordpress-tests/wp-testcase/test_shortcode.php)
> ==========================================================================================
> 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
> /[A-Za-z][-A-Za-z0-9_:.]*/
>
>         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
>    self-closed
>
>
> Issues:
> =======
> 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
> self-explanatory)
>
> 3. Not 100% backwards compatible
>
> ---
> I look forward to hearing this list's opinions.
> -Jacob Beauregard
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>

-- 
http://scribu.net