The current manifest validation in Chrome requires at least one
non-maskable icon to make it installable.
This commit adds the maskable entry as another entry, following up
on changes added in 3e590b8
Because:
- Chrome 78 and Firefox Fenix have support for it
- The icons will look better by using all the availiable space
- Admins can control the icon and add appropriate padding since we have a
dedicated asset for the manifest logo. Read more about it on
https://css-tricks.com/maskable-icons-android-adaptive-icons-for-your-pwa/
This commit:
- Adds a new key under the icons array in the webmanifest, named purpose
with maskable value.
- Adds support for iOS Universal Links via an `apple-app-site-association` endpoint
Adds support for Google Digital Asset Links at the `.well-known/assetlinks.json` endpoint
This change automatically resizes icons for various purposes. Admins can now upload `logo` and `logo_small`, and everything else will be auto-generated. Specific icons can still be uploaded separately if required.
## Core
- Adds an SiteIconManager module which manages automatic resizing and fallback
- Icons are looked up in the OptimizedImage table at runtime, and then cached in Redis. If the resized version is missing for some reason, then most icons will fall back to the original files. Some icons (e.g. PWA Manifest) will return `nil` (because an incorrectly sized icon is worse than a missing icon).
- `SiteSetting.site_large_icon_url` will return the optimized version, including any fallback. `SiteSetting.large_icon` continues to return the upload object. This means that (almost) no changes are required in core/plugins to support this new system.
- Icons are resized whenever a relevant site setting is changed, and during post-deploy migrations
## Wizard
- Allows `requiresRefresh` wizard steps to reload data via AJAX instead of a full page reload
- Add placeholders to the **icons** step of the wizard, which automatically update from the "Square Logo"
- Various copy updates to support the changes
- Remove the "upload-time" resizing for `large_icon`. This is no longer required.
## Site Settings UX
- Move logo/icon settings under a new "Branding" tab
- Various copy changes to support the changes
- Adds placeholder support to the `image-uploader` component
- Automatically reloads site settings after saving. This allows setting placeholders to change based on changes to other settings
- Upload site settings will be assigned a placeholder if SiteIconManager `responds_to?` an icon of the same name
## Dashboard Warnings
- Remove PWA icon and PWA title warnings. Both are now handled automatically.
## Bonus
- Updated the sketch logos to use @awesomerobot's new high-res designs
This commit adds some improvements to native app banners for iOS and Android
- iOS and Android now have separate settings for native app banners
- app banners will now only show for users on TL1 and up
- app ids are now in a hidden site setting to allow sites to switch to their own app, if desired
- iOS only: the site URL is passed to the app arguments
This will allow users installing a Discourse PWA to use their active
theme colors on the generated app. Thanks for @mgiuca for the tip.
Also makes the share_target config explicit to silence Chrome warnings
This adds a **very basic** support for share to Discourse.
Currently, this is only supported in Android + Chrome 71+.
After installing a Discourse site to the Home Screen, you will be
able to share from anywhere in the OS to the Discourse site.
Discourse will use the title and text from the share event.
- Remove share target because the spec is changing
- Allow any orientation again because natural is too restrictive
- Use correct file and mime types for the manifest
This makes Discourse compliant with latest Google PWA requirements,
so we get the App Install banner back.
Should bump our Lighthouse PWA Audit score to 11/11.
The `any` orientation forces the rotation even when the device's screen
rotation is disabled. Using `natural` respects that and restores the
expected behaviour.
The opensearch.xml results in a "site search engine" being added to
Chrome, while the sitelinks search tag results in "Search this website"
being added to Google Search.
