Inconsistent body class for /admin paths? (disabling top navigation)

I am using a simplified top navigation bar like the one that used to be on try.discourse.org based on the code provided here:

https://meta.discourse.org/t/branding-discourse-experiment-on-try-discourse/3387/4?u=tophee

It works fine with one exception: when I access /admin directly (without having loaded the forum previously in the same tab) the top-navigation bar doesn’t load so that I see only the default discourse header like here on meta.

From what I can tell, it seems to have something to do with the body class: when navigating the forum as an admin starting from any forum-URL not including /admin, the body class does not include docked unless I scroll down to make the nav bar disappear. In contrast, when navigating the forum starting from a forum-URL including /admin, then the body class is fixed to staff docked (And the nav-bar is hidden when the class is docked).

I would expect the default class under /admin to be simply staff and docked to be added when scrolling, just like everywhere else. Is this is an inconsistency in the discourse core or am I misunderstanding something and it is only the CSS code above that is missing something? In the latter case: what is missing?

It’s the normal behaviour. Styling is not supported in that area.

See here:

https://meta.discourse.org/t/custom-styling-doesnt-apply-to-admin-pages/15077/9?u=trash

4 Likes

I see. Except that my custom stylesheet does work under /admin when I navigate there from the front-end and within the same browser tab. Differently said: the admin section has different body classes depending on how you navigate there.

I’ve noticed this as well. Sometimes certain parts of our custom CSS will affect Admin (like button shadows), but mostly it doesn’t. I can’t say for sure, but @tophee’s description of navigating in from the front-end seems accurate. I’ve had a dedicated Admin tab lately (lots of customization stuff) and I never see the issue there. A full refresh of any admin page will also remove the CSS customizations that are appearing.

For a very very long time, we disabled all customizations on first load for /admin path. Now that we have safe-mode route I am not sure this is as required. We may change this.

The problem is that people would mess up a customization and then have no idea how to bring site back into operation.

7 Likes

Makes complete sense. What I would suggest, though is to make this behaviour transparent so that admins understand that they must look at the front end to verify their customizations and don’t waste their time trying to figure out what is going wrong with their code. Here would be a good place for this:

Add something like "For security reasons, most customizations are not applied to the admin section of the site.

I realized my post might not have been clear. I’m 100% in favor of not using custom CSS or JS when looking at any /admin path - I was just trying to clarify that I’ve noticed inconsistency too.

I don’t think anything is left to do here? Right?

2 Likes

This topic was automatically closed after 5 days. New replies are no longer allowed.