Editor: page with Cards Collection queries is dirty on every load — phantom 'unsaved changes' in the Site Editor save panel

[georgeolaru]

Symptom

Opening the Site Editor (or editor) on the Mies homepage (page 52 on the SM dev site) marks the page entity dirty before any interaction: wp.data.select('core').__experimentalGetDirtyEntityRecords() lists postType/page/52 with edit keys selection, content, blocks on a fresh load. Consequences for every user on this stack: the save panel always shows an extra 'site change' (e.g. '2 site changes' when only Style Manager was edited), and closing the tab warns about unsaved changes the user never made. Reproduced consistently during the Style Manager Site Editor sessions of 2026-06-12.

What's established

• PHP-side serialization is stable: serialize_blocks( parse_blocks( content ) ) round-trips byte-identical — the normalization happens in the editor's JS layer (block validation / deprecation migration / markup regeneration).
• The first core/query block on the page carries a non-canonical taxQuery shape: \"taxQuery\":{\"include\":{\"post_tag\":[63]}} (nested include), while core's canonical shape is flat ({\"post_tag\":[63]}) and Nova Blocks' own supernova edit.js consumes the flat shape (Object.entries(taxQuery) → slug → terms). Legacy content from an earlier query-extension era is the prime suspect.
• Nova Blocks' core/query extension (packages/core/src/blocks/core/query) is edit-UI-only (no schema/save filters) — not a serialization suspect by itself.
• A Node round-trip harness with registerCoreBlocks() under jsdom hangs (editor-store side effects), so the byte-level diff needs an editor session.

Pinpointing (3 lines in the editor devtools, next session)

const { getEditedEntityRecord, getEntityRecord } = wp.data.select('core');
const edited = wp.blocks.serialize( getEditedEntityRecord('postType','page',52).blocks );
console.log( edited === getEntityRecord('postType','page',52).content.raw ); // find first diff index when false

Suggested direction

Whatever attribute/markup the editor normalizes should get a proper deprecation entry (or a content migration) so parses are stable — silent re-serialization dirt punishes users on every page load. If the nested taxQuery.include shape is ours from an older release, a deprecation that migrates it to the flat shape (or a save filter that tolerates it) removes the dirt at the source.

[georgeolaru]

Sharper diagnosis from a Node round-trip harness (@wordpress/blocks parse/serialize with core blocks registered, run against page 52's saved content):

• Ten core blocks on the page fail validation / hit migration paths: core/group ×2, core/heading ×5, core/html, core/paragraph, core/button. That pattern is stale-era markup — e.g. pre-WP-6.2 headings (missing the wp-block-heading class that 6.2's deprecation migrates in), old button/group structures. Blocks that validate through a deprecation get their markup silently regenerated on every parse → the content edit → phantom dirty on load.
• The core/query taxQuery shape may be a secondary contributor but the heading/button/group migrations are the bulk.
• Caveat: the harness used block-library 7.3.1, newer than WP 7.0's shipped definitions, so exact byte diffs include version skew — the invalid/migrating set is the reliable signal. Confirm in an editor session with the devtools snippet in the issue body.

Direction this suggests: this is content staleness in the starter/demo content rather than a Nova Blocks code bug — the durable fix is refreshing the shipped starter content through a current editor save (and for live sites, a one-time 'open + save' or a CLI re-serialization pass), plus ensuring NB's own blocks aren't adding to the migration set.