[wp-trac] [WordPress Trac] #32912: Autosaves are generated every other preview if post is unchanged

WordPress Trac noreply at wordpress.org
Tue Jul 7 22:30:04 UTC 2015


#32912: Autosaves are generated every other preview if post is unchanged
--------------------------+-----------------------------
 Reporter:  mboynes       |      Owner:
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Autosave      |    Version:  trunk
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 I'm trying to work with revisioned post meta and noticed an interesting
 quirk in core today that I'd categorize as "unexpected behavior." While
 this probably wouldn't come up very often, I think it can cause a bit of a
 headache when it does.

 To replicate:
 1. Create a new post, give it a title, and publish it.
 2. Once the screen reloads, click "Preview Changes". Don't make any
 changes to the post.
     * In loading the preview, WordPress created an autosave of this post
 3. Return to the WordPress Admin and click "Preview Changes" again without
 making any changes.
     * In loading the preview, WordPress deleted the autosave it created in
 step 2

 Every other preview will add an autosave and every other one will delete
 it. If at any point you do change the post, the autosave won't get
 deleted.

 In the code, what appears to be happening is, `wp_create_post_autosave()`
 checks to see if an autosave exists. If it does, the code checks to see if
 the autosave is different from the post, and if so, it deletes the
 autosave. If an autosave doesn't exist, the function then creates one
 (using `_wp_put_post_revision()`) -- *without checking to see if the post
 has changed*. It seems to me that there should be an intermediate
 function, e.g. `_wp_maybe_put_post_revision()`, which would check to see
 if the post has changed, and only then call  `_wp_put_post_revision()`.

 This probably isn't a big deal, because it requires someone to attempt to
 preview (twice) without making changes. However, it's still a bug and it
 might come up in other ways.

 Verified in trunk and 4.2.2.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/32912>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list