New blog: Admin theme redesign

[adrian]

58 minutes ago, ryan said:

I tried this but didn't run into any side-effects, it seems to work really well.

I tested using your example and that does work quite nicely - one of the key things I missed was the --masthead-input-xxxx vars which make a big difference. But as I have noted, the key thing I want is a dark back for the top level of the menu, but not for the dropdowns which is where things get particularly problematic.

One thing I noticed while testing your example CSS is an issue with setting light vs dark mode from the user's profile settings. The first time I tried to set to light mode (instead of auto), the page list hover background went black - going to back to auto fixed it, but now it's stuck on dark mode and no matter what I do, I can't change it to light mode - even after clearing all cookies/sessions.

46 minutes ago, ryan said:

What are you suggesting with the question, that we should drop dark mode? But to answer your question, I would say the same thing you'd do in any issue situation, report the issue. But by the time this is on the main/master branch, I don't think there will be any remaining concerns about dark mode.

As long as we are working towards no bugs in any situation, I am OK with it, but honestly I think it's a waste of effort. I know it's a personal thing, but I feel like the whole dark mode thing will fall out of favor once people realize it's not actually a better experience for user interfaces.

[adrian]

Hey @ryan - one side-effect from your example: setting --menu-item-backgroud-hover to a white like you have also sets it for the big Add New button on the page list screen, which means it doesn't show anything. This is one of the reasons I really believe we need separate CSS vars for the main nav vs other elements and also separate ones for the top level as well as the dropdowns, and perhaps even the next level down again (Pages > Tree etc), because the font size and padding on these is not easily adjustable (not critical though).

[adrian]

