Ignore theme for admin backend, or add classname to <html>?

Continuing the discussion from Different theme for admin backend?:

The current recommended workaround for not theming the admin UI is:

Discourse supports SCSS which means that you only need to add body:not(.admin-interface) once to your theme. You don’t need to add it to every rule.

On first look it seems a bit problematic because the :root selector where various colors are defined is above <body> and custom colors still affect both admin and user interfaces.

It would be easier if the <html> tag also had an .admin-interface (or a variant thereof) class. (Or, better still, theme customizations would be even easier if a separate (default) theme could be configured for the admin UI.)

If Discourse enabled theme creators to just theme the parts visible to normal users, it would probably make theme creation/customization easier.


A somewhat related topic is using a separate language for the admin UI (discussed here: Can discourse have different language interfaces for admin only?) — it would be especially helpful for tweaking translations for languages that have very rough (meaning: incorrect) or incomplete coverage (lots of strings untranslated).

I’m currently setting up Discourse in Estonian, and would like to fix bad user-facing translations as I see them, but using the admin UI in Estonian is very confusing because so many texts are incorrect or simply not understandable.

2 Likes

Yeah I think it would make sense for us to split off the admin area at some point, it can definitely be an extra burden to theming, which usually isn’t necessary. Wordpress also separate admin themes/styles.

In the meantime, I’ve made a PR to add an admin-area class to the HTML tag. I used a different name and kept the old body tag so that it doesn’t impact existing themes.

6 Likes