Patterns: Restoring revisions is broken #84809

Activity

1. talldan

   added

   [Type] BugAn existing feature does not function as intendedAn existing feature does not function as intended

   [Feature] PatternsA collection of blocks that can be synced (previously reusable blocks) or unsyncedA collection of blocks that can be synced (previously reusable blocks) or unsynced

   on Oct 15, 2026
2. umeshnevase commented on Oct 15, 2026

   

   umeshnevase

   on Oct 15, 2026

   More actions

   @talldan
   I attempted to replicate the issue on WordPress 7.0 and 7.1.3 but was unable to reproduce it.
3. prasadkarmalkar commented on Oct 15, 2026

   

   prasadkarmalkar

   on Oct 15, 2026

   Last edited by prasadkarmalkar

   Contributor

   More actions

   I am able to replicate the issue locally with the latest Gutenberg. I also noticed that restoring an unsynced pattern converts it into a synced pattern. I will debug more on this.

   
4. davidsword commented on Oct 15, 2026

   

   davidsword

   on Oct 15, 2026

   Contributor

   More actions

   This is broader than patterns, and it's the opposite of not restoring meta: Visual Revisions restores all of the revision's meta, including keys that aren't revisioned.

   restoreRevision fetches the revision's meta and copies the whole object onto the post before saving:

   gutenberg/packages/editor/src/store/private-actions.js

   Lines 712 to 757 in 55d109b

   	const revision = await registry
   	.resolveSelect( coreStore )
   	.getRevision( 'postType', postType, postId, revisionId, {
   	context: 'edit',
   	_fields: [
   	...new Set( [
   	'id',
   	'date',
   	'modified',
   	'author',
   	'meta',
   	'title',
   	'excerpt',
   	'content.raw',
   	revisionKey,
   	] ),
   	].join(),
   	} );
   	if ( ! revision ) {
   	return;
   	}
   	// Build the edits object with all restorable fields from the revision.
   	const edits = {
   	blocks: undefined,
   	content: revision.content.raw,
   	};
   	if ( revision.title?.raw !== undefined ) {
   	edits.title = revision.title.raw;
   	}
   	if ( revision.excerpt?.raw !== undefined ) {
   	edits.excerpt = revision.excerpt.raw;
   	}
   	if ( revision.meta !== undefined ) {
   	edits.meta = revision.meta;
   	}
   	// Apply edits and save.
   	dispatch.editPost( edits );
   	// Exit revisions mode.
   	dispatch.setCurrentRevisionId( null );
   	// Save the post to persist the restored revision.
   	await dispatch.savePost();

   The revisions endpoint returns every show_in_rest key registered for the parent post type, read from the revision ID:

   https://github.com/WordPress/wordpress-develop/blob/2995d9665a205841390f6c5adc6419ac888428fb/src/wp-includes/rest-api/endpoints/class-wp-rest-revisions-controller.php#L715-L716

   A key without revisions_enabled is never stored on the revision, so it comes back as its schema default, or null if that default fails the schema:

   https://github.com/WordPress/wordpress-develop/blob/2995d9665a205841390f6c5adc6419ac888428fb/src/wp-includes/rest-api/fields/class-wp-rest-meta-fields.php#L86-L93
   https://github.com/WordPress/wordpress-develop/blob/2995d9665a205841390f6c5adc6419ac888428fb/src/wp-includes/rest-api/fields/class-wp-rest-meta-fields.php#L571-L573

   For patterns, wp_pattern_sync_status isn't revisioned and only allows partial or unsynced, so the revision returns null. Saving null deletes the key, which is why an unsynced pattern becomes synced. A synced pattern has no stored value, which also fails the enum, so the update errors with "cannot be updated to null":

   https://github.com/WordPress/wordpress-develop/blob/2995d9665a205841390f6c5adc6419ac888428fb/src/wp-includes/rest-api/fields/class-wp-rest-meta-fields.php#L160-L182

   On other post types it's silent: restoring resets every non-revisioned show_in_rest key. Strings are saved as '', keys with a registered default get that default, and non-single keys are deleted. Repro on WordPress 7.1.3 with no plugins:

   1. Register a non-revisioned key:

      add_action( 'init', function () {
          register_post_meta( 'post', 'kept_meta', array(
              'show_in_rest' => true,
              'single'       => true,
              'type'         => 'string',
          ) );
      } );

   2. Create a post with 2 revisions, then wp post meta update <ID> kept_meta hello.
   3. With Preferences > Custom fields off, open Revisions, move to the earlier revision, and click Restore.
   4. The save sends "meta":{"kept_meta":"","footnotes":""}, and kept_meta is now empty.

   Core's classic restore only touches wp_post_revision_meta_keys():

   https://github.com/WordPress/wordpress-develop/blob/2995d9665a205841390f6c5adc6419ac888428fb/src/wp-includes/revision.php#L534-L548

   The editor can't tell which keys are revisioned, since revisions_enabled isn't exposed over REST. So the fix likely needs the server: the revisions endpoint returning only wp_post_revision_meta_keys() in meta, or restoring on the server as #82158 did.
5. prasadkarmalkar commented on Oct 16, 2026

   

   prasadkarmalkar

   on Oct 16, 2026

   Contributor

   More actions

   Thanks @davidsword for the detailed analysis!
   I was looking at an approach that skips null values from the revision's meta in restoreRevision.
   It fixes both pattern cases (the error on synced patterns and unsynced patterns becoming synced). But as you've shown, the root cause is broader than a null check: non-revisioned keys that come back as '', as their default, or as [] would still be overwritten, so it probably needs a server-side fix instead.
6. DevinWalker

   added a commit that references this issue on Oct 16, 2026

   REST API: Only include revisioned meta in revision responses.

   ...

   a332640
7. talldan commented on Oct 19, 2026

   

   talldan

   on Oct 19, 2026

   Last edited by talldan

   ContributorAuthor

   More actions

   Thanks for the testing and diagnosis of the issue.

   I've made a trac ticket (https://core.trac.wordpress.org/ticket/66336) as well for this, which will be needed for the current fix - WordPress/wordpress-develop#14359. (edit: there was an existing trac ticket https://core.trac.wordpress.org/ticket/66329)
8. annezazu

   added

   [Feature] HistoryHistory, undo, redo, revisions, autosave.History, undo, redo, revisions, autosave.

   on Oct 20, 2026
9. annezazu commented on Oct 20, 2026

   

   annezazu

   on Oct 20, 2026

   Contributor

   More actions

   @ellatrix tagging you in this for awareness and in case you can dig in.
10. adamsilverstein commented on Oct 20, 2026

    

    adamsilverstein

    on Oct 20, 2026

    Last edited by adamsilverstein

    Member

    More actions

    The analysis from @davidsword seems right - only the revisioned meta fields should be restored.

    Any empty (revisioned) meta value is valid, so those get restored as well, potentially clearing the field.

    The functionality of restoring a revision should match wp_restore_post_revision_meta from core as closely as possible (exactly).

    👍React with 👍1Reacted by annezazu