[wp-trac] [WordPress Trac] #54708: Retain existing autosave when new autosave is the same

[WordPress Trac]

#54708: Retain existing autosave when new autosave is the same
-----------------------------+------------------------------
 Reporter:  adamsilverstein  |       Owner:  (none)
     Type:  defect (bug)     |      Status:  new
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  General          |     Version:
 Severity:  normal           |  Resolution:
 Keywords:                   |     Focuses:
-----------------------------+------------------------------
Description changed by adamsilverstein:

Old description:

> When investigating an issue with previews in block themes not working
> correctly, I found an underlying bug that prevents autosaves from being
> used correctly for previews in some cases. (See
> [https://github.com/WordPress/gutenberg/pull/37622#issuecomment-1002690803
> PR comment]).
>
> In `src/wp-includes/rest-api/endpoints/class-wp-rest-autosaves-
> controller.php` in the `create_post_autosave` function - when the
> autosave sent to the autosave REST endpoint exactly matches the previous
> autosave, the controller **deletes the old autosave revision**, then
> returns an error "There is nothing to save. The autosave and the post
> content are the same."
>
> Deleting the old autosave revision means that later when `src/wp-
> includes/revision.php` `_set_preview` gets called, and it calls
> `wp_get_post_autosave` the autosave is missing, and the preview data
> swaps are not activated.
>
> Note: core calls `add_filter( 'the_preview', '_set_preview' );` in
> `_show_post_preview` which is hooked on `init` in `src/wp-includes
> /default-filters.php`.
>
> The end result of this is that currently if you set a preview image using
> a block theme on a published post and preview it, the featured image is
> not displayed correctly. Skipping deleting the previous autosave fixes
> the issue.

New description:

 Problem: Autosaves are deleting when a new autosave is sent with the same
 data. In the block editor, this causes the preview data to be missing on
 previews.

 Bug exhibited: When using block themes, post previews do not properly
 display the currently set featured image. Several other data
 transformations are also missing because `_set_preview` exits early when
 it can't locate the autosave.

 When investigating an issue with previews in block themes not working
 correctly, I found an underlying bug that prevents autosaves from being
 used correctly for previews in some cases. (See
 [https://github.com/WordPress/gutenberg/pull/37622#issuecomment-1002690803
 PR comment]).

 In `src/wp-includes/rest-api/endpoints/class-wp-rest-autosaves-
 controller.php` in the `create_post_autosave` function - when the autosave
 sent to the autosave REST endpoint exactly matches the previous autosave,
 the controller **deletes the old autosave revision**, then returns an
 error "There is nothing to save. The autosave and the post content are the
 same."

 Deleting the old autosave revision means that later when `src/wp-
 includes/revision.php` `_set_preview` gets called, and it calls
 `wp_get_post_autosave` the autosave is missing, and the preview data swaps
 are not activated.

 Note: core calls `add_filter( 'the_preview', '_set_preview' );` in
 `_show_post_preview` which is hooked on `init` in `src/wp-includes
 /default-filters.php`.

 The end result of this is that currently if you set a preview image using
 a block theme on a published post and preview it, the featured image is
 not displayed correctly. Skipping deleting the previous autosave fixes the
 issue.

--

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/54708#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform