WordPress 7.1 Beta 1 allows editable nested blocks in the HTML block, including content that arrives as raw HTML. The test is not whether a pasted layout looks correct once. It is whether harmless fixtures for invalid nesting, unsupported tags, attributes, URLs, embeds, styles, comments, and block delimiters are handled consistently across roles, save, reload, revision, export, and frontend rendering.
Use this for teams pasting generated HTML, migrating legacy pages, importing documentation, building content converters, or allowing non-administrator roles to edit raw or nested block content.
Quick answer
WordPress 7.1 HTML Block Nested Content Sanitization Test should be handled with a narrow evidence-first workflow: build harmless html fixtures, capture parse and role results, exercise block lifecycle, then verify the result before making broader changes.
What to check first
- Create harmless fixtures for headings, paragraphs, lists, links, images, tables, inline styles, data attributes, unsupported tags, event-attribute labels, malformed nesting, block comments, embeds, and relative URLs.
- Paste each fixture as administrator, editor, author, and contributor where allowed, then capture the input HTML, parsed block tree, validation notices, stored post content, and capability result.
- Save, reload, switch between visual and code views, edit a nested block, duplicate it, move it, transform it, undo it, and restore an earlier revision.
- Compare authenticated preview, published frontend, REST response, feed, export, reusable pattern, theme template, cache, and JavaScript-disabled output.
- Repeat on the latest prerelease and with plugins that filter content, sanitize imports, register blocks, or modify user capabilities.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Build harmless HTML fixtures | Create harmless fixtures for headings, paragraphs, lists, links, images, tables, inline styles, data attributes, unsupported tags, event-attribute labels, malformed nesting, block comments, embeds, and relative URLs. | Input, parsed block tree, stored post content, validation messages, and frontend output are preserved for every fixture. |
| Capture parse and role results | Paste each fixture as administrator, editor, author, and contributor where allowed, then capture the input HTML, parsed block tree, validation notices, stored post content, and capability result. | Unsupported tags, dangerous attributes, invalid URLs, and malformed markup become safe output or a clear validation failure. |
| Exercise block lifecycle | Save, reload, switch between visual and code views, edit a nested block, duplicate it, move it, transform it, undo it, and restore an earlier revision. | Role changes, revisions, transforms, imports, exports, and cache do not restore removed markup. |
| Compare every output | Compare authenticated preview, published frontend, REST response, feed, export, reusable pattern, theme template, cache, and JavaScript-disabled output. | The resulting headings, links, images, tables, and nested controls remain accessible and responsive. |
Why this usually happens
- HTML parsing, block validation, KSES filtering, capability checks, and frontend rendering are separate layers.
- A block can appear valid in memory but serialize differently after save or revision restore.
- Administrators and lower roles may be allowed to store different markup.
- Generated HTML often contains unsupported attributes, inline styles, or malformed nesting that a browser silently repairs.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
fixture_id: HTML-NEST-12
entry_role: editor
input_types:
- valid_nested_structure
- malformed_nesting
- unsupported_tag_label
- event_attribute_label
- relative_and_https_links
parsed_blocks: recorded
stored_output: recorded
frontend_output: recorded
expected: safe_and_stable
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Build harmless HTML fixtures
- Capture parse and role results
- Exercise block lifecycle
- Compare every output
- Retest filters and releases
Decision rule
Approve the workflow only when each allowed role stores predictable safe markup, disallowed content cannot become executable, nested blocks survive the required edit lifecycle, and frontend, REST, feed, export, revision, and no-script outputs agree with the content policy.
What to tell the client or owner
Provide the WordPress build, role and capabilities, harmless fixture, exact input, parsed block tree, validation notices, stored post content, revision behavior, REST and frontend output, theme, active content filters, and expected policy.
Production verification checklist
- Input, parsed block tree, stored post content, validation messages, and frontend output are preserved for every fixture.
- Unsupported tags, dangerous attributes, invalid URLs, and malformed markup become safe output or a clear validation failure.
- Role changes, revisions, transforms, imports, exports, and cache do not restore removed markup.
- The resulting headings, links, images, tables, and nested controls remain accessible and responsive.
Mistakes to avoid
- Do not paste confidential generated content into a public test site.
- Do not use browser auto-repair as proof that stored markup is valid.
- Do not test only with an administrator account.
- Do not disable WordPress sanitization globally to make one imported layout pass.
Questions teams ask during testing
Is AI-generated HTML unsafe by definition?
No, but it is untrusted input until reviewed. The source does not replace validation, role controls, accessibility checks, and inspection of stored and rendered output.
Why can the editor and frontend show different markup?
The editor parser, block serializer, server filters, theme rendering, content plugins, and browser can each transform the content. Capture each boundary instead of debugging only the final pixels.
When HandL WP should help
HandL WP should help when imported HTML breaks after save, lower roles lose content, disallowed markup survives, or the frontend differs from the editor. We can isolate parser, capability, sanitizer, theme, and plugin behavior with controlled fixtures.
If this is active on a production site, audit WordPress HTML block content.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references