It also impacts save buttons - no hover color (because it's white). And, also note the weirdness with the main color on the button dropdown arrow only.

[adrian]

Another issue with --main-color looking weird because of those blue backgrounds that I think bernhard noted:

[BrendonKoz]

1 hour ago, adrian said:

As long as we are working towards no bugs in any situation, I am OK with it, but honestly I think it's a waste of effort. I know it's a personal thing, but I feel like the whole dark mode thing will fall out of favor once people realize it's not actually a better experience for user interfaces.

I'm of the opinion that this is highly opinionated. 😉 One might say that ARIA rules are a waste of effort because the majority of people realize it's not actually a better experience for user interfaces. It's all personal perception.

From my own experience, I find that building a template from scratch with having a toggleable (or auto-determining) dark-mode and light-mode in mind is far, far easier than starting with a light mode as a main default, and then trying to tack on dark mode functionality. KONKAT's determination to go primarily monochromatic should make that quite a bit easier, but it's still not easy. And getting dark mode right so that it feels fresh and elegant to a wide population is quite difficult. That doesn't mean that dark mode doesn't have its place though, and that - to feel modern and accepted to a wider audience - it may be a feature that perspective CM(F)S users would look for, whether they use it or not. If nothing else, it's a marketable feature.

We'll have to see if KONKAT will expand their CSS variables so that adjusting one color doesn't affect colors of other areas that wouldn't normally be affected. I need to install the dev branch soon so that I can provide some proper feedback and comparable override solutions. I suspect KONKAT is using the cascade with their CSS variables in a way that works, but can cause situations as you're showing above, adrian. (And these are useful things to discover!)

CSS variables are great, and they make things quite a bit easier, but there are, and may, be times when you'd need to (or want to) more specifically target the cascade when overriding CSS vars. I suspect most of the issues here are related to that - just needing slightly adjusted CSS selectors, or some additional ones.

One thing to note when overriding the CSS - from one of Ryan's prior posts I learned about the new light-dark() CSS method which is awesomely useful for CSS themes that take advantage of light and dark modes. If you're forcibly applying a static color regardless of mode (for branding, perhaps) like Ryan's last example for the masthead, it's less imperative, but for other areas... If you want to make sure older browsers continue working as well, you might need a fallback value, just in case (the light-dark() method came about in 2024).

[ryan]

Quote

one side-effect from your example: setting --menu-item-backgroud-hover to a white like you have also sets it for the big Add New button on the page list screen, which means it doesn't show anything.

@adrian Only if you set your body background color to the same color (white). Those menus will blend right into the background if you do that. For the light theme I'd suggest having a light, but not pure-white background. Likewise, for the dark theme, a dark, but not pure black background. Unless you make your body background pure white or pure black, you aren't going to run into that issue. An alternative would be to target those dropdowns with a different color, but if it were me, I'd focus on the body background color instead because I think there are more visual benefits for doing that with this theme. 

Quote

the key thing I want is a dark back for the top level of the menu, but not for the dropdowns which is where things get particularly problematic.

I'm still learning how to use CSS vars, but this seems to work for me. Basically, if the element has pw-dropdown-menu class, then I set the variables to use different colors, so that the visible primary nav at the top uses different colors than the dropdown nav that appears. I'm just using boring #ccc and #333 as example colors for the dropdown, but I'm sure you can come up with better colors. 

:root {
    --masthead-background: var(--main-color);
    --masthead-active-color: white;
    --masthead-text-color: rgba(255,255,255,0.8);
    --masthead-border-color: var(--main-background);
    --masthead-logo-color: white;
    --masthead-input-background: var(--masthead-background);
    --masthead-input-color: var(--masthead-active-color);
    --masthead-input-border: var(--masthead-text-color);
    --menu-item-backgroud-hover: rgba(255,255,255,0.25);

    .pw-dropdown-menu {
        --masthead-background: #ccc;
        --masthead-active-color: #000;
        --masthead-text-color: rgba(0,0,0,0.8);
        --masthead-input-background: #ccc;
        --masthead-input-color: #333;
        --masthead-input-border: #333;
    }
}

 

Quote

Another issue with --main-color looking weird because of those blue backgrounds that I think bernhard noted:

I think that main color (pea green?) is probably not a great choice because it's not dark, nor is it light. It's right in between. So it seems like it's always going to have contrast issues, especially when text is involved. I'd suggest going a little darker with it so that it falls more in an accessible color range. Btw, I don't know if that background in your screenshot is supposed to be blue or not. I'll check with Diogo and Jan on that. 

[ryan]

Quote

One thing I noticed while testing your example CSS is an issue with setting light vs dark mode from the user's profile settings. The first time I tried to set to light mode (instead of auto), the page list hover background went black - going to back to auto fixed it, but now it's stuck on dark mode and no matter what I do, I can't change it to light mode - even after clearing all cookies/sessions.

@adrian I tried a few times to duplicate this but not having any luck. If  there are more specific steps you can outline to reproduce it, please let me know. But to me it sounds like maybe the ajax request that saves the color mode changes is failing. Check your browser tools network tab, it may be that there's some PHP or JS error preventing it from completing its job. 

[adrian]

Really appreciate your input and problem solving here @ryan. I feel like there has been lots of discussion about whether we should need to override CSS at non-root levels and I tend to agree that we shouldn't have to, hence my suggestion for --submenu-xxx vars.

Regarding the choice of green - it's the color of a company brand and it works fine for the menu background, but not great for links when there is a background behind (like that blue). I think perhaps the core issue here is how --main-color is used. It seems weird to me where it is and isn't used. Do you think it would make sense to have a separate css var for link color and link hover color? I think "main" is too generic and will always come down t personal preferences regarding where it should be used.

And regarding --main-background I do feel pretty strongly about this being white, so that --menu-item-backgroud-hover is always going to be problematic for non-menu dropdowns (like from Add New and Save buttons) unless I go and do more overrides at non root levels.

The problem with non-root level overrides is that it takes a lot more fiddling to get things right and they are subject to future changes to the PW admin classes, but if we had more variables for more things at the root level, we know they will always work - this is their beauty.

22 minutes ago, ryan said:

Check your browser tools network tab, it may be that there's some PHP or JS error preventing it from completing its job. 

The network response is: {"status":"ok","adminDarkMode":0} so it appears to be ok and no JS errors.

 

[ryan]

Quote

I feel like there has been lots of discussion about whether we should need to override CSS at non-root levels and I tend to agree that we shouldn't have to, hence my suggestion for --submenu-xxx vars.

@adrian I fully support adding whatever CSS vars Diogo and Jan want to add. But I’d hate to throw out the idea of using anything but root-level vars. They seem very powerful to me and a major benefit of using these CSS properties in the first place. 

Quote

Regarding the choice of green - it's the color of a company brand and it works fine for the menu background, but not great for links when there is a background behind (like that blue). 

I mention it just because my eyes are struggling with it in the screenshots and video above. Especially the white-on-green text. But if the company is used to that usage then I’m sure they’ll like seeing it in their admin either way. 

Quote

Do you think it would make sense to have a separate css var for link color and link hover color? 

I'm not sure. I’ve not had that come up yet, so can’t really well speak to it. But I’m not opposed to it.

Quote

And regarding --main-background I do feel pretty strongly about this being white, so that --menu-item-backgroud-hover is always going to be problematic for non-menu dropdowns (like from Add New and Save buttons) unless I go and do more overrides at non root levels.

While very customizable, this admin theme is also something that’s been designed. If “anything goes” and “anywhere” in terms of colors, it’s more of a blank canvas than a professionally designed theme. 

I don’t think this theme was intended as a blank canvas. So there have to be some constraints in place. Making some things customizable, where planned for by the designers, is great. But other things, like rethinking the foundation of a slightly off-white (or off-black) body background might be going too far, because it changes the whole balance of it. 

It appears to me the editing tools (Inputfields, etc.) are designed with the idea that they won’t share an identical background color as the body. So if you go pure-white or pure-black with the body background, I agree that it may be problematic. It may be that they can add more CSS vars, but it might also be that it goes outside the boundaries of how the design is supposed to work. But I’m not the designer, so I’m kind of speculating and might be wrong. 

Quote

The problem with non-root level overrides is that it takes a lot more fiddling to get things right and they are subject to future changes to the PW admin classes, but if we had more variables for more things at the root level, we know they will always work - this is their beauty.

Maybe so. But I will say that as someone new to CSS variables, it’s been refreshingly easy to change anything I need to with what we’ve already got. There hasn’t been any real fiddling, and the affected markup is not likely to ever change in terms of how it would be identified with CSS selectors. So I'm just trying to say that I think we're already in quite a good spot, being able to do stuff I hadn't thought possible before. But I'm not saying that we should stop there. There's always room for making things better and better, at least where the resources allow. 

[adrian]

Thanks for all your thoughts there @ryan - really appreciate your input. The one thing I would say about the new grey background is that I think it looks OK when editing a page - I think the contrast between the background and the input fields is quite nice. What I really struggle with is the page tree and the action buttons white background on hover - that is probably my biggest issue with the new theme. Everything else works (except for some bugs that need ironing out), but that page tree view is just really ugly IMO and I know I am not the only one with concerns about it. One solution to this is:
 

.ProcessPageList {
    --main-background: #FFF;
}

and of course to need to deal with the action hover, but in this case I like the buttons back so I have also added:

.PageList .PageListActions a,
.PageList .PageListActions a:hover,
.PageList .PageListerActions a,
.PageList .PageListerActions a:hover,
.PageList .PageListMoveNote a {
    color: #fff;
    border-radius: 3px;
    background: var(--text-color);
    padding: 2px 6px;
    font-size: 12px;
    font-weight: bold;
    line-height: 1.4;
    text-transform: none;
    display: inline-block;
}

.PageList .PageListActions a:hover {
    background: var(--main-color);
}

One other thought for now - I really like the margins between fields when editing module settings, eg:

but when editing a page, there are no margins:



I thought the setting below would change that, but it doesn't seem to have any impact that I can easily see - it least it certainly doesn't match the module editing layout:

Is it another option somewhere else?

 

[adrian]

 Actually, in case anyone is interested, this is my current complete setup. I've given up on the colored top nav because it really doesn't add anything and in reality does look kinda ugly :)

