[wp-trac] [WordPress Trac] #14050: shortcode_unautop() should also remove the <br /> added after shortcodes

[WordPress Trac]

#14050: shortcode_unautop() should also remove the <br /> added after shortcodes
----------------------------------------+-----------------------------
 Reporter:  aaroncampbell               |       Owner:
     Type:  defect (bug)                |      Status:  new
 Priority:  normal                      |   Milestone:  Future Release
Component:  Formatting                  |     Version:  3.0
 Severity:  normal                      |  Resolution:
 Keywords:  dev-feedback needs-refresh  |
----------------------------------------+-----------------------------

Comment (by lkraav):

 Above is a squash of the following 4 commits.

 {{{
 * e18aa9f - (HEAD, master) Formatting: shortcode_unautop() should support
 shortcode attributes, see #14050 (17 minutes ago) <Leho Kraav>
 * f05a03e - Formatting: shortcode_unautop() clarifying comment, see #14050
 (17 minutes ago) <Leho Kraav>
 * 2bddf79 - Formatting: shortcode_unautop() should support shortcodes on
 separate lines, see #14050 (17 minutes ago) <Leho Kraav>
 * 2ac5bcd - Formatting: shortcode_unautop should support [footag /], see
 #14050 (18 minutes ago) <Leho Kraav>
 * 6927ba5 - (origin/master, origin/HEAD) Fix JSHint errors in widgets.js.
 (16 hours ago) <Sergey Biryukov>
 ...
 }}}

 Unit tests are separate from SVN because I haven't found a a git repo for
 them yet, and didn't feel like cloning it myself.

 Putting a near-full working day into this made me understand better what
 exactly is going on here. Regex from [18952] is missing many things that
 are standard operation in WordPress for a long time and even seems to
 regress on a couple of features. Seems kind of important to me, because
 HTML output will be broken if the user makes the slightest "mistake" in
 his shortcode entry process. I'm not even sure what the "safe" way to
 enter shortcodes is right now.

 To me, double-linebreak

 {{{
 [foo]

 content

 [/foo]

 [bar]

 [proton]
 }}}

 seems the cleanest and {{{wpautop()}}} is also agreeing with this
 statement so far (#24085).

 Funny thing is, I really don't know what to do with that original test
 case from comment:14. If someone could state the rules / algorithm for it
 in plain English, I could probably patch the regex up for that, too.

--
Ticket URL: <http://core.trac.wordpress.org/ticket/14050#comment:22>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software