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

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. 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 honestly quite like much of how the new theme looks and appreciate lots of the decisions and work that has been put into it. It's the problems with tweaking it that are proving the killer for me - css vars should make it easier, but they way they currently are is making it harder. Please try to change the top menu to a darker background with white text you'll quickly notice that many side-effects aren't easy to fix. The problem is that if it doesn't work for some modules but the project developer really wants to use it (or their client does) but then later they discover a new module they want to use doesn't work well with it, then what to do?

@diogo - yes, you need to be able to trigger the nav dropdowns, but that's not an issue with the current theme because the main nav and dropdowns are set to different z-index values and it works great with Tracy panels set to 100.

@diogo - I mentioned this elsewhere, but that fixed header is proving problematic with Tracy because the effective z-index of the main nav is different to the dropdowns. The way things used to work I could set Tracy's panels to 100 and they would appear over the main nav, but the dropdowns would appear over the Tracy panels (which is the behavior we want). Do you know how that can be done with the new fixed nav? It seems I have to drop Tracy panels to less than 50 (maybe something higher but that works) for the dropdowns to appear over the Tracy panels, but I need 200 (maybe less, but 100 isn't enough) for the panels to be above the top nav. If they go below it's hard to grab their title and move them.

@diogo - that's a kind suggestion, but I don't honestly think that is the right route to take. I strongly believe that we all need to move to adopt your new theme to avoid issues with some users being on the old and some on the new. Despite all the assurances, I am still certain that the old theme will be problematic at some point with core functionality and/or some new modules. I think we just need some refactoring (to prevent the reported issues with the core and modules) and other bug fixes along with more distinct css vars so that any aspects of the new theme's color scheme can be modified easily and so that these css vars will work in the future should PW ditch UiKit at some point.

I agree with a lot of @bernhard's issues, but if I am understanding his suggestions about aligning CSS vars with UiKit's classes, then I don't agree with that suggestion. I think the CSS vars need to be agnostic in this regard (for when PW moves away from Uikit at some point). This is why I am wanting things like: --text-color --text-color-hidden --text-color-active --text-color-hover --top-menu-text-color --top-menu-background-color --top-menu-text-color-active --top-menu-background-color-active --top-menu-text-color-hover --top-menu-background-color-hover --dropdown-menu-text-color --dropdown-menu-background-color --dropdown-menu-text-color-active --dropdown-menu-background-color-active --dropdown-menu-text-color-hover --dropdown-menu-background-color-hover Same for button text, color, background, border-radius including hover state, etc. It's really not that many but will mean that we don't have situations like where --blocks-background is used for the text color of a button. I haven't put proper thought into these yet, but hopefully you get the idea. And, definitely no vars that reference other vars meaning that you can't override one without affecting the other. There are actually a lot of good articles online for css variable best practices - I know I need to read more about this.

On this note, I have already noted that this has affected Tracy and the z-index I need to set for its panels. How can I support it to work properly for the base UIKit and the new theme?

I really agree with @teppo here - setting css vars outside of the root context seems dangerous. I am not expecting an infinite number of css vars, just not reusing of ones that don't seem semantically correct, like my example of --masthead-active-color also being used for all submenu items and --muted-color being used for hidden pages along with page list actions. It honestly feels like --muted-color may as well be called --light-grey in the sense that it's describing a color, rather than a usage which defeats the flexibility of css vars. I'd be happy to compile a starting list of the vars that I think we need (and what they should be used for) and then have other passionate and skilled folks her chime in to help refine. I think with a little brainstorming we can end up with something really powerful and flexible and all defined at the root level.

