Contrib.social

Extend site information page to generate a manifest.json file

Open on Drupal.org →
Created on 31 March 2016, over 8 years ago
Updated 13 November 2023, about 1 year ago

Problem/Motivation

New browser features enable better website integration to users' systems. While working on the progressive web app → module I came across a W3C draft for a manifest file. This file is used on mobile devices to allow website authors some control over the way the shortcut and initialization screen looks like.

Proposed resolution

  • Add new form fields and reorganize the site information form.
  • Add a <link rel="manifest" href="…/manifest.json"> tag in the head and a way to generate that file.
  • Generation of a manifest.json file containing at least:
    {
  "lang": "en",
  "dir": "ltr",
  "name": "Very good Drupal Website™",
  "short_name": "Drupal Website™",
  "icons": [{
        "src": "my/default/theme/logo.png",
        "sizes": "144x144"
      }],
  "start_url": "/",
  "display": "browser",
  "theme_color": "#ffffff",
  "background_color": "#ffffff"
}
  • We need to add a <meta name="theme-color"> tag for branding color to compliment the values set inside manifest.json

User interface changes

Site information form changes. New fields:

  • short_name (textfield)
  • start_url (textfield) Could be different from the site homepage.
  • display (select list/radio)
  • theme_color (probably expose that to themes)
  • background_color (probably expose that to themes)

API changes


Probably some ways for theme to declare/alter informations in the manifest file.

More details: Web app manifests usher new wave of progressive apps to your homescreen.

Additional tasks

Once this is RTBC'd, create an issue at
https://www.drupal.org/project/pwa →
to implement the required changes to keep the module compatible with these core changes and implement the new hooks, instead of creating the manifest in the module

✨ Feature request
Status

Needs work

Version

11.0 🔥

Component
Base  →

Last updated about 1 hour ago

Created by

🇫🇷France nod_ Lille

Live updates comments and jobs are added and updated live.
  • mobile

    Issue related to Drupal on mobile devices.

  • Usability

    Makes Drupal easier to use. Preferred over UX, D7UX, etc.

  • html5

    Implements and supports the use of HTML5.

  • Needs usability review

    Used to alert the usability topic maintainer(s) that an issue significantly affects (or has the potential to affect) the usability of Drupal, and their signoff is needed. When adding this tag, make it easy to review the issue. Make sure the issue summary describes the problem and the proposed solution. Screenshots usually help a lot! To get sign-off on issues with the "Needs usability review" tag, post about them in the #ux channel on Drupal Slack, and/or attend a UX meeting to demo the patch and get direct feedback from designers/UX folks/product management on next steps. If an issue represents a significant new feature, UI change, or change to the general "user experience" of Drupal, use Needs product manager review instead. See the scope of responsibilities for product managers.

  • Needs documentation

    A documentation change is requested elsewhere. For Drupal core (and possibly other projects), once the change has been committed, this status should be recorded in a change record node.

  • Needs change record

    A change record needs to be drafted before an issue is committed. Note: Change records used to be called change notifications.

  • Accessibility

    It affects the ability of people with disabilities or special needs (such as blindness or color-blindness) to use Drupal.

  • Needs accessibility review

    Used to alert the accessibility topic maintainer(s) that an issue significantly affects (or has the potential to affect) the accessibility of Drupal, and their signoff is needed (see the governance policy draft for more information). Useful links: Drupal's accessibility standards, the Drupal Core accessibility gate.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment over 1 year ago →
    🇨🇦Canada mgifford Ottawa, Ontario
  • Open in Jenkins → Open on Drupal.org →
    Environment: PHP 8.1 & MySQL 5.7
    last update over 1 year ago
    CI aborted
  • Open in Jenkins → Open on Drupal.org →
    Environment: PHP 8.2 & MySQL 8
    last update over 1 year ago
    Patch Failed to Apply
  • Comment over 1 year ago →
    🇩🇪Germany Anybody Porta Westfalica
  • Comment over 1 year ago →
    🇩🇪Germany dercheffe Sersheim, Germany

    It's up to the developers and UI / UX designers to create an accessible interface regardless of whether the orientation is locked or not. IMHO Drupal shouldn't go against the manifest specs. If an option is available in the specs and supported by most browsers, even if not mandatory, it should be configurable.
    If you don't want to lock the orientation change, you would choose the "any" option (which should be the default option since it will be the case in 90% of the WPAs) but if - for some reason - you want to lock the orientation, Drupal should provide the means to do so.

    As a disabled person I agree with that 👍. Going with the standards/specs of technology is almost a good option. Don't forget that accessibility often plays together with different third party apps. The assistance software (braille device etc.) is more comfy with standards. And in my opinion it might be a kind of exclusion too, to "hard code" an option independent from it's direction. Let the developers/designers decide what is necessary for the individual use case.

  • Comment over 1 year ago →
    🇨🇦Canada xmacinfo Canada

    We can remove “orientation change” from the list I made.

    But there is no clear consensus on that one. See #194 and #192.

    Creating a good-looking and usable web page/web app in both orientations requires more work. But using responsive CSS code helps to build pages that adapt to most screen sizes.

    Personally, on an iPad, for example, I want to be able to use a web page/web app in any orientation and not be left lock-out in one orientation.

  • Comment about 1 year ago →
    🇯🇵Japan tyler36 Osaka

    From #197

    > If an option is available in the specs and supported by most browsers, even if not mandatory, it should be configurable.

    This. However, "orientation" is marked as "Experimental: Expect behavior to change in the future." so I would be inclined to skip this (and any other experimental) to increase reliablity.

    Currently, patch #187 and the MR reference the "color" module which was removed in Drupal 10.

  • Comment about 1 year ago →
    🇺🇸United States Albert Volkman

    Created a version of the existing patch to apply to 10.1.x

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024