Previously, logologo smallmobile logo etc were just shown as their urls (and you had to upload the logo to “Assets for site design” and copy the url over).
Now, you can upload an image directly to the logo etc site settings. So the benefit of this new UI is evident.
But there are also some serious downsides:
To start with, I can’t copy the url of the current image and save it somewhere, e.g. when I want to try out a new logo but switch back to the old one by pasting the old url back to where it was.
Also, there seems to be no way of using the images that are already stored in “Assets for site design”. If I want to use one of those images, I have to download it to my computer and upload it from there to site settings?
And it is not transparent where those logo images are stored. Not in “Assets for site design” as far as I can tell.
This is rather confusing so I’m not sure if I’m misunderstanding something…
Yep, I’ve had a similar experience in the past day, in the end I rooted around in the page source to get the path to the image.
Could we get the text field below the image with the path? Could we have both the upload dialog and the ability to paste a URL?
It’s an improvement in terms of not knowing the topic trick, but as there’s no underlying media library it’s more a step sideways than directly forward. Hoping this is a first iteration and we will see more improvement before 2.3.
If you’re uploading a logo to set the site setting, you’ll have both files locally on your disk. To switch between both files, you can just re-upload the file.
Yup you’ll have to download the images locally to your disk. Note that the Assets for the site design topic will no longer be seeded going forward. In fact, it was already super-seeded by the setup wizard.
I’m not following this because where and how the upload is stored is an internal implementation of the software. The admin should have no need to know whether the images are stored in a topic or somewhere else.
I personally feel like this is a feature request for the image uploader component that we use for multiple things such as user profile background image, user card background image and category logo image. I’m open to adding this but I don’t think it’ll make it into the 2.3 release.
Nope, that’s exactly why I stumbled across this. I don’t have all the logos for all my sites on all my computers, and especially not my mobile devices which I use much more frequently.
Of course, I can always download them and reupload them, but this was not necessary before. And on mobile, such operations can be a real pain.
Hm, I quite liked the simplicity of the idea, but I understand that discourse has been ridiculed for it and there surely are better (or more professiinal looking) solutions. But I’m not sure the current state is an improvement. (I wouldn’t see the setup wizard as a replacement for any UI element. In my mind, a wizard provides a different/easier way of doing things that you could alway do without the wizard too.)
Yes, I think that would pretty much solve things. Looking forward to it.
That was necessary before as well. In order to switch to a new logo, you would have had to upload the image to the Assets for site design topic first before copying and pasting the URL into the site settings field.
I’m not sure I agree with this. Previously we had to communicate to users the “special” topic for them to upload their images, ask them to copy the URL of the image and then paste that into the site settings field. Right now, they go straight to the site settings page and just update their logos with an interface that is intuitive.
Yes, I acknowledged exactly that as an improvement at the beginning of the OP. My point is that while you’re improving the UX on one end, you’re making it worse at another. Whether that equals out or whether the improvement side weighs more is a matter of perspective.
I’m not saying that the changes should be reverted but I thought this was a good suggestion:
@tgxworld I would agree with @tophee & @Stephen here. Having text fields along with the image upload option would be quite useful.
Here is a real usecase - I faced this problem today when I configured s3 for uploads along with a s3_cdn url. Image uploads for logos only point to s3 and not s3_CDN urls. (while it works correctly in posts).
In the above scenario, having a text box would have helped to update the logo urls with s3_CDN url (as a temporary fix).
Request you to consider adding the text box below the image upload option.
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.
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
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 forum.domain.com/public-images/123123123123123123123.png)
Please correct me if I’m wrong here
PS: are there workarounds if I need to change the current logo? Maybe a database update or something?
