A different sanitized HTML string is not necessarily a broken page. Test the visible result and the security boundary separately when preparing for the wp_kses implementation based on the WordPress HTML API.
Treat this as development compatibility work
The Core progress report describes output normalization and changes in how some elements are removed. The October developer update places the work in the 7.2 or 7.3 window depending on testing. As of October 16, do not assume the final release target is settled.
Run the comparison on isolated builds and record the exact revision. A PHP fatal in an allowed-HTML filter is a different failure from normalized markup; use the allowed-HTML callback guide if execution stops before you receive output.
Assemble fixtures from the real feature
Choose a small set of synthetic inputs representing a product description, form notice, email fragment or another feature your plugin actually processes. Record the sanitizer function, allowed elements, allowed attributes and the caller. Do not silently substitute wp_kses_post for a narrower application-specific allowlist.
Include ordinary formatted text, a link with multiple query parameters, an image with a caption and a harmless example of markup the feature intentionally rejects. Keep the rejected examples inert in your test harness. Do not paste untrusted HTML into a live administrator screen to see what happens.
Revision: Identify both exact builds. Security: Rejected behavior stays rejected. Rendering: Allowed content remains usable. Report: Minimal synthetic reproduction. Explanatory checklist, not a customer test result.
Compare three layers
- Save the input fixture exactly, including its encoding. A copy-and-paste transformation can make two builds appear different when their inputs differ.
- Capture the output string from each build. Note tag casing, attribute quoting and entity changes without immediately marking them as defects.
- Render the sanitized output in an isolated preview. Confirm the intended text, destination URLs and layout, then check that disallowed behavior remains absent.
For example, a byte-level snapshot can fail because quotes were normalized even though the link still reaches the correct destination. Conversely, a visually similar link can contain a changed query value. Check parsed attribute values as well as appearance.
Do not weaken sanitization to satisfy a snapshot
When a fixture fails, decide whether the contract is the exact serialization or the document's meaning. Search indexing, export signatures and downstream string comparisons can have different requirements. Document that requirement instead of broadly allowing script elements or event handlers.
The progress report mentions a temporary legacy-parser option. Treat it as development troubleshooting information whose availability must be rechecked, not a permanent security strategy. Any temporary mitigation needs an owner, a removal condition and a test of the corrected path.
Report a reproducible compatibility issue
Provide the smallest synthetic input, expected visible behavior, actual sanitized output, allowlist and exact builds. Explain why the difference matters to the application. Do not attach private form submissions or complete customer content exports.
Keep both semantic tests and a few intentional serialization tests where exact bytes truly matter. If your site loses essential content after an update, ask HandL WP to isolate the sanitizer and caller before changing global HTML permissions.
References reviewed October 16, 2026. Examples are explanatory, not customer test results.