Sanitization changes can improve security while breaking custom block attributes, embedded markup, patterns, reusable content, REST updates, or older saved HTML. The risky case is not only a visible editor error. Content can also appear correct in one role while another role loses fields, or the editor can silently rewrite markup that the front end still expects.
Use this for sites with custom blocks, raw HTML, embeds, patterns, reusable blocks, role-specific editing, headless REST updates, or legacy content created by older plugin versions.
Quick answer
Create a fixture page from production examples before updating. Save the raw post content and rendered HTML, then open, edit, save, REST-update, duplicate, and render the fixture under administrator and editor roles on the current 7.1 release candidate. Compare attributes, invalid-block notices, KSES output, front-end DOM, and security payload rejection without repairing markup by hand during the test.
What to check first
- Collect representative serialized block markup, custom attributes, embeds, patterns, reusable content, and raw HTML from approved production pages.
- Save baseline post_content, REST output, rendered HTML, screenshots, role, plugin versions, and theme version before the RC test.
- Open and save the fixture as administrator and editor, then repeat through the REST API or headless publishing path.
- Compare removed tags, escaped attributes, invalid-block recovery, block validation warnings, and front-end DOM changes.
- Include safe content plus deliberately unsafe scripts, event handlers, URLs, and malformed comments to prove the security boundary remains closed.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Legacy custom block | Serialized content from the oldest supported plugin version | Approved attributes survive and block stays valid |
| Editor role | Same fixture saved by a non-admin author | Allowed content remains and forbidden markup is removed |
| REST update | Headless client sends known block markup | Stored and rendered results match the role policy |
| Unsafe payload | Script, event handler, and javascript URL fixtures | Payload is rejected or sanitized without executing |
Decision rule
Approve when approved content round-trips without silent loss, invalid legacy markup has a documented migration, non-admin roles keep only allowed capabilities, and unsafe tags, attributes, and URLs cannot execute on the public page.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Build the approved and unsafe fixture set from real content patterns.
- Identify whether the change belongs to block serialization, KSES, REST permissions, or rendering.
- Update the custom block schema and migration instead of broadly allowing unsafe HTML.
- Add backward-compatible transforms for approved legacy markup.
- Repeat role, editor, REST, and front-end tests before release.
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Build the approved and unsafe fixture set from real content patterns. | Collect representative serialized block markup, custom attributes, embeds, patterns, reusable content, and raw HTML from approved production pages. | Baseline and post-save serialized content differ only where the migration expects. |
| Identify whether the change belongs to block serialization, KSES, REST permissions, or rendering. | Save baseline post_content, REST output, rendered HTML, screenshots, role, plugin versions, and theme version before the RC test. | Custom blocks remain editable and valid for supported roles. |
| Update the custom block schema and migration instead of broadly allowing unsafe HTML. | Open and save the fixture as administrator and editor, then repeat through the REST API or headless publishing path. | REST and editor saves enforce the same intended security policy. |
| Add backward-compatible transforms for approved legacy markup. | Compare removed tags, escaped attributes, invalid-block recovery, block validation warnings, and front-end DOM changes. | Unsafe fixtures are removed or rejected and never execute in editor preview or front-end HTML. |
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
# Export the fixture before testing
wp post get 4242 --field=post_content > before-blocks.html
wp post get 4242 --format=json > before-post.json
# Save through each supported role and API path, then export again
wp post get 4242 --field=post_content > after-blocks.html
diff -u before-blocks.html after-blocks.html
Production verification checklist
- Baseline and post-save serialized content differ only where the migration expects.
- Custom blocks remain editable and valid for supported roles.
- REST and editor saves enforce the same intended security policy.
- Unsafe fixtures are removed or rejected and never execute in editor preview or front-end HTML.
Why this usually happens
- Block validation compares serialized markup while KSES and REST permission checks can transform content on a different path.
- Custom blocks may store HTML in attributes that were never declared or sanitized consistently.
- Older content can depend on markup accepted by a past plugin version but no longer generated by the current editor.
Field notes
- Use a cloned production post and never test unsafe payloads on a public page.
- Keep raw baselines in a protected artifact store because screenshots cannot reveal serialized attribute loss.
- A security test passes only when malicious markup fails and approved content remains usable.
Mistakes to avoid
- Do not change several production layers at once. Preserve the failing evidence and isolate one variable per test.
- Do not use a successful status or screen message as the only proof. Verify the business outcome and the underlying record.
- Do not leave debug logging, broad credentials, test orders, or temporary exceptions active after the review.
- Do not close the incident without recording the fixture, timestamps, owner, result, and rollback point.
What to tell the client or owner
Give the owner the affected versions, exact fixture, stable IDs, UTC timeline, before and after evidence, decision, rollback point, unresolved risks, and next review date.
Questions teams ask during testing
Can this be tested on staging?
Start on staging with production-like versions, cache, data shape, and integrations. Finish with one controlled production fixture when the result depends on real routing, provider, or edge behavior.
What evidence should be retained?
Keep the smallest useful set: stable IDs, UTC timestamps, sanitized request or log excerpts, expected result, actual result, version inventory, and the final verification.
When should the change be rolled back?
Roll back when a revenue, privacy, security, or publishing path fails and the cause cannot be isolated inside the approved maintenance window.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, test WordPress block compatibility.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references