[wp-hackers] Shortcodes + wpautop() & wptexturize()
Aaron D. Campbell
aaron at xavisys.com
Thu May 22 05:33:25 GMT 2008
http://trac.wordpress.org/ticket/6444 should have taken care of that,
and it worked without autop for me in 2.5.1. Specifically
http://trac.wordpress.org/changeset/7816 should keep autop from
affecting shortcodes. Having said that, I'll try to take a look at
trunk tomorrow and see if something got messed up.
> My opinion:
> wpautop/wptexturize should ignore the content of shortcodes, and allow
> the shortcode handler to take care of all outputted formatting.
> Else how is the shortcode handler supposed to get the data that the
> user has supplied it?
> If i supply a shortcode:
> Some text
> Some Text
> I want that exact code to be passed along
> The same goes for if it contains special characters, HTML, or anything
> else i can think of.
> I think some trust needs to be given to a plugin if its chose to
> output some HTML, its not allways WordPress's place to stand in and
> dictate how it should speak(the html it outputs).
> On Thu, 22 May 2008 13:56:41 +1000, Viper007Bond
> <viper at viper007bond.com> wrote:
>> This is kinda RE: http://trac.wordpress.org/ticket/6444 but I
>> thought I'd
>> take the discussion up here rather than re-open the ticket or make a new
>> I'm (attempting) to write a shortcode-powered code posting plugin.
>> You type
>> like [code lang="php"]some code here[/code] and it
>> htmlspecialchar()'s it
>> and other things.
>> The problem I'm running into though is both wpautop() and
>> wptexturize() are
>> both ruining the internals of my shortcodes by either formatting them or
>> adding paragraph marks where I have mutli-line code posts.
>> So I can think of three solutions:
>> 1. wpautop() and wptexturize() get modified to not touch the
>> internals of
>> valid shortcodes. I have tickets open for this (
>> http://trac.wordpress.org/ticket/6984 &
>> http://trac.wordpress.org/ticket/6969 ) but I don't know how those
>> will pan
>> out or if it's even the best solution.
>> 2. Bring back the before/after-10 code. This is also probably not the
>> solution as it's ugly and adds tons of excess code.
>> 3. I hook in pre-10 with my own filter, hack the $shortcode_tags
>> global so
>> it only contains my shortcodes, apply do_shortcodes() to the
>> $content, and
>> then put $shortcode_tags back to what it was. My shortcode processing
>> functions will need to replace the code blocks with placeholders that'll
>> survive wpautop() and wptexturize() and then at level 11, I replace my
>> placeholders with the real HTML I want. Ugh.
>> Any thoughts / suggestions on this whole ordeal?
More information about the wp-hackers