Make WordPress Core

Opened 4 years ago

Last modified 13 months ago

#36836 assigned enhancement

Two different preview saving processes cause confusion with editorial teams

Reported by: sc0ttkclark Owned by: adamsilverstein
Milestone: Priority: normal
Severity: normal Version:
Component: Revisions Keywords:
Focuses: Cc:


When post_preview() runs from the post editor when editing a draft, it will save over the draft if:

  • The post is not locked by someone else AND
  • You are the author of the post AND
  • The post status is currently 'draft' or 'auto-draft'

However, when dealing with a published post, none of those are hit so an auto-save is created with wp_create_post_autosave().

This establishes two separate workflows for an editorial team to be aware of:

  • In some cases, when previewing a post, your changes will overwrite the current post
  • In other cases, when previewing a post, your changes will safely be saved to a new autoave for preview purposes

I propose we always run wp_create_post_autosave(), even if the post is a draft, removing the edit_post() call in post_preview() if the post status is a draft / auto-draft. This establishes clear and consistent saving handling when previewing a post.

Change History (2)

#1 @adamsilverstein
4 years ago

  • Owner set to adamsilverstein
  • Status changed from new to assigned

#2 @sc0ttkclark
4 years ago

Use-case example:

  1. Editor goes into a draft post, makes a couple of changes to formatting
  2. Clicks Preview
  3. Decides they don't want to make those changes after all
  4. Closes preview post tab in browser, leaves post editor without explicitly saving the draft

The assumption by the editor (and rightfully so) is that when making a change but not explicitly saving the draft -- those changes will not be saved onto the current version of that draft until they are ready to.

This currently happens as expected for posts that do not have the 'draft' or 'auto-draft' posts.

Note: See TracTickets for help on using tickets.