:root {
    --text-color: #444;
    --muted-color: #999;    
    --button-radius: 10px;
}

.ProcessPageList {
    --main-background: #FFF;
}

.PageList .PageListActions a,
.PageList .PageListActions a:hover,
.PageList .PageListerActions a,
.PageList .PageListerActions a:hover,
.PageList .PageListMoveNote a {
    color: #fff;
    border-radius: 3px;
    background: var(--text-color);
    padding: 2px 6px;
    font-size: 12px;
    font-weight: bold;
    line-height: 1.4;
    text-transform: none;
    display: inline-block;
}

.PageList .PageListActions a:hover {
    background: var(--main-color);
}

h1, .uk-h1 {
    font-size: 1.6rem;
}

This results in:





@ryan - this still needs fixing though:

But, otherwise pretty happy. Toggles and dark mode are disabled in config.php and we still have branding accents, no horrid grey background for the page tree (sorry KONKAT) and my eyes aren't bleeding from the #000 text 😁

Not sure if everything is perfect yet, and I'd rather not have to override CSS vars at non-root level, but it's time to move on and enjoy the fixed nav, scrolling fields and templates dropdowns although we still do need the dropdowns to have a higher z-index than the top-level menu so that Tracy panels can slot into place like they used to. @ryan - is that something you could look into please?

[ryan]

@adrian I'll read and reply in more detail later but that turned out nicely! It looks great

[adrian]

Thanks @ryan 

