Builder Integrity detects WordPress editor and page-builder problems before they become content problems.

WHAT IT DETECTS

When editor state and stored content stop agreeing.

WordPress content can accumulate stale editor signals, malformed block structure, mixed builder state or metadata that no longer matches the content being rendered. Builder Integrity separates those signals before deciding whether anything should be repaired.

A WordPress page can continue to render while its stored editor state is already inconsistent. A page may contain Gutenberg block comments together with builder metadata, old Elementor data can remain after content has changed, or malformed block delimiters can stay hidden until the page is edited again. These conditions are difficult to diagnose from the front end because the visible output may still look normal.

Builder Integrity examines the stored content and editor signals directly. It distinguishes positive builder evidence from weaker historical markers, then classifies the record instead of assuming that one metadata value defines the active editor. This makes the diagnostic result useful before migrations, content cleanup, translation workflows such as REEID Translate, theme changes or troubleshooting unexpected editor behaviour.

WHY CHECK EDITOR INTEGRITY?

Where Builder Integrity helps.

Editor inconsistencies often become visible only when somebody opens a page for editing, changes builders, runs a migration, translates content or updates a plugin. Detecting the state earlier gives you a clearer starting point.

For Gutenberg content, Builder Integrity checks the block-comment structure rather than relying only on whether WordPress can render the page. It can identify orphan closing markers, mismatched delimiters, unclosed blocks, invalid block attribute JSON and malformed WordPress block comments that may otherwise appear as ordinary HTML.

For deeper manual inspection of stored Gutenberg markup, see Gutenberg Block Source Editor.

For Elementor and SiteOrigin, the plugin records builder-specific evidence separately from Gutenberg and Classic content signals. This is useful when a record has been edited by more than one system over time or when old builder metadata remains after a workflow change.

The goal is diagnosis, not aggressive cleanup. A mixed or unusual state is not automatically treated as something that should be rewritten. Records outside the narrow repair rules remain available for manual review instead of being changed automatically.

SUPPORTED IN 0.1.0

Conservative by design.

The first release focuses on detection and diagnosis. Automatic mutation is intentionally limited. Builder Integrity does not attempt broad Gutenberg reconstruction or builder migration.

• Bounded site diagnostics from WordPress admin
• Per-record diagnostics
• WP-CLI scanning
• Gutenberg structural fault detection
• Elementor and SiteOrigin state detection
• Classic/non-block content detection
• Reviewed repair proposal for one narrowly supported missing Gutenberg block closer
• Verified WordPress revision before supported repair
• Post-write validation and rollback attempt on failure

Builder Integrity does not send site content to external services and does not include telemetry.

What the first release does not do

Version 0.1.0 does not attempt general Gutenberg reconstruction, automatic builder conversion, bulk content rewriting or hidden metadata cleanup. Most detected inconsistencies remain diagnostic information unless the plugin can construct a narrowly defined and deterministic repair proposal.

When a supported repair is available, the current content is checked against the reviewed preview, a matching WordPress revision is verified or created, the change is written, and the result is scanned again. If validation fails, Builder Integrity attempts to restore the original content from that revision.

Who is Builder Integrity for?

Builder Integrity is intended for WordPress administrators, developers, agencies and site maintainers who need to understand how content is actually stored before editing, migrating or repairing it. The admin diagnostics provide a bounded site scan and individual record inspection, while WP-CLI provides the same classification workflow for technical audits and larger sites.