Suitable for template specific PWA/SW?

The plugin provides a PHP abstraction for the Workbox JS API, while also allowing you to write JS workbox code and register it via wp_front_service_worker. So let’s say you have some custom JS code that interfaces with workbox (which we alias to wp.serviceWorker), you can include that file in the service worker with code like this:

add_action(
	'wp_front_service_worker',
	static function( WP_Service_Worker_Scripts $scripts ) {
		$scripts->register(
			'foo',
			[
				'src'  => plugin_dir_url( __FILE__ ) . 'foo.js', // Source.
			]
		);
	}
);

So yes, this plugin is intended to be a foundation for any custom SW logic, while also providing sensible defaults for 80% of sites (e.g. offline caching).

For how to write the JS code specifically to interface with Workbox, I would refer to the Workbox docs: https://developers.google.com/web/tools/workbox/

Thanks @westonruter, I dived in this morning as I’d already enqueued the JS, but it wasn’t clear how much of the SW lifecycle we needed to implement; from the looks of it we don’t need to do as much, more a case of working out how to make PWA/Workbox work for us with our specific needs. ??

One question I did have was, is it possible for Workbox to still trigger a cache request for a resource that is 302’d from the original URL?

I’ve registered a custom endpoint to get around the fact that the route registration is regex based — we’re essentially mapping /resources/<post-id> to a number of curated files/posts that live across a number of different permalink structures — however I’m guessing that 302 redirecting to the resource breaks the ability for the SW/Workbox to cache it? Is there a suggested way around this, or do we need to look at returning the actual asset in response to a request for these URLs? e.g. /resource/42 returns 42.pdf rather than redirecting to the media library URL for the PDF.

Appreciate your efforts on the plugin, fingers crosssed for core merge!

It sounds like what you need to do is add a route for /resources/<post-id> which does the fetch from origin and then handles any redirect and then puts the result in the cache.

Maybe you could us the CacheableResponsePlugin to opt-in to 302 status to cache: https://developers.google.com/web/tools/workbox/modules/workbox-cacheable-response#caching_based_on_status_codes

But then the redirect would be cached, not the resource that it is redirecting to unless you have a caching strategy for the redirected URLs as well.

I’m not clear on the need for a custom endpoint, however. What’s the problem with it being regex-based?

The regex based route registration prevents us from caching assets that live in different URL structures, but also the fact that we don’t want to cast the net so wide that everything is cached.

For example, it will be a curated selection of *some* but not all PDFs/Office docs as well standard WP posts/standard HTML pages.

If we could pass in an array of cacheable paths that would solve the issue, but as we have to supply a regex, the endpoint was my idea of having a single canonical URL structure for the assets instead of having to produce a complex regex pattern…but obviously the redirects are now the issue.

How many paths are you talking about here? While the regex may be complex, you wouldn’t have to construct it by hand. You could just gather the array or paths, and pass each one through preg_quote() and then join the list with |. And that would be the regex.

That’s a good shout actually; there’s potentially quite a few but I’m actually tempted to intercept the fetch request and check the requested file against a whitelist of URLs as opposed to using the route regex for now.

One of the things that did cause a little confusion was that it wasn’t immediately clear that registration of a new route didn’t cover Navigation requests; it might be worth explicitly stating this in the readme?

Regardless, to work around this I’ve simply opted into Navigation caching, and I’m intercepting the fetch event to only cache the navigation request if it matches our whitelist of URLs, giving us the compartmentilisation wr need. ??

Regardless, to work around this I’ve simply opted into Navigation caching, and I’m intercepting the fetch event to only cache the navigation request if it matches our whitelist of URLs, giving us the compartmentilisation wr need. ??

How did you opt-in to navigation caching?

One of the things that did cause a little confusion was that it wasn’t immediately clear that registration of a new route didn’t cover Navigation requests; it might be worth explicitly stating this in the readme?

Perhaps that could be an argument when calling WP_Service_Worker_Caching_Routes::register()

Sorry for the delayed reply!

> How did you opt-in to navigation caching?

For this I’ve just used wp_service_worker_navigation_caching_strategy

> Perhaps that could be an argument when calling WP_Service_Worker_Caching_Routes::register()

That would be fantastic