@ryan - maybe all our concerns will go away once all the bugs are sorted out. Maybe all of bernhard's modules will work without issue, maybe my issues with checkbox toggles not working in my modules with custom AJAX loaded tables will be fixed and maybe it will be possible to skin colors easily without contrast issues. Maybe then your point about them being the same theme just with different styling will be correct and this all won't matter. If that is the case, then I sincerely apologize for my frustration. I think the problem is that it's actually hard for any of us to know what are actually issues that should be reported on Github vs decisions that have been made that we just have to deal with. I know you spent some time in the first post of this thread showing how certain things can be overridden and that is helpful, but I'd love to see you or konkat try to replace the grey background with white and make the main nav have a darker color (just a simple green or blue) and get an idea for the struggles that are had when attempting this. Here's another example I have just noticed. --masthead-active-color controls the color of the active top level menu item, but it's also used for all submenu items (which as we know don't have active or inactive states, so why is it used here?). I just don't see how that makes sense. For example, I want the green nav background and I want to distinguish the active page at the top level, but now the submenu items are also white. Is there a recommended way to deal with this? I'd ideally like the submenus to not have the green background - which can obviously be down with overrides, but it just seems like skinning has become more difficult than it used to be and css vars should make it easier. Not really - I just want to be able to adjust menu text separately to the search box without needing overrides.

It might well be possible to do what you're saying (I have typically only used them at the root level), but I think what you're suggesting becomes very messy very quickly. Styling is complicated and I don't want to veer too far from the defaults of the new theme, which is why I listed these key things at the start of my post above: https://processwire.com/talk/topic/31277-weekly-update-– 30-may-2025-– customizing-default-theme-in-adminthemeuikit/?do=findComment&comment=249059 I think if we could handle those easily, we'd be ok here, giving us the ability to give the admin a quick color skin to match client's sites without having to adjust a million different things to avoid contrast issues.

I know this is the intention and I understand how the new one depends on it, but even if it remains that way indefinitely, module authors (in particular @bernhard) are already having to deal with differences between the two - will he support both or at some point give up and only support the new? At some point new modules will come along that only work with the new theme and so those of us using the old one will have unusable modules. Software changes and in my experience you need to upgrade to the latest implementation sooner than later because at some point it will bite you and the longer you leave it, the more you will need to do to fix things.

Hi @diogo - thanks for your thoughts! I think the key thing here is that if you like the look of the new theme (and there are many things I do like), then it's great (checkbox/toggle issues aside), but if you don't like the look or just want to theme it easily to match a client's brand, then it's really painful to adjust - I think that is what most of us are taking issue with. The key things I want to be able to do easily are: set the background and text color of the top level nav without it impacting the color of the dropdowns (like we could before) change the grey background to white and be able to fix the issue with the background color of the page actions row - personally I would really appreciate an option to go back to the button look without css overrides, but just being able to set the background of the rows without it impacting other things (I can't remember now what it was) would be fine. change the inactive state of buttons to match the primary color rather than using it for the hover state Honestly, that would satisfy everything for me. Thanks for considering. Other than Modules > Refresh, I am curious what else are actions and not pages? I really think the active class here would be great. Sorry, but even though this sounds good in theory, I really don't think it works in practice. You can't overwrite variables that are the dependents of other variables without consequences (unless there is something I am missing). And the contrast issues prevent changing 5 or 6 variables to get things working if you decide to go with darker over lighter colors for backgrounds. The thing is though, that with AdminStyleRock you only needed to change a couple of things to make a significant change. You can't actually do that with the new approach (and have it remain readable). But, I really love CSS vars and want to make this new approach usable. The issue with page list actions comes about when you want the background to be white and not the new grey. Now the white background highlighted color of the page list actions row doesn't work so the links to "edit" aren't very visible at all. Changing the background color of these has been other consequences because of the few css vars issue. So, I ended up restoring the actions to buttons using .PageList .PageListActions a, .PageList .PageListActions a:hover,.PageList .PageListerActions a,.PageList .PageListerActions a:hover, .PageList .PageListMoveNote a {

I think this has already been reported but can't find it. There is a really bad FOUC on smaller screens - the top nav shows before being hidden for the hamburger menu. Also, the close button on the hamburger menu is broken. And another crazy css variable reuse --main-background also determines the background color when hovering over menu items in the hamburger menu. This doesn't work with the colors I am trying to work with.

--muted-color is also used for the page list action links but these should be highlighted, not muted. But regardless of what you think they should look like, they definitely shouldn't be tied to the same color as hidden pages. And is there a reason it's --muted-color and not --muted-text-color?

Sorry to keep going, but we desperately need more css vars. --blocks-background controls the color of so many things it makes it effectively useless. It impacts the top nav, the actual field blocks, the color of button text (what's with that?), the page list actions hover bar, and probably more. I love css vars (I never jumped on the less/sass bandwagon), but they only work if they are distinct enough to modify everything as needed because if we need to mix and match between css vars and class/id targeted overrides it becomes an awful mess very quickly and things will surely get broken with future PW changes. I really am trying to figure out a way I can turn on the new theme for users because I know that it's only a matter of time before the old one is no longer supported (that's not a slight, it's just reality when there is limited time and resources to maintain things). I really wanted the background of the main nav to be darker color with white text, so went with: :root { --main-background: #FFF; --text-color: light-dark(#444, #efefef); --muted-color: light-dark(#999, #efefef); --masthead-text-color: #FFF; } #pw-masthead { background-color: #c3d152; } but you end up with the placeholder for the search box white as well. I am sure I can override that as well but my point is that it gets messy fast without more specific vars to work with.

Also, as I mentioned in the other thread, along with changing the text color away from pure black, I still think another very important tweak is the color of the dropdown menu items - I still think they need to be the same color as the top level menu items when not selected. At the moment it looks like all submenu items are selected because they are the same color as the selected top level item. All items (top or dropdown) should be the lighter color unless it's the current page.

@ryan - thanks for the option to disable toggles, but would you consider reversing it because as @bernhard and I pointed out, there are too many situations in 3rd party modules where toggles are just broken so I think the default should be checkboxes still. Also, keep in mind that the inputfield type is called "checkbox(es)", not "toggles".

Hi everyone, Tracy is now using the brand new AdminNeo project. It's been quite a rollercoaster in the Adminer world with the apparent death of Adminer, to AdminerEvo, and then AdminerNeo, then the revival of Adminer, and now AdminNeo. I have been following both Adminer and AdminNeo and deciding which one to use and while I do worry that AdminNeo might not survive given the long history of the original Adminer (now it's alive again), the theme we were using was written by the AdminNeo developer and I just can't live with any of the Adminer themes by comparison. AdminNeo also introduces a robust external login system (instead of the hack needed by Adminer), so that's where we are now. Along the way I also added styling to page IDs so you can now tell if a page is hidden, unpublished, both, or trashed: I have also added a modal viewer for images, audio, and video, along with download functionality, along with thumbnails for images. And we also finally have a nice interface for the full Adminer Process module (Setup > Adminer) when not in Standalone mode - @Robin S - I think you might actually want to use this now 😜 Please let me know if you notice any issues or have any suggestions.

Just another note on toggles - this impacts even checkboxes that are added to process modules, but in some cases the css for it is broken so it's unusable. Also, in this case the checkbox is in a table and it takes up much more space. On another topic, I find it weird that the font color for the main menu is so black (mentioned above by someone), but also that for the dropdown items, the unselected items are black whereas for the top level items, the unselected are grey and the selected is black. I also think that dropdown menus should reflect the current page by being in the darker color, but again, definitely not #000

As noted above regarding z-indexes, they also seem weird for top nav menu dropdowns. It looks like they are set to 200, but they still appear behind Tracy panels when they are set to 100. I haven't narrowed down the exact required index, but setting Tracy to 50 lets the menus dropdown over Tracy panels. In the original theme, the menus are also set to 200, so it must have something to do with the new fixed header nav messing with things.

Sorry, one more thing (for now). I think there should be separate CSS vars for the dropdown menus (vs the --masthead-background). And to re-iterate my point above about --blocks-background and --button-color. Having any css var assigned to another css var seems like a real limitation and there are many other cases where this happens.

Any chance we could have css variables for page list action buttons for color, background, border-radius and padding? I really want to go back to the look of them being buttons. Or, we need to separate the usage of --blocks-background, because at the moment it is also used for the hover color when the page list actions are displayed. I don't like the grey page background so I have changed --main-background to white, so I need to change the color of the page list actions hover but if I change that to something useful it makes all fieldsets look awful because --blocks-background is also used for those. Actually, it seems that --blocks-background is also used for some button text colors --button-color: light-dark(var(--blocks-background), var(--text-color)); - this is problematic because you can't override --blocks-background without overriding --button-color I honestly think there needs to be quite a bit of tweaking of the css variables to make things usable.

Thanks everyone for the work on this! A couple of issues I noticed right away: Tab indicator not positioned correctly. Add new button padding (Repeater Matrix) I also really need checkboxes back - toggles don't work en masse and I also heavily rely on https://github.com/baumrock/RockAdminTweaks/tree/main/tweaks/Inputfields/CheckAllCheckboxes for being able to quickly check all checkboxes. This came from AOS originally, but I ported over to RockAdminTweaks.

I haven't comprehended this is detail but in case it has any impact on the issue or @ryan's recent fix, please note this code in Tracy: https://github.com/adrianbj/TracyDebugger/blob/ae38175fe29fc7076dfa269145de98667cce76c7/TracyDebugger.module.php#L963-L966