Repository navigation
Preview can show a stale autosave after reverting a published post title #80662
Description
Description
When a published post title is changed, previewed, and then changed back to its published value, the next preview can still show the earlier autosaved title instead of the reverted title.
This only occurs with Real-Time Collaboration disabled.
Step-by-step reproduction instructions
- Ensure Real-Time Collaboration is disabled.
- Create a new post with the title
Sample Pageand some body content. - Publish the post.
- Change the title to
Sample Page 2. - From the editor top bar, select View -> Preview in new tab.
- Confirm that the preview shows
Sample Page 2. - Return to the editor without saving or publishing.
- Change the title back to
Sample Page. - Select View -> Preview in new tab again.
Expected behaviour
The second preview should show Sample Page, matching the published post and the reverted editor title.
Actual behaviour
The second preview still shows Sample Page 2 from the previous autosave.
Screenshots, screen recording, code snippet
autosaveCacheBug.mp4
Additional context
With collaboration enabled, the post carries additional CRDT persistence data alongside its normal title and content changes.
So when the title is changed back to Sample Page, the autosave is still not identical to the published post because its collaboration document metadata has changed. WordPress therefore creates or updates an autosave revision, and Core Data replaces the cached autosave preview link.
With collaboration disabled, the reverted autosave contains only data that matches the published post. WordPress returns the parent post instead of an autosave revision, but Core Data leaves the prior Sample Page 2 autosave preview link in memory. The next preview then uses that stale link.
This is covered by Preview › should not use stale autosave data after reverting title in test/e2e/specs/editor/various/preview.spec.js. The test fails when collaboration is disabled.
Environment info
- WordPress version: 7.1-alpha
- Gutenberg version: 23.6.0-rc.1
- Theme: Twenty Twenty-One
- Browser: Brave
- Device: MacBook Air
- Operating system: macOS
Please confirm that you have searched existing issues in the repo.
- Yes
Please confirm that you have tested with all plugins deactivated except Gutenberg.
- Yes
Please confirm which theme type you used for testing.
- Block
- Classic
- Hybrid (e.g. classic with theme.json)
- Not sure
Activity
ingeniumed commentedon Jul 27, 2026
I looked further into a client-side fix, but Gutenberg does not currently track enough information to distinguish all the relevant cases reliably.
When an autosave is needed, Preview requests one before opening the preview link. If the submitted state matches the published post, Core can return an existing per-user autosave that contains older data. On the client, an untouched editor with a recoverable autosave and an editor that was changed and then reverted can both appear clean. The existing selectors do not distinguish between those situations.
Addressing this on the client would require additional state to track the history and origin of edits. A server-side solution could instead determine whether the autosave returned for Preview represents the submitted state, using its knowledge of revisioned fields and meta.
Changing the server behavior would need careful compatibility review because it could affect the returned resource, the retention of existing autosaves, and autosave recovery. Implementing it only in Gutenberg’s custom controller would also create different Preview behavior depending on whether Gutenberg is active, so the behavior would need to be considered alongside Core’s implementation.
ingeniumed commentedon Jul 28, 2026
I tracked this down to Gutenberg’s collaboration autosaves controller being used even when collaboration is disabled. Its RTC-specific no-op comparison returned the parent post while leaving the previous autosave cached, so Preview continued using the stale autosave link.
Delegating to Core’s autosaves controller when collaboration is disabled fixes the failing Preview test while leaving the RTC path unchanged. I’ll open a PR with the fix and regression coverage.