Add support for Web App Manifests

[westonruter]

Per ​MDN:

The web app manifest provides information about an application (such as name, author, icon, and description) in a JSON text file. The purpose of the manifest is to install web applications to the homescreen of a device, providing users with quicker access and a richer experience.

Web app manifests are part of a collection of web technologies called progressive web apps, which are web applications that can be installed to the homescreen of a device without needing the user to go through an app store, along with other capabilities such as being available offline and receiving push notifications.

For populating the manifest:

• description can be pulled from the blogdescription
• name can be pulled from blogname.
• background_color can be pulled from the custom-background theme support.
• lang can be pulled from the site locale.
• icons can be pulled from site icons.

A filter can be present for themes and plugins to augment the manifest.

See also #36995 for adding service worker support to core.

[westonruter]

Having an API for Web App Manifests is to facilitate multiple plugins all coordinating on the same manifest, but it is also generally useful for WordPress as well. The manifest gives the site control over the “Add To Homescreen” behavior in a browser, such as allowing it to open full-screen and have a landscape orientation. A web app installed with a manifest integrate with the OS's task switcher as a separate app, rather than being shown as just another tab in Chrome or Firefox.

[goldsounds]

Worth noting that Jetpack has a Web Manifest implementation that you could steal for Core :)

​https://github.com/Automattic/jetpack/tree/master/modules/pwa

[westonruter]

Excellent. Let's do that.

[westonruter]

In the Jetpack defaults ​there is:

'short_name' => substr( get_bloginfo( 'name' ), 0, 12 ),

Where was the length of 12 determined? Truncating it like that could produce undesirable results. At least an ellipsis should be added, but otherwise maybe it would be better to default to the domain name (if not a subdirectory multisite install).

I think the name and shortname is also missing a good default configs for lang and dir which we can provide automatically.

Also, for display perhaps the default of browser is better than standalone? Just thinking that if this is rolled out across all WordPress installs does it make sense for every WordPress site I add to my homescreen to be a different standalone app by default? I think that should maybe be opt-in via filter.

I think including scope in addition to start_url may be worthwhile.

[goldsounds]

IIRC, it was in response to a warning produced by Chrome's Lighthouse tool:

​https://developers.google.com/web/tools/lighthouse/audits/manifest-contains-short_name

short_name is used as the application name when installing to a phone screen / desktop, and the limitation is for readability. Adding an ellipsis might help with readability but then you have a max length of 9, which seems unreasonably short.

You're probably right about browser vs standalone.

[westonruter]

I've created a feature plugin repo for collaborating on this: ​https://github.com/xwp/pwa-wp

[westonruter]

Initial PR which ports Jetpack's implementation with some iterations: ​https://github.com/xwp/pwa-wp/pull/13

[westonruter]

That plugin PR was merged, so testing welcome.

Class with the functionality: ​https://github.com/xwp/pwa-wp/blob/master/php/class-wp-web-app-manifest.php

There is a web_app_manifest filter for plugins to extend the manifest. It uses the REST API to serve the manifest.

[westonruter]

PWA feature plugin is now live on WordPress.org: ​https://wordpress.org/plugins/pwa/

[earnjam]

#46392 was marked as a duplicate.