CSS admin-contents reloaded

[JSey (Joe Seyfried)]

Continuing the discussion from CSS Clearfix for admin-contents:

@zogstrip

I just pushed a fix that will automagically disable custom stylesheets when you’re entering the /admin section and enable them back when you’re leaving it

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…

[zogstrip]

What kind of customizations have you made to the admin section?

[JSey (Joe Seyfried)]

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.

[thangngoc89 (Khoa Nguyen)]

I think a F5 you clean every custom CSS in admin section

[DeanMarkTaylor (Dean Taylor)]

Just to re-iterate what was said to @zogstrip via PM:

I have this problem in admin too.

Directly visiting /admin includes the Header section from added via CSS/HTML > Header.

Now that the CSS is not loaded in /admin the custom HTML added via Header is unstyled and looks bad.

[JSey (Joe Seyfried)]

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.

*sigh* Now Dean was faster…

[zogstrip]

I understand, so the bug is that we are only disabling custom CSS and not all the customizations…

[DeanMarkTaylor (Dean Taylor)]

It seems reasonable to to require admin additions to be done via plugins.

I would like the possibility of user code additions in admin - but you can’t have every thing.

[zogstrip]

@DeanMarkTaylor

I would like the possibility of user code additions in admin - but you can’t have every thing.

Yeah, it’s a balance between ease of extensibility and users making mistakes that are hard to recover from.

[elberet (Jens Maier)]

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?

[riking (Kane York)]

Let’s try an experiment.

Put this into your </head> customization:

<style>body { display: none !important; }</style>

Enable, save, and close all other forum tabs.

How do you recover?

1. ./launcher enter app + rails console, which may not be available to every admin of your site (as in, the ones that do have access are asleep).
2. Use the inspector to delete the CSS rules.

Okay. Now let’s change that bad CSS into bad javascript that causes all pages to not load…

[elberet (Jens Maier)]

What? No!

3. Open a new tab, type in https://my.forum.org/admin, fix the customization, done.

And I just tried exactly that.

This is my customization right now, yet /admin is perfectly usable.

[riking (Kane York)]

Oops, I think there was a part of that post that I thought but didn’t type… or I could have just been wrong.

[JSey (Joe Seyfried)]

@riking

Okay. Now let’s change that bad CSS into bad javascript that causes all pages to not load…

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…

[chapel (Jacob Chapel)]

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.

[JSey (Joe Seyfried)]

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…

[elberet (Jens Maier)]

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”.

[JSey (Joe Seyfried)]

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:

<script>$("body").css("display","none")</script>

[sam (Sam Saffron)]

Yeah … this whole change is just causing too much confusion, we should revert to the old way we did this.

Apply everywhere, remove if you refresh admin.

[zogstrip]

Here’s the fix

https://github.com/discourse/discourse/commit/1b2381d5a03e69859617d2be537091730a9a1282