Enable autosave for published stories

[o-fernandez]

Feature Description

Currently, per #221 we disable autosave for published stories. The proposed change here is:

• When user makes changes after they open the published story, we autosave to a second file (doesn't overwrite published post) every 60 seconds (same interval).
• User can push changes live by triggering "publish/update" button
• User can trigger "Discard changes/revert to published version" option if they want to ignore any changes made after the last publish

The proposed UX changes are (need finalization before ticket moves to eng queue):

• Add a "discard changes" or "revert to published" button/option in the UI for published posts with changes
• May want some other way to show in WP (in the editor, stories dashboard, etc.) whether a published story has unpublished changes in draft.
• We may want to change the buttons nomenclature, we currently closely follow the WP article/page editor and replace "save draft" with "switch to draft" for publish stories, but in this scenario that wouldn't make as much sense since users would still be able to keep a working draft. In that case we think that having the 3 main buttons continue to be "save as draft", "preview" and "Update/publish changes" could be good, and we'd want to move the "unpublish/switch to draft" option and add "discard changes/revert to published" to some "other options" menu (maybe a drop down arrow next to update/publish).

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance Criteria

QA Instructions

[swissspidy]

A brief summary of how autosaves/revisions work in WordPress:

(I recommend trying it yourself to get a better feeling for it)

1. Create a new post (as post post type)
2. The WIP post is periodically saved to both session storage and the database (if online)
   • If the post is still a draft, this just means updating the currently edited post.
   • If the post is already published, this will create a new autosave (revision post type, referencing the post) Note: See #3842 for details on local autosaving
3. If someone else is taking over editing from you and locks you out of the editor (see #6055 for story locking), the same applies. Your changes will be saved so you don't lose anything.

Let's say you edit a post, save it, and then make some changes again.

If you later open the editor, you might get a message like this (depending on whether the changes were saved to session storage or the database:

Clicking on the review link will lead you to a WP UI to compare changes in a diff view:

Here's where the implementation in the story editor differs:

1. No offline detection / message -> Needs UX
2. We don't save to session storage. That means you can easily loose content. This would be relatively easy to implement, see #9859
3. We don't autosave if the post is already published This is easy to fix, just need to remove the status checks here: https://github.com/google/web-stories-wp/blob/c249b1ff3ec580a51f6e5bf64a089d93230acfc7/packages/story-editor/src/components/autoSaveHandler/index.js#L47-L70
4. We don't show any message if there is an autosave -> Needs UX
5. We don't autosave when someone takes over editing

cc @choumx @gajasinski @aaskedall @agingoldseco for thoughts & prioritization

[swissspidy]

Ona difference I forgot to mention above:

In Gutenberg, when you create a new post, that post will be periodically autosaved as an autosave, not a "proper" save. In our editor, we currently incorrectly always do "proper" saves, which quickly leads to the posts list being polluted:

To fix this, we simply need to remove the updateFunc check here and always use autoSave:

https://github.com/google/web-stories-wp/blob/eb22fc727405eadad3b5f25d15dff3d8aa9039f5/packages/story-editor/src/components/header/buttons/preview.js#L112-L127

[swissspidy]

@agingoldseco Would love your input here

All we basically need is UX for this kinda message:

[barklund]

My thoughts on the goal of this ticket (which should probably be split into multiple tickets).

New flow

Editor changes

Working on an unpublished draft of a published story

When you publish a story and keep working, or if you load an already published story and start working on it, the header changes to the following options:

• The preview button will preview the current draft of the story.

• The save button saves the current draft as an autosave (and only as that) so the changes are persisted to the database but not published (the published story remains unchanged).

• The update button works as today. If you press the update button the published story is updated to match the current draft (and the current draft is discarded / the revision is deleted).

• The options button at the end will open a small dropdown menu with three extra buttons:

  • Preview published story
  • Revert to published story / discard draft
  • Convert story to draft / unpublish story

All of these extra buttons have some underlying technical consequences, that we can always discuss, but I'm not sure how much we should reveal to the user about what those consequences are.

---

Loading a published story with an autosave

When you open a published story in the editor, that has an autosave newer than the published version the story, currently this dialog is displayed:

The "View the autosave" button is pretty useless though, as it takes you to a diff view of the underlying JSON changes, which is far too technical to be useful.

I propose we instead display something like this dialog:

Here you can open previews for the published story and autosave for comparison (it does require that you manually check the differences, but it is a lot more useful that the JSON diff view at least.

We could add additional information to this dialog such as "autosave last modified on July X by Author Y" and maybe even some metadata about said changes: "The autosave includes changes to story metadata, page 3, and page 8".

If you click the last button, "keep working", the autosave is loaded in the editor as in the above scenario where you keep working on an unpublished draft of a published story.

---

Dashboard changes

We need to highlight that a given published story has an unpublished autosave somehow. Suggestions are welcome, but a simple solution would be something as beautiful as this:

If the user wants to see or restore the autosave, they have to click on the story and go into the editor.

We could however add a new option to the options menu to directly discard the autosave without going through the editor?

---

New API

To support the above flow, we need to extend the API between WP and the editor a bit.

When a story is loaded in the editor, the config is extended with a new field, autosave, which defaults to null is no autosave exists for the current story. However, if an autosave exists, the value will be something like:

{
  ...,
  autosave: {
    revision_id: "<id>",
    last_modified: "<timestamp>",
    author: "<author name>",
    preview_link: "<URL>",
  }
}

We then also extend the API with a new endpoint to retrieve a revision as well as delete one: /web-stories/v1/revision/.

I don't think we need an API to "restore story from revision" (even though WP has that as a built-in function) as we would handle that manually in the editor by simply overwriting the story data with the data from the autosave. I guess the WP function to restore from revision also deletes the revision, but we could also do that manually when the user chooses to republish.

---

Ping @swissspidy, @timarney, @merapi, @miina for input.

[swissspidy]

Thanks for this summary 👍 There are definitely some good ideas here.

Admittedly, working on this is not straightforward because this ticket hasn't been updated in quite some time and mixes a bunch of things, plus the terminology and possible constellations are also confusing.

Because of that, I'd like to provide some additional context...

Ever since we built the initial version of the editor, the workflow with revisions/autosaves/publishing etc. did not match the rest of WordPress and thus caused quite some UX inconsistencies and sometimes even user frustration.

That's why we've added support for "submit for review" in the past, and are now working on things like sessionStorage autosaving, properly supporting the auto-draft status, and making it easier to access revisions— all in an effort to more closely align the behavior.

Speaking of revisions, there's actually some limitation there: WordPress does not natively support revisions to already published posts. That makes it very hard for us to build this. And that's also why people have even built clever solutions to support amendments to published posts and cloning/duplicating posts.

---

Working on an unpublished draft of a published story

I like the suggestion with the changes to the buttons there.

IIUC this would require support for revisions on published stories though (not just autosaves), since it would allow you to make multiple edits to an already published story, without affecting the published content though. Since WP does not support this natively, it would require quite a few backend changes to make this work.

Let's track this idea separately in its own ticket so we can dig more into technical feasibility.

Loading a published story with an autosave

Ditto w/ a separate ticket.

I like adding a preview option.

Perhaps with a dropdown button instead of this many individual buttons.

Dashboard changes

I like the idea and I think this is something we can already do now. It could check for autosaves both in sessionStorage and the db

Maybe displayed with a NotificationBubble or similar?

Something that we must already do today to make autosaves work for published stories is removing the isDraft check in AutoSaveHandler. That will allow #12098 to work.

We can repurpose this ticket for that.

We then also extend the API with a new endpoint to retrieve a revision as well as delete one

The revision endpoint exists at /web-stories/v1/web-story/<id>/revisions already.

---

Please let me know what you think.

Aside: no corgis in the pictures? 🙂

[barklund]

@swissspidy, it seems that this ticket is completely useless at this point, no? Do you want to keep it around, re-purpose it, or just close it?