wp_staticize_emoji() converts emoji inside code/pre blocks that have attributes

[prakritee08]

[45569] / #47489 fixed convert_smilies() so that emoji and smilies inside ignored tags (code, pre, style, script, textarea) are left alone even when the tag has attributes — for example the block editor's Code/Preformatted blocks, which add class="wp-block-code" to the <pre> tag.

That fix was only applied to convert_smilies(). The identical logic in wp_staticize_emoji() was never updated, so it still only recognizes an ignored tag when the tag closes immediately after its name:

// wp_staticize_emoji() — current
if ( '' === $ignore_block_element && preg_match( '/^<(' . $tags_to_ignore . ')>/', $content, $matches ) ) {

Compare the corrected sibling function:

// convert_smilies() — fixed in #47489
if ( '' === $ignore_block_element && preg_match( '/^<(' . $tags_to_ignore . ')[^>]*>/', $content, $matches ) ) {

Because wp_staticize_emoji() runs on the_content_feed, comment_text_rss, and outgoing mail (wp_staticize_emoji_for_email), an emoji placed inside a <pre class="wp-block-code"> or <code ...> block is wrongly converted to a static <img> in RSS/Atom feeds and email — even though the same content is correctly left untouched on the rendered page thanks to #47489.

Steps to reproduce

1. Create a post with a Code block (or any <pre class="..."> / <code ...>) containing an emoji, e.g. 🙂.
2. View the site feed at /feed/ (or trigger an email containing the content).
3. Expected: the emoji inside the code/pre block is left as-is. Actual: the emoji is replaced with <img class="wp-smiley" ... />.

Proposed fix

Apply the same [^>]* tolerance to wp_staticize_emoji() that convert_smilies() already uses. Patch with unit tests attached.

[prakritee08]

Patch with unit tests attached. This completes the #47489 fix, applying the same [^>]* tolerance to wp_staticize_emoji(), which was missed at the time. Verified locally against trunk: the new test fails without the fix and passes with it; the full Emoji suite (24 tests, 79 assertions) passes.

Description

Emoji inside ignored tags (code, pre, style, script, textarea) should not be staticized, but wp_staticize_emoji() only recognised such a tag when it closed immediately after the tag name. Tags with attributes — for example the block editor's Code/Preformatted block, which adds class="wp-block-code" to the <pre> tag — were not detected, so emoji inside them were converted to <img>.

Because wp_staticize_emoji() runs on the_content_feed, comment_text_rss, and outgoing mail (wp_staticize_emoji_for_email), this affects RSS/Atom feeds and email — even though the same content is left untouched on the rendered page.

This is the same bug that was fixed for the sibling function convert_smilies() in [45569] / #47489, but that fix was never applied to wp_staticize_emoji().

Fix

Apply the same [^>]* tolerance to the ignore-block regex in wp_staticize_emoji() that convert_smilies() already uses.

Testing

Added unit tests covering all five ignored tags, with and without attributes. The new test fails without the fix and passes with it.

Verified locally against trunk:

• New test fails on unpatched code (5 failures), passes with the fix.
• Full Emoji test file passes: 24 tests, 79 assertions.

[westonruter]

@prakritee08 Thanks for the ticket and PR!

Note that you don't need to attach a patch if you already opened a pull request. A PR alone is perfect.