Experiment: Admin PWA #33102
Experiment: Admin PWA #33102
Conversation
ellatrix
requested review from
ajitbohra,
chrisvanpatten,
spacedmonkey and
TimothyBJacobs
as code owners
|
Size Change: +1.37 kB (0%) Total Size: 1.05 MB
ℹ️ View Unchanged
|
|
Here's one thing I'd like to improve: the icon.
|
|
Nice exploration. Have you checked if there is an overlap with the PWA plugin (40,000+ active installations) that already exists in Plugin Directory? https://wordpress.org/plugins/pwa/ /cc @westonruter Is there any particular reason that you think it would be better to add this functionality to the Gutenberg plugin first? |
|
@gziolo Sorry, I missed your comment.
|
| { | ||
| "name": "@wordpress/admin-manifest", | ||
| "version": "1.0.0", | ||
| "description": "Dynamically creates a Web App manifest and registers the service worker for the admin.", |
There was a problem hiding this comment.
Can you mark it as private so it doesn't get published to npm until it's ready for prime time?
It will also remove the entry from docs/manifest.json – the block editor handbook.
There was a problem hiding this comment.
Oh, sure, I wasn't aware of that.
It actually registers a service worker for both the frontend and the backend, but it doesn't currently register a separate web app manifest for the backend. See GoogleChromeLabs/pwa-wp#295. The key goal of the PWA plugin is to allow for extensibility. Since only one service worker can control a given scope (e.g. /wp-admin), it's important that the service worker script be served by WordPress in a way that plugins can inject their own logic. The PWA plugin then takes this an additional step by bundling Workbox.js and providing a PHP abstraction for plugins to add service worker logic. |
Right, Gutenberg is good for experiments with JavaScript-based functionalities. It didn't occur to me that PWA is related to the writing experience, but it definitely can be once the offline support is implemented 👍🏻
Shouldn't it be behind the feature flag like other experiments in the past (Widgets screen, Navigation screen, etc)? |
A PWA by itself needs to be activated explicitly by the user, so there's no need for an experimental flag. You're opting out by default, and you're opting in if you add the site to your Home Screen. :) Similarly in Chrome on macOS, there will be an install button. By default nothing happens, we just let the browser know that it's possible to install as a PWA.
|
Actually, the service worker is installed regardless. The install prompt will only be offered of the service worker is detected. It's only the app UI that is a user opt-in. Therefore perhaps a feature flag is warranted or else this may conflict with another service worker that the user may have installed in the admin (e.g. via the PWA plugin). |
|
I think the only thing missing from the PWA plugin is the registering of the admin web app manifest, which we already have that issue for (GoogleChromeLabs/pwa-wp#295). It wasn't implemented yet because there wasn't strong demand for it yet. We can then build on that to use the service worker for offline access to the block editor. |
| function addManifest( manifest ) { | ||
| const link = document.createElement( 'link' ); | ||
| link.rel = 'manifest'; | ||
| link.href = 'data:application/manifest+json,' + JSON.stringify( manifest ); |
There was a problem hiding this comment.
This is clever. The PWA plugin uses the REST API to serve the manifest, but using a data: URI simplifies things. Was there a specific reason for doing it inline?
| function addManifest( manifest ) { | ||
| const link = document.createElement( 'link' ); | ||
| link.rel = 'manifest'; | ||
| link.href = 'data:application/manifest+json,' + JSON.stringify( manifest ); |
There was a problem hiding this comment.
This is clever. The PWA plugin uses the REST API to serve the manifest, but using a data: URI simplifies things. Was there a specific reason for doing it inline?
There was a problem hiding this comment.
Right, this simplifies things and allows us to dynamically generate the icon (for which I'm changing the background color based on the admin color scheme). See #33102 (comment).
There was a problem hiding this comment.
I guess it's still preferable to use the REST API for the frontend web app manifest, because there's a performance hit for running script with each page load.
| 'admin_head', | ||
| function() { | ||
| $l10n = array( | ||
| 'logo' => file_get_contents( ABSPATH . 'wp-admin/images/wordpress-logo-white.svg' ), |
There was a problem hiding this comment.
Should this incorporate the site icon? Otherwise a user may have multiple admin PWAs and they'd all have the same icon.
There was a problem hiding this comment.
I've thought a bit about this, and I think we shouldn't use the site icon. See #33102 (comment).
I was using the site icon at first, but it only works with pngs in Chrome, and the front-end of the site could potentially be a PWA that uses the site icon. The site icon is meant to be used for the site, not the administration area. I've made it so that the admin icon is dynamically generated based on the admin color scheme, so you could have many different WordPress sites that you're managing with differently coloured icons. I think this is the nicest solution for the admin, for which we'd need a default icon anyway if so site icon is set.
There was a problem hiding this comment.
How often do users change the admin color scheme? I personally never change it. It's the same for all sites I manage.
There was a problem hiding this comment.
The site icon is meant to be used for the site, not the administration area.
Also, I'm not sure about that. Is not the site icon also showing up as the favicon when in the admin?
| ); | ||
|
|
||
| add_filter( | ||
| 'load-index.php', |
There was a problem hiding this comment.
The PWA plugin makes use of admin-ajax.php for serving the service worker which also works.
There was a problem hiding this comment.
Right, we could do that too :)
|
I'm going to work on taking the changes in this PR to apply to the PWA plugin so that that the service worker won't conflict and so that other plugins can extend the service worker with their own logic, as right now this is not possible with the new Gutenberg service worker. See GoogleChromeLabs/pwa-wp#569. |
|
There is a plan to remove this functionality with #38810. |
Description
This PR enables the WordPress admin to be added to the Home Screen as a standalone app (removing the browser chrome).
To me, the benefits are huge: much easier access to WP and a larger space to work with.
The scope of the app is explicitly set to the admin only so that the login page, front-end, and any external URL load in a pop up browser modal (which can be exited by clicking "Done").
The app must be created from the admin.
Screen.Recording.2021-07-01.at.17.31.46.mov
Desktop PWA with Chrome:
How has this been tested?
Screenshots
Types of changes
Checklist:
*.native.jsfiles for terms that need renaming or removal).