Improve behaviour when saving content while offline

[johnbillion]

Issue Overview

As Gutenberg is a JavaScript driven application that doesn't rely on traditional form submission like the current editor does, there's an opportunity to improve the end user experience when the client experiences connectivity problems or goes offline completely.

For example, if the saving action fails in any way, Gutenberg displays an error message that states Updating failed. It would be great if Gutenberg could inspect the navigator.online property at this point (or earlier), and if it returns false then display a more appropriate error message to the user, for example You do not have an internet connection. Saving and previewing is not available offline.

A further enhancement would be to fully save the post content in the browser in the same way that the current editor does, to avoid data loss in case the user decides to close their browser window. This happens in the current editor, but not in Gutenberg. I'm not sure if there's an existing ticket for that.

[johnbillion]

In addition, clicking the Preview button while offline results in a loading spinner that never stops spinning.

[johnbillion]

Core ticket here, but not very relevant to Gutenberg: https://core.trac.wordpress.org/ticket/41535

[westonruter]

It would indeed be a great improvement to show a warning when offline and to store the changes in localStorage to restore later.

In addition to this, I think we also now have the opportunity to go much father than having parity with the classic editor. With service workers we could provide an entirely offline authoring experience:

• The service worker can cache the assets required by the editor (i.e. the old Turbo mode: Use Service Workers (as grandchild of Gears) to bring back Turbo mode in admin GoogleChromeLabs/pwa-wp#34) as well as the HTML required to render the edit post screen (minus legacy metaboxes).
• The service worker can cache the REST API responses for any number of posts and media to allow them to be accessible for editing when offline. To access the list of offline-editable posts, there would probably need to be an REST API-driven post list table to which could leverage what @rmccue prototyped in new-list-tables.
• If a user goes offline while editing and they attempt to save, the saved post can be scheduled for a background sync to automatically send back to the server when the user re-connects, even if they don't go back to the post edit screen they were on. The Workbox has a background sync API that looks well suited for this.

With this in place, if the user hits “Save Draft” when offline then a notice could appear as:

You do not have an internet connection. Your changes will be synced once back online. Previewing and some editing is not available when offline.

Enabling offline editing in Gutenberg is one of the key use cases we've identified for service workers in core for the PWA feature plugin. It would be great to identify what Gutenberg would need from service workers to enable offline usage so that the feature plugin can be built to facilitate it.

[schmitzoide]

Weston how you’d know which items to cache (posts, media) in preparation for the potential offline situation?

[westonruter]

@schmitzoide I'm guessing the heuristics would probably include caching the X most recently-modified posts, in addition to caching all of a user's drafts (and their media). It could then use runtime caching to store any other posts that the user accesses.

The biggest challenge here I think is what to do in the conflict scenario, when you make changes to one version of a post offline but that post has had other changes done to it once you go back online. I suppose we'd need a merge conflict resolution UI.

Another challenge for offline in WordPress is that some things would not be possible offline, including the uploading of new media and creation of new reusable blocks, since these would rely on obtaining new AUTO_INCREMENTED IDs.

[westonruter]

We could bypass the issues with conflicts by only doing background sync to push up changes to the user's autosave revision. That would then allow the user to restore the autosave which could then overwrite another user's changes. That's not great either as it just somewhat passes the buck, deferring the problem down the road. Instead of doing this the background sync could do a PUT request to the endpoint with an If-Unmodified-Since header so that their changes would be saved as normally if nobody else edited the post (which would probably be the normal case) but then if that PUT request's precondition fails (412 Precondition Failed), it could then fallback to re-sending the pending changes into the autosave revision.

[getsource]

To me, this seems like a pretty big regression from the current editor. Why is it marked with Enhancement and not in the merge milestone?

(unless the existing behavior, as noted/screenshotted in https://core.trac.wordpress.org/ticket/41535#comment:5 lives in a ticket I'm missing -- if so, my apologies)

[tofumatt]

I have started tackling a lot of accessibility stuff for the merge and have let this sit a bit, but I would like to get back to it and have at least the beginnings of offline support for the merge. I originally committed to that but then ended up wrangling a lot of accessibility issues. It's still on my radar though… I agree I would like to see it in the merge. I guess I'll add it in for now; you can blame me if it doesn't make it! 😅

[getsource]

Cool, thanks so much! Appreciate the attempt either way.

[designsimply]

#7367 proposes saving post data to the REST API offline so data isn't lost, and I think that covers the first point.

#4590 proposes better error messaging for the "Updating failed" error.

If you agree the issues you've raised are covered in the other two, I would like to close this issue in favor of those in order to consolidate to more specific issues because it helps keep them actionable (and this issue/discussion can still be a good reference point for the others). If I've missed anything in my read of the suggestions that isn't covered by the other two issues, then we should keep this issue open. These are important issues and I also would like to say thank you for raising them!

[getsource]

@designsimply I'm not sure if offline saving is entirely handled in #7367, but if so, it'd be great to have that back in the 5.0 milestone if this one is to be closed.

In my opinion, it's a pretty big regression to lose offline saving, and the safety that comes from that when your connection is lost.

[designsimply]

Issues like these are certainly a tough call! #7367 does appear to need a dev that is not already dedicated elsewhere and that may not happen before 5.0. I'll leave this issue open just a bit longer as I agree offline saving is important but still want to get a check on whether we can consolidate these issues, even though #7367 slated for 5.1.

[getsource]

I'll also note that at least one of the two (this one, or the two you mention) should probably be marked back-compat, rather than enhancement, as they are regressions in behavior.

[mtias]

There's a work in progress in #9383 if anyone wants to help continue it (of note, localForage has incompatible license). I'd love to have offline compatibility sometime soon, personally, but I don't think it should block. In any case, let's consolidate the conversation in #7367 which has a bit more traction.

[westonruter]

I've opened a core ticket with patch for adding support for the If-Unmodified-Since request header when updating posts: https://core.trac.wordpress.org/ticket/47676

[miina]

Note: looking into this in terms of starting creating a small proof of concept based on Service Workers (see @westonruter's comment for specifics).

[miina]

Here's a PR (currently in full PoC state) for implementing very basic offline editing with Service Workers:
miina#1

It basically:

• Allows editing a previously loaded post only.
• Displays a message about being offline upon clicking "Update" and lets the user know that the post will be updated later.
• For now, always updated the post content when online again, ignoring changes done by anyone else meanwhile.

Other notes:

• Requires https (since using Service Workers)
• Assumes that pretty permalinks are not enabled.

[youknowriad]

Closing this issue cause I believe offline save is implemented now cc @mcsf
Let me know if I'm missing anything.

[mcsf]

It's less ambitious than service workers, but local autosaves were added in #16490.