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.

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?

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?

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. The network response is: {"status":"ok","adminDarkMode":0} so it appears to be ok and no JS errors.

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

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.

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.