One thing I have been playing around with is setting the background to white everywhere (not just the page tree) - not sure if I want it or not yet, but tried:

.ProcessPageList, .ProcessPageEdit, .ProcessModule, .ProcessUser, .ProcessPageLister, .ProcessPageListerPro {
    --main-background: #FFF;
}

but the problem does come back to process modules - you would need to specify each process module separately. So I tried:

.AdminThemeUikit {
    --main-background: #FFF;
}

which does work, but maybe there are unintended side-effects I haven't noticed yet.

I guess my point is that because --main-background is used for the body background as well as menu and dropdown button item hover background, we have to do this weird hack. I really do feel that these need separating.

[adrian]

PS - please don't forget about repeater buttons:

[markus-th]

I use the RepeaterMatrix in most of my installations to build page content.

To make elements visually easier to grasp, I use the option to adjust the colors in the item headers.

Unfortunately, this no longer works with the new theme.

Original:

New Default:

New default with @ryan's admin-tweak.css

 

Quote

but that page tree view is just really ugly IMO and I know I am not the only one with concerns about it.

@adrian

I agree with that. In my opinion this is not a good user experience. The "old" style was a lot better/faster to scan.

[Mikel]

One of our test users of the new admin style informed us that there is a minor visual bug on the "close" button of the slide-in pagetree. As I was able to reproduce it, here you can see the issue:

Also present when hovering the "close" button

[diogo]

1 hour ago, markus-th said:

To make elements visually easier to grasp, I use the option to adjust the colors in the item headers.

Unfortunately, this no longer works with the new theme.

This should be a fairly easy fix. Thanks for reporting it!

[Mikel]

As our interface test module evolves, more minor bugs pop up. Here we have the toggles:

I think there is supposed to be a separator between the two options? Interestingly when 3 options are defined there is a separator between the first two options:

[ryan]

Quote

What I really struggle with is the page tree and the action buttons white background on hover - that is probably my biggest issue with the new theme. 

@adrian Interesting, I've been liking the white background that appears when you hover. The Original theme uses horizontal lines instead, so I thought the white background that only appears on hover was a better alternative, while still creating a strong visual row for the current hovered page. But if you don't care for that look, making the whole background white like you did in the page list seems to work well too. 

Quote

I've given up on the colored top nav because it really doesn't add anything and in reality does look kinda ugly 🙂data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw==

I like your new version much better too. It looks quite good, and easy to read as well. 

Quote

 

we still do need the dropdowns to have a higher z-index than the top-level menu so that Tracy panels can slot into place like they used to. @ryan - is that something you could look into please?

 

Yes, I've been trying to compile a list of things like this. But if it's something that NOT visible in regular usage, if possible, please post in the GitHub issues too so that we have instructions on how to reproduce. Though this one may already be there. 

Quote

I guess my point is that because --main-background is used for the body background as well as menu and dropdown button item hover background, we have to do this weird hack. I really do feel that these need separating.

Okay I will make note of this. And we're talking about the dropdowns that appear on submit buttons, and the Add New button in the page list, correct? (since the masthead dropdowns already have variables). 

Quote

PS - please don't forget about repeater buttons:

How do I reproduce that one? This is how the repeater add-new button looks on mine:

and this is how my file upload buttons look:

@Mikel Thanks for reporting the small bugs, I hadn't see those yet, will add them to our list. 

[adrian]

3 hours ago, ryan said:

Okay I will make note of this. And we're talking about the dropdowns that appear on submit buttons, and the Add New button in the page list, correct? (since the masthead dropdowns already have variables). 

It's dropdowns on submit buttons, the Add New button (page tree) and the top menu. What actually happens here (and maybe it is expected, but seems weird to me) is that if I want to override: --main-background for the page background at the root level, this automatically sets the --menu-item-backgroud-hover to the same color because of the reference to it. This means I need to re-set --menu-item-backgroud-hover again which works, but I think these references might might be part of the confusion we'll all be having and it's not initially obvious that changing one will impact the other so you might break things without realizing it. So maybe all that is needed is not referencing one var with the value of another? Sometimes it works, but often it doesn't.

If I do that though, I can avoid that lower level override of --main-background and just go with the following - in this case I am playing with the menu hovers matching the main color, but you can also easily just reset it to the: #eee which I still might go back to.

:root {
    --text-color: #444;
    --muted-color: #999;   
    --button-radius: 10px; 
    --main-background: #FFF;
    --menu-item-backgroud-hover: var(--main-color);
}

