WordPress.org
Get WordPress

Make WordPress Core

Changes between Initial Version and Version 1 of Ticket #14050, comment 5


Ignore:
Timestamp:
03/22/2011 02:10:50 PM (14 years ago)
Author:
aaroncampbell
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #14050, comment 5

    initial v1  
    221. You are more than welcome to update the codex as long as you are clear in describing what exactly is happening, AND clear that this behavior *may* change in the future (as this ticket is not yet "accepted" you shouldn't say *will*).
    331. I'm glad this fix works for you!
    4 1. In #13340 hakre is talking about changes to `wpautop()` and in this ticket we're not suggesting a change to that.  Instead I want to make an adjustment to `shortcode_unautop()`.  The former is used in many places and a small change can GREATLY affect things on the front end of a thousands (or even hundreds of thousands) of sites.  It's used on such a vast array of content that it's almost mind blowing to consider.  However, `shortcode_unautop()` is used far less, and since it's specifically meant to undo what `wpautop()` does to shorcodes, I think it will be safe to effect this change.
     41. In #13340 hakre is talking about changes to `wpautop()` and in this ticket we're not suggesting a change to that.  Instead I want to make an adjustment to `shortcode_unautop()`.  The former is used in many places and a small change can GREATLY affect things on the front end of thousands (or even hundreds of thousands) of sites.  It's used on such a vast array of content that it's almost mind blowing to consider.  However, `shortcode_unautop()` is used far less, and since it's specifically meant to undo what `wpautop()` does to shorcodes, I think it will be safe to effect this change.
    551. This fix will definitely not make it into 3.0.6 because there won't be a 3.0.6 (and if for some reason there is, it will only be for security issues).  Likewise, this was punted from 3.1, which I agree with.  There just isn't time to get something like this in there.  Likewise it probably won't go in 3.1.1 because while I consider it a bug, it's not a regression.  This is how it's worked ever since `shortcode_unautop()` was introduced.  In my opinion 3.2 is the perfect time to try to get this fixed.
    661. I think the article you linked to is fine.  When you update the codex to point out that you get a trailing br on shortcodes, make sure to mention that while this *may* be fixed in the future, right now you can put the shortcodes on the same line as a workaround.