[nickchomey]

In get_html_split_regex() and _get_wptexturize_split_regex(), the normal-element pattern [^>]*>? ends a tag at the first >, even when that > is inside a quoted attribute value. The rest of the attribute then leaks out as text: wptexturize() curls its quotes, and wp_html_split() callers see a broken tag.

This PR replaces that one pattern in each function. The new pattern is attribute-aware:

(?(?=[a-zA-Z])                                   # Only when < starts a tag:
    (?:[^>=]++                                   #   anything but > and =
     | =[ \t\f\r\n]*(?:"[^"]*"|'[^']*'|[^> \t\f\r\n]*+)  #   = then a quoted or unquoted value
    )*+
  | [^>]*+                                       # Otherwise: trunk behavior.
)>?

• Quotes only matter after =, so quote-named attributes (<div "=noquote id="quote">) parse as before.
• Quotes only matter when a letter follows <, so <=, <3 and </p> split exactly as on trunk.
• The trailing >? keeps the "if not found, match all input" behavior for unclosed tags.
• Possessive quantifiers keep matching speed at trunk parity.

There are no other behavior changes. & encoding, CDATA handling, and existing test expectations are all unchanged from trunk. Type and docblock changes to existing tests are in #14898.

Not addressed: #43785, which is about raw text inside <script>. Fixing it needs HTML API–based segmentation.

Trac tickets:
https://core.trac.wordpress.org/ticket/63997
https://core.trac.wordpress.org/ticket/57381
https://core.trac.wordpress.org/ticket/63426

Use of AI Tools

AI assistance: Yes
Tool(s): VSCode Copilot Chat, OpenCode
Model(s): Deepseek V4 Flash, Claude Opus 5.5
Used for: Diagnosis, the initial fix, and reworking it in response to review. I reviewed and tested the result.

---

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs.

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

Props nickchomey, westonruter, dmsnell.

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

---

Props Bot commands

You can trigger Props Bot actions by commenting on this PR:

• @propsbot add <username> to give props to a GitHub user. Requires write access.
• @propsbot remove <username> to leave a user out of the props. Requires write access.
• @propsbot refresh to refresh this list. Adding the props-bot label works too.

[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.

[nickchomey]

I made another commit that modified the regex a bit further (?:"[^"]*"|\'[^\']*\'|[^<>])*+> in order to handle the edge case in https://core.trac.wordpress.org/ticket/43785. It required some other test cases to change though, but I dont think it matters - it now texturizes invalid html/content.

[nickchomey]

Also took the liberty of addressing a TODO comment in _get_wptexturize_split_regex to replace it with get_html_split_regex(). All tests still pass.

[nickchomey]

I went ahead and added/fixed types and docblocks for all the functions in the two files. Let me know if that was excessive and should be reverted...

[westonruter]

I went ahead and added/fixed types and docblocks for all the functions in the two files. Let me know if that was excessive and should be reverted...

IMO, always better to fix these things up while touching the files already, like you're doing here. 👍🏻

[nickchomey]

@westonruter is there anything remaining here that is blocking this from getting merged?

[nickchomey]

@westonruter is this something that might get merged before the 7.2 beta period starts in 8 days?

[nickchomey]

now that the phpstan warning is resolved, is there anything else that might be blocking merging this?

[westonruter]

🤖 Comment by Claude Opus 5.5

A high effort code review was run on this PR. All changes were compared with trunk. The first three issues were reproduced by running wptexturize() in a local environment. The rest come from reading the code.

None of these issues are caught by the existing tests. The formatting, shortcode, rest-api and comment PHPUnit groups all pass (3243 tests), and PHPStan reports no new errors on the changed lines.

Regressions in output

1. & is now encoded inside CDATA blocks (src/wp-includes/formatting.php ~L708)

wptexturize() now gets its split pattern from get_html_split_regex(), which treats a whole <![CDATA[ … ]]> block as one element. As a result, the & → & encoding runs over the entire CDATA body:

wptexturize( '<script>/*<![CDATA[*/ if (a > b && c) {} /*]]>*/</script>' );
// … if (a > b &#038;&#038; c) …   ← breaks the script

The old texturize-only regex had no CDATA branch. It stopped at the first >, so the code after that point was a text chunk inside <script> and was left alone. Inline scripts in posts and widgets often use this pattern, and no test covers CDATA.

2. A quote in a tag can pair with a quote after the tag's real > (~L682)

In the possessive pattern (?:"[^"]*"|'[^']*'|[^<>])*+>, an unbalanced quote matches up with a quote that comes after the tag ends. The match then hits the next < and fails, and because the pattern is possessive it cannot backtrack. The whole tag ends up being texturized as text:

wptexturize( "<p>Hi</p>\n<a href=\"/x\" title=it's>It's here</a>" );
// <a href=&#8221;/x&#8221; title=it&#8217;s>

A stray quote such as <b class=x">hello</b> behaves the same way. The old [^>]*> pattern handled both cases correctly.

The same mis-split affects other wp_html_split() callers. In do_shortcodes_in_html_tags(), shortcodes in that tag's attributes are no longer recognized as being inside an element. They therefore skip wp_kses_one_attr() and are expanded unsanitized by do_shortcode() later.

3. Unclosed tags are no longer protected (~L682)

Removing the optional >? drops the documented "If not found, match all input" behavior. Truncated tags are now texturized as text:

wptexturize( '<p>Truncated <a href="http://example.com/it\'s' );
// href=&#8221;http://example.com/it&#8217;s

The test edits confirm the change:

• <br [gallery …] … / now produces … (wpTexturize.php ~L1457).
• word <'word now produces ’.
• wpautop output changed too: the rest-comments-controller expectation lost a \n.

Scope

4. & is no longer encoded in any quoted attribute value (~L258)

To fix the Tailwind [&>…] class case, the change stops encoding & → & in every quoted attribute value on every element. That is a much broader behavior change than the ticket needs. For example, <a href="?a[]=1&a[]=2"> now keeps its raw & (the expectations at wpTexturize.php ~L1409/L1413 were changed to match). Ambiguous references such as &copy, &para or &lt in query strings are also no longer neutralized.

A fix limited to the split, so that > inside quotes no longer ends a tag, would solve the swiper case without changing how URLs are encoded.

5. A chunk starting with < is no longer always an element (~L245)

The '<' === $first check assumes every < starts a matched delimiter. With the new regex, an unmatched < can start a text chunk, and that chunk then goes through the element branch.

As a result, whether a mis-split tag is texturized depends on what comes before it. The markup from item 2 is left alone at the very start of the input, but it is texturized after <p>Hi</p>\n. In <p><3 "you"</p>, the text <3 "you" is treated as an element: its quotes are never curled, and its first word goes through _wptexturize_pushpop_element() as if it were a tag name.

Performance and maintainability

6. A PHP closure now runs for every quoted attribute value (~L258)

preg_replace_callback() with a PHP closure now runs for every quoted attribute value of every element. This code runs on hot paths such as the_content, titles and comments, where trunk used a single native preg_replace(). There are two cheaper alternatives:

• a single preg_replace() with (?:"[^"]*"|'[^']*')(*SKIP)(*FAIL)|&(?!…)
• at minimum, a str_contains( $curl, '&' ) guard before the callback

7. Long tags match about 3× slower (~L682)

[^<>] consumes one character per pass through the alternation group. Measured timings:

• A 5 MB unquoted data URI in <img src=…> takes 5.8 ms, versus 1.9 ms on trunk.
• 200k repeats of a < b take 2.1 ms, versus 0.6 ms on trunk.

Every wp_html_split(), wptexturize(), wpautop() and do_shortcode() call pays this cost. Consuming runs of characters at once is cheaper: (?:[^<>"']++|"[^"]*+"|'[^']*+'|["'])*+>.

8. substr( get_html_split_regex(), 2, -2 ) is fragile (~L708)

This depends silently on get_html_split_regex() returning a pattern wrapped in exactly /( … )/. Any later change there, such as adding a flag, switching the delimiter or dropping the capture group, would corrupt the texturize pattern without any visible failure. Also, when there is no shortcode regex, the code just rebuilds the identical regex.

A shared private helper for the inner pattern would avoid this, and get_html_split_regex() could be returned directly when $shortcode_regex is empty.

---

Items 1–3 are worth addressing first, each with a regression test.

[westonruter]

@nickchomey I'm probably not the best to review this further. This is begging for a review from @dmsnell. It may actually become obsolete with KSES being attempted to be shied away from, although I'm not actually sure if wp_html_split() is related in any way to wp_kses_split(), other than both should be using the HTML Tag Processor!

[dmsnell]

@nickchomey I recommend splitting this as the PR currently addresses a number of independent issues.

You can also look at #9270 where I explored replacing wp_html_split() with the HTML API, and #9851 where I was looking at ways we can remove dependency on this function altogether and think about a future where it’s deprecated.

Thanks for your patience with my review pace. I was out of office for a week which didn’t help. There is probably a helpful change in here, but I want to make sure we’re careful and not replacing one broken ad-hoc HTML parser with another before thinking it through. Ultimately, all of these functions are fundamentally broken and need to be replaced with functionality based on the HTML API (or any other sound HTML parsing). Shortcodes are a thorn in that effort for wptexturize() (and I think we will need to make some grammatical changes to them to fix it, which has happened before).

Side note: there’s substantial noise from unrelated type annotations. Those would be more helpful in a separate PR, as those seem mostly non-controversial and don’t change the runtime of WordPress. if we have to revert the change, would be best not to revert those out of necessity.

[nickchomey]

Thanks for the review! I'll try to review and address your feedback in the coming week.

[nickchomey]

(this comment is from Opus 5.5. But I guided and reviewed all of the work that went into the two new commits)

@westonruter @dmsnell I've reworked this PR in response to your reviews. It's now a much smaller hot-fix: only the element pattern in the two split regexes changes. I added commits on top of the existing branch rather than rebasing.

• 899727a: merges in trunk, reverts everything except the pattern change, and adds regression tests.
• a8adc91: only treats quotes as special when < is followed by a letter.

Type and docblock changes to the existing tests are now in their own PR, #14898.

Weston's review items

1. & encoded inside CDATA. Fixed. wptexturize() keeps its own comment-only pattern again, with no CDATA branch. Test: test_ampersand_in_cdata_is_not_encoded.
2. A quote pairing with a quote after the tag's real >. Fixed. Quotes are only special after =, and only when < is followed by a letter.
   • title=it's and <b class=x"> behave the same as on trunk. Tests: test_quote_in_unquoted_attribute_value_does_not_pair_across_tag in both files.
   • <p>x<=' then</p><p>don't</p> also behaves as on trunk. Tests: test_quote_after_non_tag_lt_does_not_pair_across_gt.
3. Unclosed tags no longer protected. Fixed. The >? is back, and every invalid-HTML expectation and the REST roundtrip test are back to their trunk values. Tests: test_unclosed_tag_*.
4. & no longer encoded in quoted attributes. Reverted. Test: test_ampersand_in_quoted_attribute_value_is_encoded.
5. A chunk starting with < not always an element. Fixed by the >?. Every < starts a match again.
6. A PHP closure on hot paths. Removed. It's back to the original single preg_replace().
7. Speed. Back to trunk parity. A 5 MB unquoted data URI takes about 4 ms, and 200k repeats of a < b take about 1 ms, the same as trunk on my machine.
8. The fragile substr(). Removed. Each function keeps its own pattern.

What changes compared with trunk. This is to answer the "how do we know it's better overall" question. The pattern only differs from trunk when all three of these are true:

• the tag starts with < followed by a letter;
• it has a quoted value after =;
• that value contains >.

In that case the tag now ends at the real > instead of inside the value, which is the bug in #63997, #57381 and #63426.

One case to be aware of: when a quoted value is never closed, as in <a title="foo>…, the value now runs to the next matching quote. That's how browsers parse it too.

Testing. The formatting, shortcode and comment groups all pass (3432 tests). PHPStan reports no errors in formatting.php.

#43785 (raw text inside <script>) is not addressed here. As dmsnell said, it needs HTML API work.

[dmsnell]

this is not a CDATA section, so the test is claiming to test one thing and actually testing another, which is whether the ampersand is encoded within SCRIPT contents.

[dmsnell]

I find this test confusing, particularly because it’s not obvious to me from the input and expected output what the failure mode would be. I guess the expectation is that the =' then</p><p>don' would be treated as a single attribute?

these cases can be transformed into self-documented ones just by adding some description.

"Every <p> is a real <p> <=' ain't no attributes <p> either</p>"

[dmsnell]

This should use assertEquivalentHTML() since it’s incidental that the ampersand is encoded as & rather than & or & or the variations of those forms.

then, the test would need to assert that the original unquoted ampersands no longer exist.

assertStringNotContainsString( $texturized, '&a' );

if that assertion doesn’t exist it will need to be emulated.

[dmsnell]

in general, we should be leaning on assertEquivalentHTML() when comparing HTML. this prevents over-fitting in tests which lead to fragile and flakey test suites.

[dmsnell]

I reviewed the wptexturize() tests first, but some of the same comments apply to this file.

[dmsnell]

which may contain >

this is relevant to the PR and ticket under discussion, but largely a distraction for the code it’s commenting. the values may also contain a and ? and ☂️ but we don’t call those out.

the PCRE snippet is obvious, it’s enough to label it as a double-quoted attribute.

[dmsnell]

This PR is now only this pattern, which is your recommended hot-fix

I’m not sure if this comment is already outdated, or was based on an idea that you didn’t end up pushing out, but this pattern extends far beyond my recommendation for a hot-fix but falls short of using the HTML API for parsing. in essence, it’s picking some of the worst tradeoffs of each option and combining them.

maybe you had another thought on this, so I’d like to understand better what was in your head when you wrote this.

[nickchomey]

@dmsnell I apologize for how much this drifted from the direction you gave in your previous review.

I used an AI agent to rework this PR after your and Weston's reviews. I was reviewing its output, but I lost sight of what this PR was meant to do while trying to address every piece of feedback (which I squashed from about 12 to 1 commit before pushing). That's how it became a complete overhaul that tried to handle every edge case that had been mentioned, plus some new ones. I also resolved your threads myself before you had a chance to look at the changes, which I shouldn't have done. I'm sorry for the extra review time this cost you.

I've reduced the PR to a single change to trunk's [^>]*>? in each of the two split functions:

[^>\t\n\f\r \/]*+(?:[^>=]++|=[ \t\f\r\n]*+(?:"[^"]*+"|'[^']*+')?)*+>?

After the tag name, a quoted value following = is skipped as a whole. Everything else, including unquoted values, behaves as [^>]*>? did, so I didn't add a separate unquoted branch.

The leading [^>\t\n\f\r \/]*+ is the one addition beyond that. Without it, a < that doesn't start a tag, as in x <=' y</p><p>isn't, had its quote paired with the apostrophe in isn't, which trunk handles correctly.

One other difference from trunk remains. An unclosed quoted value, as in <a title="foo>bar</a> He said "hi", now runs to the next matching quote, which is how a browser reads it.

On the tests, the misnamed CDATA test is gone, the cases are self-describing, and the wptexturize() test uses assertEqualHTML().

It's entirely possible that this regex is still inappropriate. If you have suggestions to improve it, or would like any other changes, including dropping the tag-name part, please let me know. I'm admittedly somewhat out of my depth with these regexes, which is all the more reason I appreciate the HTML API work you've been doing.

Thank you for your patience with this. I'd appreciate another look when you have time.

[nickchomey]

Oops, i pushed the wrong commit that cut out a bunch of tests (was trying to isolate some things). Will fix shortly.

[dmsnell]

It's entirely possible that this regex is still inappropriate. If you have suggestions to improve it, or would like any other changes, including dropping the tag-name part, please let me know. I'm admittedly somewhat out of my depth with these regexes, which is all the more reason I appreciate the HTML API work you've been doing.

No sweat here. The issue isn’t even the PCRE pattern you are updating, it’s the entire system on top of which it stands, and managing expectations. 🙃

Let’s give a think-over on this for another couple days; I think it’s probably ready, and should be able to make it into WordPress 7.2.

Your diligence through the review feedback is great, so thank you. I think the current modification is the right amount of change without raising questions about all the other broken parsing cases.

[nickchomey]

@dmsnell ah, i pushed another commit that restored some changes before I saw your reply.

I honestly have lost track of how this PR has evolved. Its probably best for me to just look at the overall diff relative to trunk going forward, which is relatively small now. So, it shouldn't be too difficult to refine this in your desired direction.

I think your previous review comments arent even all that relevant anymore, but I'll leave them for you to resolve.