Downsides of the new logo UI in site settings

That’s my point really, it appears this decision was made on a flawed assumption. The new interface relies on you having the file stored locally, which is the opposite of the behavior Discourse previously encouraged. Previously we could have several logos stored in the Assets for the Site thread under Staff and refer to them as and where required. This is a definite disadvantage to the new UI.

One of the communities I assist has special versions of their logo for particular seasons and holidays. They used the assets topic to store all of these files, any of the staff could update the logo when a particular season was upon them. There shouldn’t be any need for them to each keep local copies in 2018.

I’m really hoping that this is just an interim step before we see some kind of media library implemented. Until then it would be great if we could get a URL field below the new image fields, so as to not cripple the workflow which existed previously.

I don’t think this is fair to say at all, it never superseded the assets topic nor the settings under /admin/ because it was only visible during setup, or to those who knew where the wizard was once the site was live. We could still use the topic which has existed for at least four years to store assets and swap between them whenever needed. Relying on local storage isn’t really any substitute for the flexibility this provided.

That’s an assumption based on a new and highly inflexible option - previously we didn’t have a media library per-se, but we did have an online collection of assets we could easily switch between. It has only become an internal implementation with this change. We didn’t need to be at a particular computer, with access to particular files. If a logo needed to be swapped out we could just dip into the old assets thread, grab a text URL and paste it into a text field. We could also repurpose the same URL into several fields. The new approach offers no such flexibility.

Already noticed, the first step I’ve taken to remedy this is to manually recreate it. In the case of tweaks which don’t warrant a theme component, sites still need somewhere to store assets referred to in CSS and HTML customisations. Without a media library to manage assets we still need a means to get them into Discourse.


While I’d agree for this specific use case uploaded images may seem like a disadvantage over URLs, the vast majority of sites never change the logo once set. In the rare case the logo needs to be changed, simply uploading a new logo right from settings is far simpler and easier for admins to do then uploaded to a topic that exists in staff, figuring out how to copy the URL, navigating back to site settings, and pasting in the URL.

For the site that changes logos frequently, nothing is stopping them from storing all the different logos in a private topic. If someone needs to change the logo, they go to that topic, download the logo, and upload it to site settings. Same number of steps as before, except instead of copying/pasting a URL, you’re downloading/uploading an image.


Sure, but that topic didn’t just store logos. All of the icons and logos specified during setup go here, a lot of communities use the topic exactly as it’s titled, for every asset related to the design of their site.

Even if you don’t change your logo, you still need somewhere to store assets that don’t have a UI option, including for theme components and backgrounds. As an example the banner themes component uses an imgur link for the demo image, if you wanted to use anything else then the Assets topic was the go-to place to store it.

I agree that the topic approach was far from ideal, I remember raising an eyebrow when I first discovered it myself, but now that it has become an accepted practice to store design assets it seems a tad shortsighted to remove it wholesale when the substitute doesn’t provide functional parity.


The topic hasn’t been used during setup since the Wizard was introduced. The wizard stored the logos internally, not in the assets topic.

I’m confused. Both themes and theme components support uploads. Why would you need to upload assets outside the theme itself?

That topic shouldn’t have been the go-to place. Theme assets should be uploaded directly to the theme.

As @eviltrout just said to me: “the topic was always a hack. it saved a little time, but if I were to do it again I’d push for building uploads into site setting like we eventually did”.


That’s easy to say, but uploads to themes weren’t there, outside of the team practices are going to develop which you didn’t intend, but that doesn’t make them wrong, particularly the broad title that topic was given.

The upload UI to themes and components is definitely an improvement as multiple assets can be uploaded and switched between within the css, which further emphasizes the limitation of the logo upload fields.

Hopefully the logo/icon asset management side of things can at least be expanded upon to mirror this.

I’ve actually wondered if the logo would ever just switch to be a setting in the theme. That way you can have true simple way of doing a dark and light version without a CSS hack and having the Setting/wizard update the default light theme that ships by default.


I thought about this too, the challenge there is that the logo would need to be uploaded to every theme, but not all themes need different logos. A logo override field within themes would be nice, though.

Agreed, it comes with its own set of challenges.

From what I’m reading and understanding now, it isn’t that the new UI in site settings that is confusing as what @tophee mentioned. The problem here is very specific to the use case of needing to switch the site settings among a group of assets that have been uploaded before and we’ve increased the friction of that in this re-design. The only possible way I can think of for us to support this is to have some sort of admin media library and during the selection of uploads, you are provided with the option to select from your “admin media library”.

You can still create a topic and store your site designs in there if you want but there is no substitute happening here. We’re simply removing a seeded topic that is no longer required to serve the purpose of holding uploads for either site settings or themes.

I do understand the problem at hand here since I’ve recently had to test some site setting bug and inadvertently replaced our existing logo with something else. After that, it was a challenge again for me to find the original file to re-upload.

How I’ll like to approach this problem is to have each upload site setting be tied to a theme_field and then have those fields be part of a Theme. The UI for the upload site settings can then be changed to have an extra option where you can select an existing upload from the “Assets Theme”.

@sam @Osama I’ll like to know what your thoughts on the above are :slight_smile:


Yes, the confusion has meanwhile been cleared up (I changed the topic title to reflect that). What remains is the

that you mention and that you experienced yourself.

… or any other url, I suppose? Or will it be limited to the stuff uploaded to that theme (aka “media library”)?

A URL is not going to cut it because we’ll have to handle the download of the file for the user on the server whenever you provide us with a URL. While it seems like a convenient way of doing things, it was actually passing the responsibility of ensuring that the URL is valid to the user which I don’t think is right. The user should just give us the file and the Discourse instance will handle the URL generation.

I would very much appreciate this. We are using the image-guardian plugin, and from what I can tell, we no longer have the ability to specify a different path for the logo/favicon than the “protected” uploads-folder (current url for logo is

Please correct me if I’m wrong here :slight_smile:

PS: are there workarounds if I need to change the current logo? Maybe a database update or something?


Today I was replacing images: ‘logo_black.svg’ with ‘logo_white.svg’ - And both images are identical except for the color.
The problem in the admin: /admin/site_settingc/category/required is that the images look exactly the same in the backend previewer.

How do I know which images I have already uploaded if I am uploading it in ~7 places?
Which one is using the black and which one is using the white version?

Here it would be very helpful to have the filename of the image below the image.


Just landed

on master.


This is awesome :kissing_closed_eyes: :confetti_ball:


I believe this is all complete now @tgxworld?

Would still appreciate until the media library becomes a thing for the URL for the uploads be displayed, even if read-only. Much easier that way for site owners to grab the URL for use in theme components, etc.


@david can you confirm since you’re working on that part as well?

The upload site settings and lightbox, with filename, are all complete. @tophee’s and @Stephen’s request for an “admin media library” has not been implemented.

@tgxworld mentioned this possible solution:

This is risky, uploads that are not referenced somewhere will be deleted automatically. In themes, you should always use the uploads system, and refer to the files using variables.

The need for this kind of workflow should be greatly reduced in the next couple of weeks - I am adding automatic resizing to site icons, so you only need to upload once.


O yes, it is still on my plate to get a assets theme going.