The original poster, amatthews, was having trouble updating two image URLs to HTTPS, specifically the favicon and Apple touch icon, after enabling HTTPS on their Discourse forum.
omarfilip and codinghorror suggested re-uploading the images through the admin settings (/admin/site_settings/category/branding) to update the URLs.
amatthews confirmed that enabling force_https and re-uploading the images solved the issue. However, they suggested that it would be better if the image URLs automatically switched to HTTPS when force_https is enabled.
itsbhanusharma explained that the intended behavior is to load all Discourse assets over HTTPS once force_https is enabled, making re-uploading images unnecessary. Stephen noted that this behavior is a recent change and that the frequency of this issue has decreased since its introduction.
I inherited a Discourse forum from a previous team member. I’ve gone through and made a number of changes requested by my marketing department but there are two last images that I can’t find anywhere. I’ve spent several hours scouring the customization section and nothing.
All of the branding assets are in Settings → Branding /admin/site_settings/category/branding
The favicon (32x32) and Apple touch (180x180) are 7th and 8th down on the list. Perhaps deleting the existing and re-uploading new ones will set the correct url for them.
Could these urls automatically switch to https when we enable Force https?
I’ve encountered this issue on several clients’ installations. That’s not that annoying, but if it could be avoided by a single line of code somewhere, that would be nice nontheless.
This is one of the reasons we changed discourse-setup to default to HTTPS. Making it optional meant most people skipped it and had to backtrack to it afterwards.
I went ahead and enabled force_https, reuploaded the image and they’re now loading via https, thanks!
Feedback from a first time admin user of the forums:
Asking someone to run through a setup wizard to fix an image reference feels like bad UX. I was nervous the whole time that I’d change one of the existing settings accidentally. Better to just have granular controls for that (which you do). I wound up using those instead.
Also, I’m curious why I had to reupload the images to begin with. Why aren’t you just storing a file reference and outputting the protocol based on the settings for force_https? That might actually be what you’re doing because I changed the force_https setting AND reuploaded the images before testing.
Regardless, you guys jumped on this question quick and I really appreciate it. Stay safe everyone.
That definitely wasn’t the case in the past, we got this question reasonably regularly, prior to the change above that @falco referred to. Running a quick search the frequency we get asked this fell off a cliff with the introduction of that PR.
The gross majority of installations will work with Let’s Encrypt out of the box, it’s only when people do squirrelly things with reverse proxies or network rules that it falls over.