HTML API: Add a serialization regression test for enqueued attribute updates

[wppoland]

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

Test-only follow-up to [62960].

[62960] made get_attribute_names_with_prefix() respect enqueued updates, and it landed with 208 lines of tests. All of them are in wpHtmlTagProcessor.php.

The bug had a second surface. WP_HTML_Processor::serialize_token() iterates the names from get_attribute_names_with_prefix( '' ) but reads each value through get_attribute(), so it consumed exactly the stale list the fix corrected. Before [62960] that meant:

• remove_attribute( 'onclick' ) then serialize_token() re-emitted the attribute as a value-less one: <div onclick class="x">
• set_attribute( 'id', 'new' ) then serialize_token() dropped the addition entirely

Both are fixed by [62960], with no change to serialize_token() itself. Neither is covered.

This adds one test to wpHtmlProcessor-serialize.php pinning both directions, so the serialization path cannot silently regress if the name-list logic is touched again.

Verification

Run against tests/phpunit/tests/html-api/wpHtmlProcessor-serialize.php:

• On trunk (63095): OK (1 test, 2 assertions)
• With only class-wp-html-tag-processor.php reverted to [62960]^, source otherwise untouched: fails with

  An attribute enqueued for removal was serialized as a value-less attribute.
  -'<div class="x">'
  +'<div onclick class="x">'
  

So it genuinely exercises what [62960] changed rather than passing vacuously.

Timing

Tests only, no source changes, so this is safe during RC, but nothing breaks if it slips to 7.2 instead. Entirely the committers' call.

Background: I raised this serialization symptom on the ticket at comment:15 while the fix was still being chosen between four competing PRs, and offered the test to whichever branch was picked. #12757 landed without it, so I am submitting it here rather than letting it drop.

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

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.

[irozum]

Good, well-targeted follow-up — it closes a real coverage gap left by [62960]: that fix covered get_attribute_names_with_prefix() on WP_HTML_Tag_Processor (208 lines of tests) but never exercised the same stale-name-list bug on WP_HTML_Processor::serialize_token(), which reads through get_attribute() off that same name list.

I verified the claims in the PR description by hand: reverted class-wp-html-tag-processor.php to its pre-[62960] state and confirmed the new test fails exactly as described (<div onclick class="x"> instead of <div class="x">), then restored it and confirmed it passes. Ran the full Tests_HtmlApi_WpHtmlProcessor_Serialize suite (133 tests, all green) plus composer lint:errors and typecheck:php — both clean aside from pre-existing violations in unrelated files.

No blocking concerns — test-only change, correct @ticket/@covers tags, follows the surrounding file's conventions. One minor observation: the second assertion (set_attribute() case) uses assertStringContainsString rather than pinning the full serialized output the way the first assertion does — reasonable if attribute ordering isn't guaranteed, but worth confirming that's the reason rather than an oversight.