While shortcodes shouldn't be allowed inside of HTML, should closing shortcodes be allowed "inside" of HTML?

[Viper007Bond]

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

[dd32]

Most of me wants to say that < existing like that is invalid, it should either be encoded or be a HTML tag.. If it were a HTML tag, then the shortcode shouldn't be parsed, as it's no longer within a valid HTML node.

[Viper007Bond]

I've thought about it some more and I think I agree with you.

It also helps that I came up with a workaround for my plugin. :)

I'm going to close this.

[Viper007Bond]

Replying to Viper007Bond:

It also helps that I came up with a workaround for my plugin. :)

​Incase anyone stumbles across this via Google, here's the workaround I ended up using:

​https://github.com/Viper007Bond/syntaxhighlighter/commit/2f4011ab40f1ef5e5fbb507a9c141796802f4a39

The less complex version of that code is just this:

$pattern = get_shortcode_regex( $tagnames );
$content = preg_replace_callback( "/$pattern/", 'do_shortcode_tag', $content );

It's a clone of do_shortcode()'s core functionality so that do_shortcodes_in_html_tags() doesn't get called.

Note that this isn't a great idea for rendering! I'm only using it in the context of escaping shortcode contents when a post is going into the database and decoding them when they're heading to the editor. I'm using the safe do_shortcode( $content, true ) when actually parsing the shortcodes for render.