Formatting: make get_tag_regex() match tags non-greedily (#26674)

[gunjanjaswal]

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

What

get_tag_regex() builds a pattern with a greedy body match:

<iframe[^<]*(?:>[\s\S]*<\/iframe>|\s*\/>)

Because [\s\S]* is greedy, content with more than one tag of the same type matches from the first opening tag all the way to the last closing tag, so both tags — and everything between them — collapse into a single match:

$content = '<iframe src="a"></iframe> text <iframe src="b"></iframe>';
preg_match_all( '#' . get_tag_regex( 'iframe' ) . '#', $content, $m );
// $m[0] currently has ONE entry containing both iframes and the text between.

Fix

Make the attribute and body matches lazy:

<iframe[^<]*?(?:>[\s\S]*?<\/iframe>|\s*\/>)

This is the same pattern core already uses inline in get_media_embedded_in_content() ([^<]*? … [\s\S]*?), so this really just brings the standalone get_tag_regex() back in line with it. With the change, the two iframes above match as two separate entries, and single-tag, multiline-body, and self-closing cases keep matching as before.

get_tag_regex() has no callers in core today (get_media_embedded_in_content() carries its own copy of the pattern), but it's a public function since 3.6.0, so the greedy behavior affects anything outside core that relies on it.

Tests

get_tag_regex() had no test coverage, so this adds tests/phpunit/tests/functions/getTagRegex.php covering a single tag with a body, two adjacent tags matched separately (the regression), a self-closing tag, a multiline body, and the no-match and empty-tag cases. The two-adjacent-tags case fails against the current greedy pattern and passes with the fix.

Notes

This refreshes the long-stale patch on the ticket (it no longer applied against trunk). I kept the self-closing branch as \s*\/> to match the pattern in get_media_embedded_in_content(); @afercia's earlier suggestion to also make the slash optional (\s*?\/?>) would broaden what counts as self-closing, so that feels like a separate decision from the greedy fix and I left it out here.

Props @kopepasah for the report and original patch, and @afercia for the regex review.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props gunjanjaswal, afercia.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[afercia]

Would the test be more meaningful if the passed $content contains also other HTML? To my understanding, the original usage of this function was inside get_media_embedded_in_content() which receives $content A string of HTML which might contain media elements.
I would consider to wrap the current$content passed by the data provider within other content, it could be just a simple div with some text. I'd do it for all the cases in the data provider. Thoughts?

[gunjanjaswal]

Good point — done. Every case now embeds the element(s) inside a containing <div> with surrounding text, so the data reflects what get_media_embedded_in_content() actually receives rather than a bare element. The expected matches are unchanged, since the regex still pulls out just the media element from the larger string. Pushed in ccb22e6.

[afercia]

Fixed in https://core.trac.wordpress.org/changeset/63331, where the commit message missed the # before the ticket number.