A thought on CSS and customization in general - Optional disabling on the admin console

(Nick Sahler) #1

I was thinking about customization in general, and breaking things (something I’m good at) and I thought it might be a good idea to give the option to disable custom CSS/Headers on all admin pages. This would handle CSS breakage elegantly in that if the user somehow made his site unusable while customizing, he could just pop back into the admin page and disable or modify things. I would enable it by default but obviously give the option to have a pretty (but potentially broken and unreachable) admin page.

CSS admin-contents reloaded
(Jeff Atwood) #2

I believe @sam has brought this up before, seems sensible to me.

(Tobias Eigen) #3

I’m running into just this issue right now - I have added a custom header menu to my site, which looks lovely on the frontend but borks on admin. If there were a way to hide the menu from all /admin pages I’d be grateful.

The custom header also borks printing but that’s a different issue.

(Benjamin Freeman) #4

Yep, if the admin page could only load the default css that would be great

(Kane York) #5

Until this gets straightened out, you can work around that by putting the styles next to the html in a <style>.

(Erlend Sogge Heggen) #6

Although only tangentially related, it seems fitting to resume this discussion in light of our upcoming native themes support. I think this is a great feature and I’m hoping the @team can take a renewed look at it.

We’ve had to bail out customers a couple of times exactly because of the type of CSS breakage that @Nick is describing. It hasn’t happened often, but it does happen, and being locked out of your site is basically the worst kind of UX experience a user can have, so if we can bring that occurrence from 1% of sites down to 0.1% of sites, I think it’s well worth doing.

Also, as a Discourse team member I have to go into a lot of customers’ admin panels, and oftentimes their admin panel is a really poor experience, because their Color & CSS customisations never took the admin panel into account – nor should they have to! So not only are we giving a lot of our users a sub-par admin interface; we’re making them our accomplices!

This is not the :rainbow: way

Custom styles not appeared if you go from /admin routes to public pages
(Joe Buhlig) #7

I ran into an issue with this today but on the javascript side. I was trying out some group specific javascript code today (thankfully on my development environment) and in the midst of my debugging I rendered my site unusable. I couldn’t get any pages to load. Even the ?preview_style=default trick didn’t work.

That said, I’d be in support of disabling the javascript side on admin screens as well. I had to go into the database manually, alter the customization, and then restart with a cleared cache in order to get it back. That would not be a comfortable situation in a production environment.

(Sam Saffron) #8

You can always bring in the bigger guns which is safe-mode :slight_smile: