Make WordPress Core

Opened 9 years ago

Closed 4 years ago

Last modified 4 years ago

#36836 closed enhancement (wontfix)

Two different preview saving processes cause confusion with editorial teams

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

Description

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 (4)

#1 @adamsilverstein
9 years ago

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

#2 @sc0ttkclark
9 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.

#3 @adamsilverstein
4 years ago

  • Resolution set to wontfix
  • Status changed from assigned to closed

Hey @sc0ttkclark - going thru old tickets and found this one. Thanks for submitting... so long ago ;)

Does this issue still apply with the block editor?

In terms of the confusion you describe, the fix you want is that previewing a draft would no longer edit the draft itself, right? Because this has been the default behavior for so long, I expect most users will feel this is a feature, not a bug and changing it might cause more confusion than leaving it as is. Because of this, we are unlikely to change it in core.

With the current block editor, there is likely a way you could filter the behavior of the autosave endpoint to align better with your expectations (if not, let's make that possible). If you want help with a mini plugin to enable this on your site(s), please let me know.

Closing this for now - if you want to work on this further, please feel free to re-open.

#4 @sc0ttkclark
4 years ago

I'm not sold on that being a feature and depended upon, but we can disagree there. I think it's problematic, but I haven't tested this on the new Block flows. It might be resolved there, unfortunately I don't have time to dig further into this.

Hope all is well, thanks for following up.

Note: See TracTickets for help on using tickets.