I’m not following here. Since you deleted the old custom logo small, the application would default back to the Discourse logo since you don’t have anything configured.
Last time with the default settings it was a icon, something like that:
But maybe this icon was replaced with Discourse logo at the default settings.
OK I can confirm this is a bug. Will have a look.
What plugin are you referring to which impacts the logo?
With the current beta, without HTTPS users are seeing an unsafe script prompt from Chrome. So looks like then it may a problem both ways (with and without HTTPS) if what you’re saying is true:
The originally reported issue here from OP relates to this plugin:
Which controls access to uploaded images and thus was interfering with how logos and icons were accessed after core changed the way such uploads were handled. It’s not the fault of Discourse itself, a third party plugin was built on an assumed behavior, core changed and said plugin impacted core.
Several people came to us with similar sounding issues at the release of beta 8 and all piled onto the same topic, because they assumed their issues were one and the same. One user had a plugin conflict, another had reverted their logo to default, and a third had erased the value which led to the site name being displayed instead. That’s part of the fun of troubleshooting these issues, on top of the originally assumed issues each user can make material changes to their setup in an effort to fix it, leaving them in even more diverse states.
Good to know.
I checked and we aren’t using this plugin. Double checked all the settings the staff has recommended. As I had mentioned earlier nothing changed except for upgrading from BETA6 to BETA8 and now with HTTP only it no longer serves the icon consistently and more importantly it shows the scripts warning error.
There are only 4 discourse plugins being used
Open to troubleshooting options and unfortunately there’s no way to go back to BETA6.