escaped shortcodes should not be expanded during 'get_the_excerpt'

[bobbingwide]

It is possible for "the_content" filter to be invoked while processing "get_the_excerpt".

If the do_shortcodes() filter hook is attached to both "the_content" and "get_the_excerpt" then this can lead to an unexpected expansion of an escaped shortcode.

This can lead to unwanted side effects, as reported here.
​http://www.oik-plugins.com/2013/12/escaped-shortcodes-unexpectedly-expanded-get_the_excerpt/

This minor problem can be alleviated by a simple change to strip_shortcode_tag(), returning the HTML code [ as the first character rather than the left square bracket.

function strip_shortcode_tag( $m ) {
	// allow [[foo]] syntax for escaping a tag
	if ( $m[1] == '[' && $m[6] == ']' ) {
		return "[" . substr($m[0], 2, -1) ;
	}
	return $m[1] . $m[6];
}

I don't believe that it's necessary to make the same change in do_shortcode_tag().

[bobbingwide]

patch for 26649

[SergeyBiryukov]

Duplicate of #19927.

[bobbingwide]

Hi Sergey. Thanks for finding 19927 for me. I wondered why my patch had two changes.
The change in 19927 is for do_shortcode_tag()
The second part of the change, in 26649, is for strip_shortcode_tag().

The problem is not exactly a duplicate as the fix for 26649 handles the situation where shortcodes are being removed.

The patch for 26649 will work for 19927 but not vice-versa.
How should this be addressed?

[SergeyBiryukov]

Replying to bobbingwide:

The patch for 26649 will work for 19927 but not vice-versa.

I see, thanks for the clarification. Let's close #19927 in favor if this ticket then.

[SergeyBiryukov]

#19927 was marked as a duplicate.

[SergeyBiryukov]

Related: #12760, #25820.

[dd32]

I tend to agree that simply encoding the shortcode as text makes sense, as that's what the string is after strip_shortcodes() has run.

I would not expect the encoded shortcode to be completely removed, nor would I expect it to be escaped still, so encoding it such that do_shortcode( strip_shortcode( '[[example]]' ) ) doesn't execute the example shortcode makes sense to me.

Trac ticket: https://core.trac.wordpress.org/ticket/26649

Converts escaped shortcodes [[example]] into [example] to prevent do_shortcode from ever executing the shortcode.

Trac ticket: https://core.trac.wordpress.org/ticket/26649

[michaelwp85]

I've created a pull request with a fix and updated unit tests.

There is one scenario in which I revert the html entities back into brackets, this is when an escaped shortcode is used inside an attribute. Specifically for this test scenario: <div style="selector:url([[gallery]])">
If I do not revert the HTML entities will interfere with the processing of safecss_filter_attr stripping the code.

[michaelwp85]

All builds passed so I guess this can be tested :)
This is my first core contribution so any feedback is welcome.

[michaelwp85]

I would love to get this ticket to a closed state. The PR has been reviewed and approved. Is there anything blocking this from being merged? Can I do something to get this to move forward?

[johnbillion]

@dd32 Is this something you can take a look at for 6.9?

[devsahadat]

The issue is valid, and the proposed fix correctly prevents escaped shortcodes from executing unexpectedly. I have tested it, and it works as expected, handling edge cases without side effects.

The approach aligns with strip_shortcodes(), ensuring consistent behavior.

Fixes #26649.

This changeset prevents escaped shortcodes (e.g., [[shortcode]]) from being incorrectly expanded when generating excerpts using get_the_excerpt().

• Temporarily removes all registered shortcodes before applying the get_the_excerpt filters.
• Restores the original shortcode handlers after excerpt generation.
• Ensures escaped shortcodes display correctly without being processed.

[logicrays]

Hello
I've tested the fix, and it correctly prevents shortcode? from executing in get_the_excerpt(). The updated strip_shortcode_tag() handles escaping as expected:

function strip_shortcode_tag( $m ) {
    if ( $m[1] == '[' && $m[6] == ']' ) {
        return '[' . substr($m[0], 2, -1);
    }
    return $m[1] . $m[6];
}

[sachinrajcp123]

This patch ensures that escaped shortcodes like shortcode? are not expanded or parsed during get_the_excerpt(). 🔹 Problem: Currently, even escaped shortcodes may get processed and output unexpectedly in post excerpts. 🔹 Fix: The patch updates shortcode_unautop() to correctly detect and preserve escaped shortcodes by treating them as plain text. 🔹 Benefit: This allows users to display shortcode syntax examples in content or documentation without triggering actual shortcode output. This fix improves shortcode handling and respects user intent when using double square brackets.

Modified strip_shortcode_tag() to return HTML entities ([gallery]) instead of raw brackets

Trac ticket: https://core.trac.wordpress.org/ticket/26649

[micahele]

I allowed for the strip_shortcode_tag() function to return HTML entities ([gallery]) for both the opening and closing bracket to allow for more consistency

[wildworks]

Since the 6.9 RC1 release is coming soon, I will punt this ticket to 7.0.

[michaelwp85]

Replying to wildworks:

Since the 6.9 RC1 release is coming soon, I will punt this ticket to 7.0.

What is the reason to postpone instead of including it as planned?

[wildworks]

Replying to michaelwp85:

Replying to wildworks:

Since the 6.9 RC1 release is coming soon, I will punt this ticket to 7.0.

What is the reason to postpone instead of including it as planned?

Oh sorry, I overlooked the fact that ​PR 8231 has already been approved. However, since more than six months have passed since it was approved, it might need to be tested again.

@dd32 Is it possible to commit this PR to the 6.9 release? Also, ​a new PR has been submitted; do you have any feedback on that?

[michaelwp85]

Replying to wildworks:

Oh sorry, I overlooked the fact that ​PR 8231 has already been approved. However, since more than six months have passed since it was approved, it might need to be tested again.

The PR has unit tests :)

[wildworks]

@michaelwp85 Just in case, I've merged the latest upstream changes into your PR branch.

[dd32]

Punting to 7.0, this needs to be included early in a release cycle, not during beta. This is due to the complex nature of text processing in WordPress and risk of breaking existing code (in core, plugins, or themes) or introducing additional edge-cases of security issues.

The early keyword should signify to committers to review this after the 6.9 release to see if it's something they're willing to pick up.

I'm not personally able to shepperd this into core though, due to focuses elsewhere.