[wp-trac] [WordPress Trac] #35856: While shortcodes shouldn't be allowed inside of HTML, should closing shortcodes be allowed "inside" of HTML?

[WordPress Trac]

#35856: While shortcodes shouldn't be allowed inside of HTML, should closing
shortcodes be allowed "inside" of HTML?
--------------------------+-----------------------------
 Reporter:  Viper007Bond  |      Owner:
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Shortcodes    |    Version:  trunk
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 I can't make up my mind if this is a broken edge case or if things are
 working as intended, so I'm opening this ticket. Feel free to close and
 accept my apologies if everything is working as intended.

 I'm aware of the recent changes to shortcodes to prevent `<foo
 [shortcode]>` and why the change was made but was this intentionally
 supposed to break closing shortcodes "inside" of HTML as well?

 Take this example demo code (`unfiltered_html` capability is required):

 {{{
 [test]Did you know that 2 < 3 ?[/test]
 }}}

 {{{
 add_shortcode(
         'test',
         function( $atts, $content, $tag ) {
                 return strtoupper( esc_html( $content ) );
         }
 );
 }}}

 What ends up happening is that `[test]` is parsed as a self-closing
 shortcode (empty `$content`) and you're left with this (actual source):

 {{{
 Did you know that 2 < 3 ?[/test]
 }}}

 Note that the string hasn't been touched and that the closing tag is left
 in the content.

 Is this working as intended?


 The real world thing that caused me to discover this is my
 SyntaxHighlighter Evolved plugin. Details in this forum thread:
 https://wordpress.org/support/topic/php-opening-closing-tags-break-code-
 blocks

--
Ticket URL: <https://core.trac.wordpress.org/ticket/35856>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform