Serve separate web app manifest for admin

[westonruter]

In order to facilitate adding the WP Admin for a site to the homescreen, we should possibly consider serving a separate web app manifest for the admin alone, to go along with the admin-specific service worker. I think this makes sense because the frontend and the admin are really two separate apps. The alternative would be to add an app shortcut to the main manifest for the admin, but this wouldn't make sense for the vast majority of visitors who never access the admin.

This would resolve #222 wherein errors are being reported in the admin due to their being no manifest.

[westonruter]

One thing needing to determine is whether the favicon for the site should be used or else a WordPress logo should be used as the icon in the manifest. In WordPress/gutenberg#33102, @ellatrix implemented the latter along with customizing the logo to reflect the admin color scheme.

However, I'm thinking the favicon actually should be used instead because the Site Icon (favicon) set in the Customizer is used both on the frontend and admin alike. The wp_site_icon() function runs at wp_head, login_head, and then also admin_head. A user will be used to seeing their site icon in tabs and bookmarks, since WP uses the site icon as the favicon. If the user manages multiple sites, then having the same WP icon multiple times could be a source of confusion.

[westonruter]

If the icon is the same, then what will be needed is a way to differentiate the frontend app from the admin app. Currently the site title is used for the name in the Gutenberg admin PWA, but the site title is also used for the frontend PWA provided by this plugin. Perhaps the admin app should have its name prefixed with “Admin:” or “Dashboard:”?

[westonruter]

While Gutenberg is inlining the web app manifest as a data: URI (which is clever), this adds script to the page and thus increases page weight and JS execution time. It may be preferable to continue to use an external request.

Nevertheless, one complication is extensibility. Currently there is one web app manifest and it is accessible via the REST API at /wp/v2/web-app-manifest and is customizable via the web_app_manifest filter. If we add a web app manifest for the admin, what would its REST API route be? For filtering, should we introduce a front_web_app_manifest filter and a admin_web_app_manifest in the same was as we have wp_front_service_worker and wp_admin_service_worker actions?

[westonruter]

If we add a web app manifest for the admin, what would its REST API route be?

Maybe we could use a context parameter for this?

• /wp/v2/web-app-manifest?context=front
• /wp/v2/web-app-manifest?context=admin

But that is probably an abuse of that parameter.

[westonruter]

We can use a scope query parameter instead. If not provided, it would default to front. If provided it could also be admin.

[westonruter]

Not a high priority for 0.7 since the web app manifest is being removed from Gutenberg in WordPress/gutenberg#38810 which was causing a conflict. This could wait until we are actually leveraging service worker capabilities in the admin. Until then, there's not really any need to have the admin be a separate PWA to install.

[westonruter]

While Gutenberg is inlining the web app manifest as a data: URI (which is clever), this adds script to the page and thus increases page weight and JS execution time. It may be preferable to continue to use an external request.

I was doing some more research on this and I found Multiple Language Installable Web Apps using a single Manifest File which also explores the technique of using a data: URL for the web app manifest. It mentions the following downsides:

Aside from the edge cases listed above there are some downsides. This is a hacky solution to the lack of internationalisation support in Web App manifests. Many tools that work with Progressive Web Apps are not expecting a data URL but a link to a real file. For example the incredibly useful tool PWABuilder wasn’t able to parse manifests stored this way but amazingly they had a fix ready in a few hours!

In addition there maybe some future problems which could arise.

The manifest URL changes if you change the data.

This may seem like an obvious consequence of storing all the data in the URL but it has a surprising side effect.

Some browsers are planning to scan for changes in the manifest and update the install Web App for things like Web Share shortcuts. They would do this by reloading the manifest from the URL. Because it’s a data URL this manifest will never be able to be changed or deleted it will always be valid and static. So the installed Web App will never be able to change unless the user reinstalls the app.

The other main downside is bloat, every page load includes the full Web App manifest every time, in the head of the document, even if the app is installed. Although the size is not huge because it’s in the <head> of the HTML file it will need to be loaded before the page can start rendering the page content in the <body>.

For i18n, a better approach is probably going to be to add a lang query parameter to the REST API URL.

[westonruter]

Proof of concept for an Admin PWA extension plugin: https://gist.github.com/westonruter/0d09371a2b2c991f344fa67b728975c5