I appreciate the idea, but (risking to sound nit-picky) dislike the result for my site: if you have HTML additions which rely on styles which now become automatically disabled, you end up with garbled admin pages - could this become an optional setting (I wouldn’t mind if it defaulted to “off” for the discussed security reasons)? The alternative looks a bit appalling to me, to put all the styles for the HTML customizations as inline CSS…
None specifically for the admin section, I have some 50+ lines of HTML living in Customize->CSS/HTML->Header; and without the corresponding CSS, this leads to:
instead of +
as it was before.
The culprit here is not CSS, that’s properly deactivated. But I have also custom HTML headers which aren’t. Either, Discourse should disable both when I enter admin, or this should be an option: disable CSS when entering admin.
To be honest, I think this feature - disabling loaded and working customizations when entering /admin - is misguided.
If all you want to do is save yourself from boneheaded hosting customers, by all means add a site setting that turns all the links and buttons into the admin interface into real links that reload the entire page without any customizations and enable that setting by default for your hosted Discourse instances
Just leave those of us who can find a clue without immediately yelling at their paid support alone; please?
Agreed - for my case, a completely un-customized admin section would work! It’s the combination of no-CSS+HEAD-customizations that breaks things. I don’t know @elberet’s thoughts on this - but I am used to non-customized admin sections from other software, too. I cannot really imagine a use case where one would need such a thing - but as usual: YMMV…
And if they did need it, they would need to install it using a plugin. So it is harder to mess up their install, and is definitely their fault if they do.
Any thoughts on this issue? We’re not alone with it; and I do think disabling both CSS and HTML header/footers would be the least confusing option. To make Dean happier, this could also be configurable… defaulting to off, and a warning sign in red and blink beside it that you lose all support if you click it…
I still think that this entire debate is misguided and that trying to remove customizations from the initialized app when entering /admin is a genuine Bad Idea™.
For example…
We’re telling people to stick JavaScript snippets into their customizations that monkey patch stuff in the Ember app, and removing and re-adding such a JS snippet when entering /admin and subsequently coming back to the frontend would run the code again. It should be obvious that this may have unwanted effects. The logical conclusion, then, is to require that JS in customizations is wrapped in a special function call so it doesn’t get executed twice…
…and now a core feature, customizing the look of Discourse, has become an order of magnitude more complex because some dude got confused when forum.com/admin looked different than forum.com -> “Admin”.
Is there any news on this issue? The question keeps re-surfacing, so we would need a clarification in the admin section, plus the head customizations are just as dangerous as CSS, try this one:
+ 
