[UX] Overhaul the settings form items for logo and favicon

[indigoxela]

In an otherwise mostly unrelated issue the question popped up, if that logo or favicon upload should be managed files. We didn't find a clear answer, but looking at these two fieldsets on /admin/config/system/site-information...

That's probably not the ideal user interface. It's more or less like the theme settings form in Drupal (e.g. /admin/appearance/settings/bartik). It looks dated and confusing.

Open questions:

• Can or should we make the upload a managed file?
• If it's managed, should we also allow to select existing files?
• Should logos/favicons be reusable like other Files?
• Isn't that "Path to custom..." textfield odd? Is anyone really using it nowadays? (File module is in core and always enabled)

One thing to keep in mind:

• Permissions - this form is an admin form, but managed files have their own set of permissions, so non-admins might be able to change the logo and favicon

[argiepiano]

I like having the ability to specify the path. It allows me to place the icon in places that are not necessarily the managed files folder - for example, in a multi-site installation I can have just one favicon file in one of the site's folders, and reuse that in all. If I need to update it in all my sites, I just update that one file.

A small benefit, I know, but I don't really see a benefit of using a managed file - other than the ability to delete it from the Manage file ui

[indigoxela]

@argiepiano many thanks for your feedback - that's a valid use-case, although maybe a rather rare one.

The more I think the "managed file" thing over, the more it seems to me, it might cause more confusion. See this comment in the other issue.

[quicksketch]

Maybe we could improve this UI with radio buttons that only show the appropriate fields?

(*) Use logo provided by theme
( ) Upload a custom logo
( ) Specify a custom path

However, doing this will hide the most common field used: the ability to upload a custom logo/favicon.

[izmeez]

In Zulip chat there is a recent mention of the contrib module, Responsive Favicons.

It got me thinking how in Wordpress this is in the general settings as Site icon with the description,

The Site Icon is what you see in browser tabs, bookmark bars, and within the WordPress mobile apps. It should be square and at least 512 × 512 pixels.

This seems to fit with requirements described elsewhere on the Internet and allows a site to be saved on the home screen of a device with the Site icon as the button.

On the other hand Backdrop, like Drupal, has what seems to be an old dependency on the .ico file.

[argiepiano]

This was brought up in an issue that proposes creating tokens for the site logo (and possibly the favicon). If these were managed files, the token would be easy to be chained (e.g. to get the uri). But having the option suggested by @quicksketch above (i.e. still keeping the possibility of using an unmanaged file via a typed url), would create issues for token replacement, since the logo could be either a managed file served by the system, or simply a file served directly by a server.

So... I withdraw my comment above about the benefits of specifying a path to an unmanaged file (given that it's a rare use case), and we should modify these two images to be managed files as suggested by @indigoxela.

[izmeez]

Both this issue and issue #5871 appear to have arrived at the same conclusion, i.e. having site logo and favicon (site icon) as managed files. This is also how Wordpress handles them and how Drupal has been yearning for for some time.