.PageList .PageListActions a,
.PageList .PageListActions a:hover,
.PageList .PageListerActions a,
.PageList .PageListerActions a:hover,
.PageList .PageListMoveNote a {
    color: #fff;
    border-radius: 3px;
    background: var(--text-color);
    padding: 2px 6px;
    font-size: 12px;
    font-weight: bold;
    line-height: 1.4;
    text-transform: none;
    display: inline-block;
}

.PageList .PageListActions a:hover {
    background: var(--main-color);
}

h1, .uk-h1 {
    font-size: 1.6rem;
}

 

3 hours ago, ryan said:

How do I reproduce that one? This is how the repeater add-new button looks on mine:

Sorry, it's only impact repeater matrix fields from what I can see.

[adrian]

@ryan - what do you think about adding the scrollbar (like the menu dropdowns now have) to the Page List > Add New button - I have enough of these that they extend well beyond the viewport.

[adrian]

@ryan - did you see my comments about top and bottom margins between fields when on PageEdit? Is that setting supposed to make it look like the ProcessModule interface?

[bernhard]

@ryan I took some time to reflect and let the situation cool down. I'm very interested in keeping up a good relationship with you, which is why I want to address your last post rather than moving on and pretending nothing happened.

On 6/5/2025 at 7:44 PM, ryan said:

The feedback I’m referring to is “this theme is fundamentally wrong”. That’s a broad overarching negative statement referring to the entire theme and by extension those of us working on it, and I’m not sure how to read that as anything other than dismissive.

I think this is neither what I said nor what I did. This statement has really bothered me a lot over the last days. I'm sorry if I made you feel that way. It was honestly not my intention and I apologise for that!

I want to add that if you feel that the other person is behaving unfairly, it might be worth considering whether you've given them a fair chance to explain their perspective. I have read this thread again from the beginning, and I see many posts from my side that very much follow your suggested syntax for being taken seriously. However, I didn't feel that my concerns were being heard or addressed.

I honestly think we both could have done better. I'm fine with that and I hope you are too! Otherwise please let me know and we can discuss this further.

[ryan]

Quote

 did you see my comments about top and bottom margins between fields when on PageEdit? Is that setting supposed to make it look like the ProcessModule interface?

@adrian This is something that’s already been there for awhile. From the API side, this is the $inputfield->themeOffset setting, which can be 0, 1, 2, 3, and 0 is the default. From the admin field configuration side, this is found when editing a field under the “Input” tab and “Visibility > Admin theme settings (uikit) > Margin”. These settings are available in all AdminThemeUikit theme variations. Let me know if this is what you were looking for, or if you were thinking of something else?

Quote

what do you think about adding the scrollbar (like the menu dropdowns now have) to the Page List > Add New button - I have enough of these that they extend well beyond the viewport.

Makes sense to me. 

Quote

Sorry, it's only impact repeater matrix fields from what I can see.

Ah okay, I see it now. Adding to our list of updates. 

Quote

it might be worth considering whether you've given them a fair chance to explain their perspective.

@bernhard This is what I was hoping to get more of, rather than saying the theme is fundamentally wrong (unless that's what you actually think). This is a friendly forum conversation from my viewpoint and there are no negative feelings. I just wanted you to know how the statement can be interpreted, because I suspected that’s not really what you meant, as it would seem to undermine your other helpful suggestions. Diogo and Jan have put a lot of work into this (and done a great job in my opinion), but this is also a work in progress, so we need to be fair and patient. If your goal is to suggest that something should be implemented differently, the more specific you can be, the better. But if you really do think that the theme is fundamentally wrong, then that’s also a valid opinion, and your opinions are always welcome. I’m just not sure how to translate that opinion into an item for our list of updates and requests, so I don't find it helpful from that perspective. But since you've been adding issue reports on GitHub, that's definitely helpful, as are many of your other posts here, so please continue, and thank you for doing that. 

[adrian]

31 minutes ago, ryan said:

From the admin field configuration side, this is found when editing a field under the “Input” tab and “Visibility > Admin theme settings (uikit) > Margin”.

I've honestly never looked at that option - it seems like a lot of work though on a site with a lot of fields. As I mentioned in my post about this, I thought the "Input types that should be offset with additional top/bottom margin." via Modules > Core > AdminThemeUikit would be the place to set this, but it doesn't seem to do anything. Even if it did, it's still a decent amount of work to set all types. 

Can you confirm if that setting is also supposed to do the same thing and if so, can we have an option for all?

Or maybe I should just use some CSS for this.