[LeanderG]

Design proposal

Proposal: proposals/revision-history-blocks-and-repeaters.md

Readable revision history marks edits inside text and rich text fields, but treats blocks fields and repeaters as a single value. On a page built from blocks, any edit produces one "Changed Content" entry, and selecting it scrolls to a summary like "5 blocks". Editors can't see which block changed, or what changed inside it.

This plan extends the version view and change list to blocks and repeater fields:

• Each block and repeater item shows its fields, and edits inside those fields are marked the same way as top-level fields.
• The change list names added, removed, moved and edited blocks ("Edited Headline in the Hero block"). Selecting an entry scrolls to that block or field.

The change is admin-only, with no API, database or public page changes.

I prototyped the behavior locally and tested it on a production-like site with a blocks-based Page collection. Screenshots of the prototype:

Before:

After:

Text can get very long for fields with a long name:

Proposal type

• Feature plan
• RFC
• Amendment, supersession, or withdrawal

Related work

Discussion: none

Amends Readable revision history (#4127, implemented in #4136). That plan lists custom blocks among the fields shown only as "Changed ". This PR updates that line to point to the new plan.

Readiness

• The proposal identifies its author and, for an RFC, its champion and Maintainer sponsor
• The proposal describes observable behavior, compatibility, failure handling, and verification in proportion to its risk
• Conflicting accepted or pending proposals are reconciled in this pull request
• This pull request contains no implementation code
• The proposal status is accepted (check only when ready to merge)

AI assistance

• This proposal used AI assistance — model/tool: Claude Opus 5.5 (Claude Code)

[changeset-bot]

⚠️ No Changeset found

Latest commit: 6902a84

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[LeanderG]

Could we persist _key on repeater items, as we already do for blocks? The repeater editor creates a key for each item but strips it before saving. Without keys, my branch that shows changes inside repeater items has to guess which items match between revisions by comparing their content and position. That guess can miss moves: an item that's edited and moved in the same save shows as edited in place. With stable keys, my branch could match items by key and say exactly which field changed in which item, even after a reorder, without any guessing.

It would be an additive change: repeater values gain a _key property in stored data, the content API, and generated types. Existing revisions have no keys, so their history would only show that the repeater changed, not which item or field.

RFC: #4272