Research a method for caching and using data offline

[postphotos]

As a user, I should have a way to experience a website in poor internet conditions. There should be a way for me to easily save the content that the site has already loaded in cache and not lose it when I click on the next link. In this offline state, I should have meaningful content available to me.

AC1: Continue to extract the learnings from #1 and document approaches in this ticket.
AC2: Provide a prototype or a design approach in this ticket outlining how this should work.

AC3: As a developer I want to know how this works and what I'd need to do to turn this on. I'd also want to know what not to do so that I don't hurt my user's experience or excessively store content, nor accidentally permanently cache dynamic data.

[kienstra]

Hi @postphotos
Thanks for the great ACs. Offline commenting and Gutenberg editing might be good to implement with this, or in related issues.

[westonruter]

Offline commenting I think is out of scope here. That really gets into the realm of background sync.

[kienstra]

Question About offline.php

Hi @postphotos,
Does this issue mainly involve something like an offline.php page, for when there's no connection? Otherwise, this might be covered by #14 (Service Worker API) or #5 (Propose Workbox Solution).

[westonruter]

@kienstra I think this is separate from the offline.php: it's building on top of having an offline template. The bare minimum for offline support is not covered in this issue, and that is to have a page that is served when the site is offline. Eventually this offline page could surface links to content that the user has saved offline, but that would require the capability to save offline pages first. So the first step is to create a new issue that is specifically about serving the offline page. And as @mehigh suggested, we should not limit it to an offline.php but consider giving the user the ability to designate which page is served as the offline page. This would allow them to select any page in their site along with any page template they desire.

[kienstra]

Thanks, @westonruter! That was a good idea to be able select a page to display when offline.

[kienstra]

Request For New Issue

Hi @postphotos,
When you have a chance, could you please open a new issue to capture @westonruter's comment above?

...a new issue that is specifically about serving the offline page. And as @mehigh suggested, we should not limit it to an offline.php but consider giving the user the ability to designate which page is served as the offline page. This would allow them to select any page in their site along with any page template they desire.

[nico-martin]

In my opinion, that opens a very important question. How far should the core-module go?
To be honest, I don't think it makes sense deliver an offline experience out of the box. I think the core-module should provide the right tools (Service Worker API) so a plugin could add offline support.

Any other opinions?

[mehigh]

This provides the most basic implementation which allows non-tech people to enable a PWA basic-checklist feature. At the most basic level selecting a page to use for offline gets you going.
Plugins can take it a step further and define a custom template for the offline page with more bells and whistles, etc.
I feel core needs to provide a starting point, even a basic one is a huge step forward.

[nico-martin]

Yes I get that. But if you want to cache an offline page, you also need to cache all files required to show the page. And then that opens more questions. Offline first? Network first? Should this depend on the file type? How should a developer be able to change this behaviour? And why shouldn't we also cache the front page?

But the most basic question is: should the core provide PWA features out of the box or should the core only provide the tools?
I'd go for the second because thats way more flexible for future technologies and best practices.

[amedina]

An offline page can be as simple as a nice 404 page; thinking along the lines to what GitHub 404 pages look like. The goal is to give the user an experience that is less broken than a Chrome Downasaur, for example.

[amedina]

@westonruter like the idea of enabling the user to select the page that would be rendered under challenged connectivity situations; although there are some scenarios to be considered. I would start with a simple offline.php.

[mehigh]

@nico-martin on Offline first? Network first? The sensible default which would work for most users is network first. When going offline-first you need to know what you're doing and when to do that in order to avoid sending stale data by default.

In my opinion, the features to be added will have to have filters to allow devs to disable the default and do their own thing instead. Like tools + basic defaults. The less wheels you have to turn to get a site to a functional state the more people will be adopting it, or get more interested in doing more.

[westonruter]

like the idea of enabling the user to select the page that would be rendered under challenged connectivity situations; although there are some scenarios to be considered. I would start with a simple offline.php.

@amedina See #23 for more on this. I think actually the offline.php shouldn't be where we start because then it wouldn't allow existing themes to create an offline page. Otherwise, if we just provide a UI for selecting the offline page then any theme could be used to create an offline page. A theme could also provide an offline.php template which is actually a custom page template that the user could select as the template for this designated page, but this template file could actually be named anything. It would just need to have the Template Name comment in the file.

[westonruter]

And yes, the offline page should be served only if the network fails to respond to a request (i.e. network first strategy). Any use of the offline-first strategy for other pages should require explicit opt-in, and to some degree this may be plugin domain as @nico-martin notes.

[nico-martin]

I think the offline.php template would be the better solution than aksing the user to pick an offline-page.

Progressive WordPress does that. It offers the user a drop down where he can select an offline page. But to be honest I underestimated the lazyness of most Admins. I came accross a lot of examples where they just picked the front page as the offline page. Because a) they didn't want to write an extra offline page or b) they didn't know what to do an that seemed to be the easiest choice.

In my eyes the offline page is not a "page". It's more like a 404 or 500 error. An information coming from the system that something is not the way it should be. So in my opinion, just like the 404.php-Template, an offline.php-Template would make sence.

And as @westonruter pointed out in #23 , an offline page should never be used like a normal page. You should never be able to set a link to an offline page. It should hurt when you try to paste the link somewhere (But you still need a unique link for the ServiceWorker). Thats why I would suggest a link outside the url rewrites. Maybe something like https://mysite.com/?wp_offline=true_or_whatever which loads the offline.php?

And an other cool thing: a theme could then "add offline functionality" by simply adding an offline.php the way it handels 404 errors.
And yes, there could be an issue with existing themes. But to be honest, if a Theme is not longer maintained (doesn't matter if public or custom), I think it's ok if its harder to get support for new features

Any other thoughts?

[westonruter]

We could also just automatically create an offline page post upon activation. We could avoid the page from being served on the site normally by using a custom post status. This would automatically not expose the page among the available navigation menu items. We could then serve it only if requesting with the query var as you suggested. If no offline page exists, then the response could be treated as is_404() to serve the not found message, which I think would be better then no offline page at all. (Alternatively, I wonder also if the template hierarchy should be extended so that is_offline() would be a special case under is_404().)

There are thousands of themes out there and it would take a long time for them to add an offline.php template. I don't think that should be a requirement before serving the offline page.

Requiring a special offline template would also not align with the template hierarchy expectation either. A minimal theme is only required to include an index.php template which gets used then to serve responses to all queries, including is_404(). A theme should also be able to use this generic index template to serve an offline response as well (is_offline()?). That would seen the most logical from a theme developer's perspective.

[westonruter]

All of the discussion regarding a dedicated page to serve when offline should be continued on #23.

This ticket is more of a general offline consideration which I think is going to largely be out of scope for the PWA plugin, and would rather primarily the domain of plugins that build upon the PWA infrastructure that this plugin is going to propose for core inclusion.

[westonruter]

I think the offline.php template would be the better solution than aksing the user to pick an offline-page.

We're circling back to this in #52