Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Published posts should autosave #4112

Closed
2 tasks
adamsilverstein opened this issue Dec 20, 2017 · 13 comments
Closed
2 tasks

Published posts should autosave #4112

adamsilverstein opened this issue Dec 20, 2017 · 13 comments
Labels
Backwards Compatibility Issues or PRs that impact backwards compatability [Type] Enhancement A suggestion for improvement.
Milestone

Comments

@adamsilverstein
Copy link
Member

Issue Overview

When editing a published post, Gutenberg should perform a periodic autosave, matching the behavior of core's wp.autosave: https://github.com/WordPress/wordpress-develop/blob/1b5554e8188f24a0b522d82a2eccb7d098b878bb/src/wp-includes/js/autosave.js#L33

Expected Behavior

When editing a published post, the editor should autosave my changes into an autosave revision, matching the behavior of the classic editor. One autosave per user should be created.

The status indicator should also be visible:

https://codex.wordpress.org/Revisions#Autosaves

Current Behavior

Published posts do not autosave.

Possible Solution

Hook in early to the save process, and call wp_create_post_autosave when autosaving.

Having autosaves may also be helpful addressing previewing changes on published posts not working.

Related Issues and/or PRs

#1773
#3656
#4099

Todos

  • Tests
  • Documentation
@adamsilverstein
Copy link
Member Author

I started work on this here: https://github.com/WordPress/gutenberg/compare/feature/autosaves-for-published-posts?expand=1. This works to enable autosaves; needs more work to reflect the correct state after the update, currently Gutenberg is switching back to draft.

@jwold
Copy link

jwold commented Dec 20, 2017

@adamsilverstein one consideration from a user perspective could be to have the status go from:

Save Draft
Saving...
Saved √

That could help with providing confirmation that it's taking care of things in the background.

@adamsilverstein
Copy link
Member Author

@jwold thanks for the feedback!

it actually does that currently- its hard to see because it happens pretty quickly in my screen capture. I'm a little unsure about the language here for published posts. it is not really 'save draft' - for published posts autosaves maybe it should show 'save...saving...saved'?

@jwold
Copy link

jwold commented Dec 21, 2017

it actually does that currently

Ahh I missed that!

for published posts autosaves maybe it should show 'save...saving...saved'?

If "save" is an action I can click, then yes I think those steps could make sense.

@adamsilverstein
Copy link
Member Author

adamsilverstein commented Dec 21, 2017

Autosaves are working correctly for drafts and published posts in my branch, but some issues are outstanding:

  • We need an autosave message when the page loads and an autosave is available, this would include a link into the revisions screen where the autosave can be restored, similar to the classic editor
  • Autosaves should work with localstorage and when the network is not available
  • This is a bit of a kludge, a dedicated autosave endpoint might make more sense
  • Change the response code so save appears as success

@adamsilverstein adamsilverstein mentioned this issue Dec 24, 2017
3 tasks
@adamsilverstein
Copy link
Member Author

See #4156

@danielbachhuber danielbachhuber added [Type] Enhancement A suggestion for improvement. Backwards Compatibility Issues or PRs that impact backwards compatability labels Jan 23, 2018
@danielbachhuber
Copy link
Member

Related #4644

@danielbachhuber danielbachhuber added this to the Merge Proposal: Editor milestone Apr 25, 2018
@danielbachhuber danielbachhuber modified the milestones: Merge Proposal: Editor, 3.0 May 25, 2018
@danielbachhuber
Copy link
Member

Prior to shipping 3.0, we need to do another pass at addressing feedback in #6257

@tofumatt
Copy link
Member

My experience of this, testing it out locally is that once published, posts don't autosave until the page is navigated away from, and while there is an autosave then, it isn't loaded when the user returns to the editor.

And actually, while I did get it to autosave again for the screencap, it just didn't do anything:

2018-06-01 00 20 11

@adamsilverstein
Copy link
Member Author

adamsilverstein commented May 31, 2018

@tofumatt did you test out making some additional changes to the post? it won't autosave if there are no changes.

@aduth
Copy link
Member

aduth commented May 31, 2018

And actually, while I did get it to autosave again for the screencap, it just didn't do anything:

Guessing this is mainly the lack of the UI to prompt the user to restore the autosave. See #4218. You can see the autosave did happen if you load the post in the classic editor.

In the process of testing this myself, I also surfaced a related issue #7066.

@youknowriad
Copy link
Contributor

I'm closing this one. We can polish the auto-saving experience on smaller issues.

👏 🎉

@aduth
Copy link
Member

aduth commented Jun 4, 2018

A couple such issues:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Backwards Compatibility Issues or PRs that impact backwards compatability [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

No branches or pull requests

6 participants