WordPress rewrites wp_kses around the HTML API — plugin sanitisation output can change

WordPress core contributor Dennis Snell's October 7 progress report details an HTML API-based reimplementation of wp_kses(), the longstanding HTML filtering and sanitisation function used by WordPress and its plugin ecosystem. Instead of manipulating HTML-like strings through regex and legacy token handling, the replacement structurally parses input and serialises allowed output. The public wp_kses() interface stays the same, but it can lowercase tags, normalise attributes and character references, remove disallowed script/style elements together with their contents, and discard ambiguous truncated input. A temporary wp_kses_force_legacy_parser filter allows opting back into legacy behaviour while compatibility testing continues. The change is in trunk; whether it lands in WordPress 7.2 or slips to 7.3 remains contingent on testing.

Plugins, themes and publishing integrations routinely pass user-provided markup through wp_kses(). An unchanged PHP function signature does not guarantee unchanged output bytes. Content filters, snapshots, sanitiser unit tests and workflows that inspect sanitised markup can behave differently even where the resulting output is safe. Structural parsing also targets longstanding mismatch risks between server-side filtering and browsers' HTML parsing. For the WordPress plugin ecosystem, that is a meaningful compatibility and security-hardening migration rather than a cosmetic refactor.

The replacement serialises parsed markup consistently: tag names can become lowercase, attributes double-quoted and entities decoded then re-escaped. Developers comparing raw HTML strings or expecting legacy malformed-markup repairs should test with representative content, not only valid HTML.

Under the old default post-context filter, stripping a disallowed script element could leave its text content visible; the new parser removes both element and contents. Incomplete tags at the end of input can be dropped rather than rendered as escaped text. These differences can affect saved content previews, import pipelines and plugin tests without indicating a new vulnerability.

The core progress report documents add_filter('wp_kses_force_legacy_parser','__return_true') to select the old implementation temporarily. Maintainers warn the old path can disappear in a future release or even before WordPress 7.2 final, so this should be a diagnostic fallback, not a permanent compatibility strategy.

WordPress Trac ticket #66208 and the upstream pull request track implementation and tests. The current branch milestone and third-party coverage point toward 7.2, but final inclusion is still under consideration. Test against a current development build and recheck beta/RC notes before making release-specific assertions.