[wp-trac] [WordPress Trac] #24552: Taking over a locked post does not always load the most recent revision

[WordPress Trac]

#24552: Taking over a locked post does not always load the most recent revision
--------------------------+------------------------------
 Reporter:  johnbillion   |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Autosave      |     Version:  3.6
 Severity:  major         |  Resolution:
 Keywords:  needs-patch   |     Focuses:  administration
--------------------------+------------------------------

Comment (by abhishekfdd):

 Confirming the reproduction report from r1k0 in comment:9 and the earlier
 note from jackreichert in comment:6 against current trunk (6.9). Both
 reported symptoms are resolved:

 1. The "There is an autosave of this post that is more recent than the
    version below. View the autosave" notice is shown after a takeover.

 2. The notice is rendered by the standard autosave check on the edit
    screen — independent of how the editor was loaded — so the takeover
    path inherits it automatically. The check lives in both editor
    bootstrap files:

    - Classic editor: `src/wp-admin/edit-form-advanced.php`, the
      `wp_get_post_autosave()` call followed by the
      `mysql2date( 'U', $autosave->post_modified_gmt, false ) >
      mysql2date( 'U', $post->post_modified_gmt, false )` comparison
      that emits the "View the autosave" notice.

    - Block editor: `src/wp-admin/edit-form-blocks.php`, same timestamp
      comparison feeding the editor's autosave-exists state.

    `_admin_notice_post_locked()` in `src/wp-admin/includes/post.php`
    handles only the takeover modal itself and does not need to be
    autosave-aware — by the time the takeover redirect lands on the
    edit screen, the autosave check above runs as it would for any
    other load.

 3. The residual race — User A hasn't autosaved yet when User B clicks
    "Take over", so there is no server-side autosave for User B to be
    offered — was acknowledged as architectural in comment:1 (autosave
    runs on a fixed interval, A's pending changes only persist after
    B has already loaded) and explicitly declined as a fix path in
    comment:3 (the "request to take over" handshake was rejected at
    dev-chat). User A's unsaved keystrokes only exist in their browser
    at that moment; there is nothing on the server for core to load.

 The related concern about User A's stale tab continuing to autosave
 after a takeover and clobbering User B's changes is a different bug
 and is tracked in #55659; it shouldn't gate this ticket.

 Suggesting `worksforme` as the resolution.

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