A content import can look correct in its source file and change after WordPress sanitises it. The 7 October development report on wp_kses() describes a parser replacement that makes this a useful time to collect real examples from your publishing workflow before WordPress 7.2.
The Core progress report says the replacement uses the HTML API without changing the function’s interface. It also describes behavioural differences for particular inputs. Treat this as development guidance ahead of the full release, rather than evidence that every live site already runs the new implementation.
Test the content your team actually imports
Choose representative HTML from your newsletter archive, product feed, migrated pages or custom publishing integration. Include a normal article and examples containing encoded characters, query strings, embedded markup and incomplete fragments. Keep these copies in an isolated test environment with no customer data.
Record the input, saved content and rendered result separately. A change to serialised HTML can be expected even when the page looks the same. The report describes lower-case tags, double-quoted attributes and normalised character references. A comparison that checks only exact strings could flag harmless differences while missing lost text.
Ask an editor to read the rendered result and a developer to compare the markup. Give both the original input. Without that reference, a missing phrase can look like an intentional editorial choice.
Pay attention to query strings and code examples
The report highlights ambiguous ampersands, including differences between text nodes and attribute values. It advises escaping ampersands when writing HTML and including the semicolon in character references. This matters for tutorials that display URLs as text as well as links that use query parameters.
For a practical test, use one of your own articles containing a displayed URL and a linked URL. Check the visible characters and the actual link destination after saving. Avoid copying the report’s edge cases into a production page merely to see what happens.
Keep the intended destination beside the test result. If a migration tool generates the HTML, fix the escaping in that tool and repeat the test. Editing a single imported post won’t correct the next batch.
Check snippets that previously left visible code behind
When a special atomic element isn’t allowed, the new behaviour removes its contents along with its tags. The report discusses script and style elements as examples. Legacy sanitisation could remove the tags while leaving their text visible.
Inspect historical imports that contain code or styling fragments. A disappearing block may reflect this documented behaviour rather than a broken editor. Move code intended for readers into an appropriate escaped code example; don’t depend on stripped script tags to preserve its text.
The report also describes truncation around incomplete input. Check integrations that split content into fragments before sanitising it. Preserve a failing example for the integration owner so they can investigate the complete input path.
Plan compatibility work without delaying security updates
The development report describes a temporary legacy-parser filter, but warns that the old implementation may disappear, even in 7.2. Don’t build a long-term migration plan around that option. If testing finds a mismatch, record the exact input, environment and output for the developer responsible.
Keep this work separate from routine security maintenance. Our WordPress security update checklist covers the immediate release process. The KSES test set prepares content integrations for a forthcoming change.
Rerun the regression pack against the release candidate and final release, retaining both results in the integration’s change log.
Author
