[wp-hackers] Shortcodes + wpautop() & wptexturize()

DD32 wordpress at dd32.id.au
Thu May 22 05:39:38 GMT 2008


I wasnt aware of that, I was mearly replying to Viper007Bond.
If thats the way its supposed to happen right now, then Great! :)

On Thu, 22 May 2008 15:33:25 +1000, Aaron D. Campbell <aaron at xavisys.com>  
wrote:

> 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.
>
> DD32 wrote:
>> 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:
>> [shortcode]
>> Some text
>>
>> Some Text
>> [/shortcode]
>> 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
>>> one.
>>>
>>>
>>> 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
>>> best
>>> 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?
>

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/


More information about the wp-hackers mailing list