Opened 7 years ago
Last modified 6 years ago
#43328 accepted feature request
Add support for Web App Manifests
Reported by: | westonruter | Owned by: | westonruter |
---|---|---|---|
Milestone: | Future Release | Priority: | normal |
Severity: | normal | Version: | |
Component: | General | Keywords: | |
Focuses: | javascript | Cc: |
Description
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 theblogdescription
name
can be pulled fromblogname
.background_color
can be pulled from thecustom-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.
Change History (10)
#2
@
7 years ago
Worth noting that Jetpack has a Web Manifest implementation that you could steal for Core :)
https://github.com/Automattic/jetpack/tree/master/modules/pwa
#3
@
7 years ago
- Owner set to westonruter
- Status changed from new to accepted
Excellent. Let's do that.
#4
@
7 years ago
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.
#5
@
7 years ago
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
.
#6
@
6 years ago
I've created a feature plugin repo for collaborating on this: https://github.com/xwp/pwa-wp
#7
@
6 years ago
Initial PR which ports Jetpack's implementation with some iterations: https://github.com/xwp/pwa-wp/pull/13
#8
@
6 years ago
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.
#9
@
6 years ago
PWA feature plugin is now live on WordPress.org: https://wordpress.org/plugins/pwa/
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.