WordPress.org

Make WordPress Core

Opened 3 months ago

Closed 2 months ago

Last modified 10 days ago

#37025 closed enhancement (fixed)

Improve the "disaster recovery" mode

Reported by: azaozz Owned by: azaozz
Milestone: 4.6 Priority: normal
Severity: normal Version:
Component: Autosave Keywords: has-patch needs-testing
Focuses: ui Cc:

Description

We've had a "disaster recovery" that saves post title, content and excerpt in the browser's sessionStorage for a while. It runs every 15 seconds on the Edit Post screen and just before the user submits the form. However it shows very rarely, only when it detects that saving failed, and if the "There is a newer autosave..." message is not present (so we don't show two recovery options at the same time and confuse the users).

This behavior needs to be changed as the content in the browser is more recent. If there is a "newer autosave" message and the disaster recovery script activates, it should hide the message. There are some other improvements like not running editor.save() if the content in the editor has not changed, etc.

A great improvement will be to be able to show some sort of a preview with the changes that will be restored. However that deserves its own ticket and is probably out of scope this time.

Attachments (3)

37025.patch (5.6 KB) - added by azaozz 3 months ago.
37025.1.patch (6.4 KB) - added by azaozz 3 months ago.
restore-notice.png (41.7 KB) - added by azaozz 2 months ago.

Download all attachments as: .zip

Change History (16)

@azaozz
3 months ago

#1 @azaozz
3 months ago

  • Keywords has-patch needs-testing added

In 37025.patch:

  • Hide the "More recent autosave available" notice if present.
  • Simplify the "Backup available" notice (no inline undo), and add short explanation of what is changing and how to revert it. (The text may need some editing.)
  • When restoring to the Visual editor make sure it creates an undo level.
  • When restoring to the Text editor use document.execCommand() so the change can be undone with Command/Ctrl + Z. (Using textarea.value = 'string' prevents the user from undoing it).

Other suggestions about how to make this a bit more user friendly welcome :)

Last edited 3 months ago by azaozz (previous) (diff)

#2 @chriscct7
3 months ago

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

#3 @azaozz
3 months ago

How to test this (on a test install):

  • Start a new post.
  • Type something.
  • Save a draft.
  • Type something more.
  • Wait for about 10 seconds for the in-browser autosave to kick in. It runs every 15 seconds.
  • Reload the page.

Couple of seconds after the page loads the "The backup of this post in your browser is different from the version below." notice should show. (The couple of seconds delay is needed to make sure the post content is fully loaded in TinyMCE so we can compare it to the content in sessionStorage. This reduces false positives a lot).

@azaozz
3 months ago

#4 @azaozz
3 months ago

In 37025.1.patch:

  • A bit longer help/explanation of how to use this.
  • Added some subtle animation when removing an existing autosave message and opening this message.

#5 @azaozz
2 months ago

  • Focuses ui added

This ticket was mentioned in Slack in #core-editor by azaozz. View the logs.


2 months ago

#7 @azaozz
2 months ago

In 37737:

Autosave: improve the notice when the sessionStorage autosave is different than the content.

  • Make it higher priority than the server autosave.
  • Change it so the editors undo and redo can be used.
  • Replace the restore link with a button.
  • Add better explanation/help.

See #37025.

#8 @iseulde
2 months ago

I've ran into this a couple of times now while testing other things: I refresh the page, try to put my cursor in the editor and it starts sliding down. That's pretty annoying.

This ticket was mentioned in Slack in #core-editor by azaozz. View the logs.


2 months ago

This ticket was mentioned in Slack in #core by ocean90. View the logs.


2 months ago

#11 follow-up: @ocean90
2 months ago

@azaozz What's missing here? Can we close it if it's only testing?

#12 in reply to: ↑ 11 @azaozz
2 months ago

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

Replying to ocean90:

Seems to be working well. New tickets for any bugs please.

This ticket was mentioned in Slack in #core by sergey. View the logs.


10 days ago

Note: See TracTickets for help on using tickets.