New blog: Admin theme redesign

[ryan]

This week ProcessWire has an awesome new admin design thanks to the work of @diogo and @jploch of KONKAT Studio. You can get it now on ProcessWire’s dev branch! Read the latest blog post for details, screenshots, Q&A with the designers, and more:

https://processwire.com/blog/posts/new-processwire-admin-redesign/

[PWaddict]

@ryan On ProcessWireUpgradeCheck module I'm getting a 500 Internal Server Error and I can ONLY see the updates for the PW dev and master version. No info about the 3rd-party modules.

[wbmnfktr]

YES!
I hoped/was whishing for a collab like this one with @diogo and @jploch.
That's such a perfect match. Already love it without even having seen a screen yet.

I can only imagine what's coming next. 👏

[ryan]

@PWaddict Yeah I'm seeing the same. I'm not where I can debug it right now, but will hopefully by tomorrow. It may just be that something needs a reboot. 

[Mikie]

Nice to see movement in this space!

One suggestion would be to add separate light / dark mode config for main colour, otherwise there will always be accessibility issues with contrast for buttons etc in one or both of light / dark mode.

[maximus]

[szabesz]

"The masthead, primary navigation and search are now always available, fixed to the top of the window."

I've been longing for this for 10 years. Thanks to those who made it a reality!

Another great productivity booster is this: https://processwire.com/modules/admin-helper-links/

Could you guys please implement this for this "new theme"?

Edited May 10 by szabesz
typo

[Mikel]

Thank you for the huge amount of work put into the new AdminTheme style! After playing with it in different scenarios and PW installations we find ourselves always switching back to the „original“ style of the backend, wishing we could also have the fixed navigation here... is there a simpler way of doing this without rebuilding the original styles in the new theme?

Please don´t get me wrong, we appreciate many of the design decisions made, but overall the typo and colors of the original theme are more suitable for all of us. ("we" --> a design agency in Vienna, Austria. We build client projects with PW since 2012)

[bernhard]

Hey @ryan @diogo @jploch thx for your work on this!

I have some questions:

1) UIkit notifications seem to not use the theme's styling:

1.b) Is there a reason why primary buttons are black and not in the primary color?

2) Could you please add an option to make the button's border radius customisable?

3) Could you please add an option to make all input's border radius customisable?

Ideally both would use the same setting by default but could be also set differently. This was one of the changes proposed by @Chris-PW when we were working on a new admin style and I think it makes sense to have everything that can take user input (<input> <textarea> <button> etc) have some rounded borders. We already have lots of lots of lines in the admin to help with grouping content, wrapping inputfields etc. and all those lines add up. Having all clickable elements look slightly different from everything else (but identical on their own) helps a lot in my opinion.

4) Is there a reason why <select>s have white background and regular inputs have a light grey?

5) Is there an option to disable the new toggles and get back to good old checkboxes? See https://axesslab.com/toggles-suck/

Even if one prefered toggles over checkboxes in general, I think there are some situations where they are absolutely counterproductive, for example here:

6) I tried do add the file site/templates/admin.css with the following content:

:root {
  --border-color: var(--main-background);
  /* --inputs-background: var(--blocks-background); */
}

I then put both "site/templates/admin.css" and "/site/templates/admin.css" in the AdminThemeUikit config for "Custom CSS File", but it had no effect. Strangely when I put "wire/modules/AdminTheme/AdminThemeUikit/themes/default/examples/borderless.css" it worked!

I also tried with this content:

div {
  border: 1px solid red;
}

Still no luck.

7) Would it be possible to have the admin theme load one CSS file by default. Similar to what we know from /site/ready.php it is often so much nicer to just place a file in a predefined location than to have to update a module's config somewhere.

This might not sound like a lot to do, but when working with migrations and automated deployment workflows these things get more tedious, because you can't simply change the module config, you have to migrate these changes and then commit them. Also a predefined location reduces the risk of typos, of missing leading slashes, etc.

8 ) Where to report bugs/issues/requests? In the PW issues repo? Here in this thread? Somewhere else?

9) When editing a page in a modal (just add &modal=1 to any page edit form) there is a lot of unused space at the top:

10) On the page tree I think it is ok to have the action items text-only in this case (though I'd probably prefer the old style here):

But on the trash we have some text followed by the action buttons and there this text-only style is really not good imho:

11) +1 for this:

On 5/10/2025 at 1:18 AM, Mikie said:

One suggestion would be to add separate light / dark mode config for main colour, otherwise there will always be accessibility issues with contrast for buttons etc in one or both of light / dark mode.

I'm using #0a2b99 for the primary color and links are near to not readable in dark mode:

12) @ryan As you can see in the screenshot above when using dark mode I'd probably want to change the logo to a white version. If that image were an <svg> this would be quite easy to do with CSS, but at the moment it is using <img src='...'>

Could you probably update the theme to make it inject SVG markup for the logo directly?

13) Regular UIkit <div class='uk-alert'> are not styled properly (they use the default uikit blueish), which is even worse in dark mode:

Thx!

[ryan]

 

Quote

we find ourselves always switching back to the „original“ style of the backend, wishing we could also have the fixed navigation here... is there a simpler way of doing this without rebuilding the original styles in the new theme?

@Mikel This is what the two custom CSS configuration options are for, so that you can tailor to your preferences, and especially with regard to colors. The original Uikit theme color set was inherited from the Reno admin theme. I also like that color theme, but it's not great for having a customizable main color or a dark mode. However, it's likely easy to get to, probably just a matter of adjusting a few CSS variables with one of the custom CSS options. The hope is that others will come up with custom color themes (such as a Reno color set) and post them to share. 

Quote

1) UIkit notifications seem to not use the theme's styling:

@bernhard Thanks for all the feedback! How do I duplicate those notifications? I don't recognize what I'm seeing in your screenshot. I tried ProcessWire.alert() and ProcessWire.confirm() but both are styling correctly.

Quote

1.b) Is there a reason why primary buttons are black and not in the primary color?

I'm not sure but I think that was what the designers preferred for the light theme. I think it looks good too, but I'm sure main colored buttons could also work well. 

Quote

2) Could you please add an option to make the button's border radius customisable?
3) Could you please add an option to make all input's border radius customisable?

Either of the custom CSS options should enable this. 

Quote

...everything that can take user input (<input> <textarea> <button> etc) have some rounded borders.

I think this is also likely a good use case for the custom CSS options. 

Quote

 Is there a reason why <select>s have white background and regular inputs have a light grey?

I think it's likely a subjective decision to have greater contrast between selects and text inputs on the light theme, to avoid one looking like the other. But it seems like it could work either way, as on the dark theme they are more similar in appearance. 

Quote

 Is there an option to disable the new toggles and get back to good old checkboxes? 

Not yet, but it's been requested a couple of times, so I'm guessing we'll likely add as an option. I do not agree that toggles suck. But I agree with you that there are specific instances where a regular checkbox would be preferable, like any kind of one time action or confirmation (deleting something, etc.). So it makes sense to me that that it should be something you can turn on/off.

Quote

I tried do add the file site/templates/admin.css with the following content:

Just tried, but it works for me. Are you missing the leading "/" before "site/", i.e. "/site/"  ?

Quote

Would it be possible to have the admin theme load one CSS file by default. Similar to what we know from /site/ready.php it is often so much nicer to just place a file in a predefined location than to have to update a module's config somewhere.

I don't usually like having to do extra file_exists() checks, but maybe it makes sense here. Perhaps the admin custom CSS file could be pre-populated with a /site/templates/styles/admin.css or something like that so that it would be the standard it uses, unless you opt to change it to something else. 

Quote

Where to report bugs/issues/requests? In the PW issues repo? Here in this thread? Somewhere else?

Probably the PW issues repo for now, unless Diogo and Jan would prefer they go in a separate repo, I will ask them when we speak next. 

Quote

But on the trash we have some text followed by the action buttons and there this text-only style is really not good imho:

I see what you mean, the text and the link are too similar here when the trash is open and you hover it.

Quote

I'm using #0a2b99 for the primary color and links are near to not readable in dark mode:

Why choose a color that isn't readable? For anything that has customizable colors, there's a responsibility to choose an appropriate color. In this case, unless you disable dark mode, you'll want to choose a color that works for both. The three predefined color options are there as good examples. Maybe we'll add separate main color choices for light and dark mode, I'm not sure, but it will still be the responsibility of the person configuring the color to choose something that is legible. 

Quote

As you can see in the screenshot above when using dark mode I'd probably want to change the logo to a white version.

I'd skip the white version, your logo looks great in dark mode. 

Quote

Could you probably update the theme to make it inject SVG markup for the logo directly?

Sure. We're already doing it for the PW logo, so makes sense we should for custom SVG logos as well.

Quote

Regular UIkit <div class='uk-alert'> are not styled properly (they use the default uikit blueish), which is even worse in dark mode:

Most likely it's something that PW doesn't use, so it isn't styled, but I'm sure it can be. I think we do use uk-alert boxes, but always of a type like "primary" or "warning" or "danger", etc. So maybe we just need to add a style for alerts that aren't of a specific type. 

Since PW has not had a dark mode before, I'm sure there will be modules that aren't ready for it, including some of my own too. But hopefully there won't be a lot of such cases, and most should be easy to resolve. 

[Mikel]

3 hours ago, ryan said:

This is what the two custom CSS configuration options are for, so that you can tailor to your preferences, and especially with regard to colors. The original Uikit theme color set was inherited from the Reno admin theme. I also like that color theme, but it's not great for having a customizable main color or a dark mode. However, it's likely easy to get to, probably just a matter of adjusting a few CSS variables with one of the custom CSS options. The hope is that others will come up with custom color themes (such as a Reno color set) and post them to share. 

That´s what we thought, Ryan. As we really do not care for dark modes, we will return to changing the _masthead.php of UIKit module with 

<div id="pw-mastheads" uk-sticky="sel-target: .uk-navbar-container; cls-active: uk-navbar-sticky">

and stick with "classic" style. Works flawless. But, anyway: Congratulations for the new Admin style, a lot of good stuff going on!

[adrian]

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.

[cb2004]

Been testing this and loving it so far. A website is never finished, neither is an admin theme. Keep up the great work, I will do some thorough testing closer to a master release, but everything that needs looking at seems minor at present. 

[elabx]

Hi everyone! And thanks for the great work in the new admin, I kind of also agree on the checkboxes!

I'd skip the white version, your logo looks great in dark mode. 

I'd also vote on the customization of the logo! I think @bernhard's logo on the screenshot is just a nice coincidence, but I'd say most of the times it wont work out of the box?

Been testing it a little bit my block building setup using repeater matrix ,also nested repeaters, and at first glance I kinda miss the depth the repeaters added with a slightly darker background color. Will report back with more concrete examples!

[adrian]

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.

[szabesz]

12 hours ago, adrian said:

I also really need checkboxes back

I also think there are use cases for both classic checkboxes and toggle switches. Both might work well in the same context, but there are also situations where they are not interchangeable. This is all about UX ;)

[adrian]

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.

[diogo]

Hi all 👋

Just dropping in to thank everyone for your input and to acknowledge that I read through the thread. I don't have time to respond at the moment, but will do as soon as possible.

[bernhard]

19 hours ago, ryan said:

Quote

1) UIkit notifications seem to not use the theme's styling:

@bernhard Thanks for all the feedback! How do I duplicate those notifications? I don't recognize what I'm seeing in your screenshot. I tried ProcessWire.alert() and ProcessWire.confirm() but both are styling correctly.

Hi @ryan these are just regular UIkit notifications from the Notification component: https://getuikit.com/docs/notification - Just copy this into the console of your devtools:

UIkit.notification({
    message: 'my-message!',
    status: 'primary',
    pos: 'top-right',
    timeout: 5000
});
UIkit.notification({message: 'Danger message…', status: 'danger'});

 

19 hours ago, ryan said:

Quote

2) Could you please add an option to make the button's border radius customisable?
3) Could you please add an option to make all input's border radius customisable?

Either of the custom CSS options should enable this. 

Ryan, this could be the answer to all of my/our questions. The theme was marketed as being easily customisable by changing just a few css variables and I think you did a good job, but as some of the comments show the new style might be missing some. Of course anybody can look into the 3100+ lines CSS file and find the right spot to tweak. But there might be several spots that one has to override. It might be necessary to add !important to make it work. And one might forget about edge cases like RepeaterMatrix, RockPageBuilder, whatsoever. I think some main design decisions should be taken care of the style, not every developer reinventing the wheel over and over again and fixing the same issues over and over again.

For the buttons it seems to be quite easy. We'd just need a CSS variable for this:

.ui-button,
.uk-button,
.ui-button.ui-state-default,
.ui-button.ui-state-hover,
.pw .tox-dialog .tox-button,
.pw .vex-dialog-button,
.pw .vex.vex-theme-default .vex-dialog-button {
	border-radius: 9px;
}

Line 2649 of admin.css

19 hours ago, ryan said:

Quote

...everything that can take user input (<input> <textarea> <button> etc) have some rounded borders.

I think this is also likely a good use case for the custom CSS options. 

I disagree for the reasons mentioned above and I ask you 3 guys to rethink that to offer something like this:

--border-radius: 10px;
--input-border-radius: var(--border-radius);
--button-border-radius: var(--border-radius);

This means if someone wants all input/button elements have the same border radius, let's say 20px, then all he/she has to do is this:

--border-radius: 20px;

And if he/she wanted something like the style currently uses it would be something like this:

--input-border-radius: 0;
--button-border-radius: 99999px;

 

19 hours ago, ryan said:

Quote

I tried do add the file site/templates/admin.css with the following content:

Just tried, but it works for me. Are you missing the leading "/" before "site/", i.e. "/site/"  ?

Thx! Sorry, my bad! I forgot I had a very restrictive .htaccess in place that blocked access to that css file 🙂 I tried both site and /site and both did not work. But now both versions do!

19 hours ago, ryan said:

Quote

Would it be possible to have the admin theme load one CSS file by default. Similar to what we know from /site/ready.php it is often so much nicer to just place a file in a predefined location than to have to update a module's config somewhere.

I don't usually like having to do extra file_exists() checks, but maybe it makes sense here. Perhaps the admin custom CSS file could be pre-populated with a /site/templates/styles/admin.css or something like that so that it would be the standard it uses, unless you opt to change it to something else. 

Hmmm. Good point. Not sure. I think it would make things easier to have a common standard, like having a default /site/templates/styles/admin.css for example with just a few comments pointing to the example files at https://github.com/processwire/processwire/tree/dev/wire/modules/AdminTheme/AdminThemeUikit/themes/default/examples

---

Another problem I just realised: My login screen is always the new style. This toggle seems to have no effect? It's not .htaccess this time...

 

19 hours ago, ryan said:

Quote

I'm using #0a2b99 for the primary color and links are near to not readable in dark mode:

Why choose a color that isn't readable? For anything that has customizable colors, there's a responsibility to choose an appropriate color. In this case, unless you disable dark mode, you'll want to choose a color that works for both. The three predefined color options are there as good examples. Maybe we'll add separate main color choices for light and dark mode, I'm not sure, but it will still be the responsibility of the person configuring the color to choose something that is legible. 

Because it's the primary color of the CI. That's the whole point for having the primary color customisable, no? The backend should match the main color of the company and that's often a color that is dark to have a good contrast to white. It's not a solution to simply choose another color to make it work on dark mode 😞 

19 hours ago, ryan said:

Quote

Could you probably update the theme to make it inject SVG markup for the logo directly?

Sure. We're already doing it for the PW logo, so makes sense we should for custom SVG logos as well.

Great, thx!

19 hours ago, ryan said:

Quote

Regular UIkit <div class='uk-alert'> are not styled properly (they use the default uikit blueish), which is even worse in dark mode:

Most likely it's something that PW doesn't use, so it isn't styled, but I'm sure it can be. I think we do use uk-alert boxes, but always of a type like "primary" or "warning" or "danger", etc. So maybe we just need to add a style for alerts that aren't of a specific type. 

Thx. This is the code that it uses:

<div class="uk-alert">
  ATTENTION - RockMigrations is installed on this system. You can apply changes in the GUI as usual but if any settings are set via code in a migration file they will be overwritten on the next migration cycle!
</div>

 

[d'Hinnisdaël]

Separate color pickers for main color (light) and main color (dark) sound like a good solution to allow proper branding while still being accessible.

Also, I would like to second the request for adding CSS variables for the border radius. There are some great additions in the new theme to make things more customizable, but to call it truly "customizable", it should offer the possibility of changing the border radius on buttons and inputs. The current look (very round buttons + completely square inputs) is a bit peculiar, but that's okay as long as we get a way of tuning things ourselves 🙂

[eelkenet]

Thanks for all the work! I can see clear improvements on lots of places.

A couple of things that I bumped into, some of which have been mentioned already:

• We not just need separate color pickers for light and dark themes, but also logo url fields (I have a white logo which now disappears completely in light mode)
• Primary buttons should be in the primary color, which is not the same as black!  I find these very unclear and even distracting when quickly scanning the page.
• Return or optionally enable regular checkboxes, please.
• Accessibility is low. Low hanging fruit: make sure you get :focus, :focus-within working, right now its impossibly hard to see when a 'toggle' or close button is selected. Use https://wave.webaim.org/ to check the rest. (this is a tip for all reading this)
• Selected icons (in edit template / field) disappears from the list:
  

 

Again thanks for the work and looking forward to whats next!

[AndZyk]

First of all thank you to everyone involved in making this new admin theme. This is a really good looking admin theme. 😀

I have not tested it very well, but one small issue I noticed:

When you tried to assign a tag to a field, there seems to be an z-index issue with the autocomplete results:

Keep up the great work. 👏

Regards, Andreas

[bernhard]

53 minutes ago, AndZyk said:

When you tried to assign a tag to a field, there seems to be an z-index issue with the autocomplete results:

Same problem with the EditFieldLinks tweak https://github.com/baumrock/RockAdminTweaks/tree/main/tweaks/PageEdit/EditFieldLinks

Do you think these issues can be fixed in the admin style or do we have to fix those issues in the affected modules?

[BrendonKoz]

If, by chance, oddities discovered during the creation of the template - (CSS et al), testing, and reports of usage - could be included in a document by the theme authors somewhere for future work (next iteration of a template?), that would be amazing. Absolutely outside the scope, but likely appreciated by others, for sure! 🙂 Some of the issues will be module-specific, but issues with core, or (more) "commonly" used modules (ex: InputfieldIcon) might be worthwhile to be noted there... Just a thought, after reading all of the feedback thus far.

On 5/12/2025 at 10:07 AM, ryan said:

Why choose a color that isn't readable? For anything that has customizable colors, there's a responsibility to choose an appropriate color. In this case, unless you disable dark mode, you'll want to choose a color that works for both. The three predefined color options are there as good examples. Maybe we'll add separate main color choices for light and dark mode, I'm not sure, but it will still be the responsibility of the person configuring the color to choose something that is legible. 

The unfortunate thing here is that once you offer a light/dark mode, prior colors that worked in whatever theme was used previously (in the PW backend, this would essentially be a light theme, by default) just might not work -- and they could have been set as a primary color from a prior theme customization, or even as bernhard said, the company's primary color. For my company's primary color, it is a sort of putrid green (#649a44). Even in light mode it doesn't work well, but is terribly difficult to read in dark mode (when I was developing a light/dark mode for the frontend). I had to use color mode saturation/lightness adjustments to make it appear as though I'm using the same color, while in effect they're fairly significantly different colors (but visually, to the eye, looks right-on-target). This isn't something that can be done by simply assigning a single color. Even with CSS color function adjustments (lightness, saturation, lab colors, etc.) it's a bit of a "magic number" game.

BTW - related 👉 Safari: How to have the browser pick a contrasting color automatically via CSS (🤞 for other browsers to implement this too)

That said, the custom CSS file override option still works just fine. Since this theme does offer customizations though, the determination would mostly be, "Where does it make sense to offer a customization right in the theme, and where should the dev take the extra effort themselves?" Primary color, I opine, would likely be a configuration option that would often need to be customized further for light/dark compatibility, and therefore makes sense to offer the option in the theme.

Similarly for the logo image used in the backend. Just because we may think a certain logo image is fine as-is (ex: bernhard's logo), the client might not, but may also demand it. It's definitely something we can adjust, either with admin JS and/or CSS, but if it may be a common request or need due to the light/dark mode offering, it also seems to make sense to offer the option here (imho).

Love seeing the work, excitement, and feedback thus far. I haven't had a chance to give this a whirl yet, but appreciate the massive amount of work that's gone into it, and the early testers that are enthusiastically offering their feedback!! This community is so awesome.

P.S. - Is there any preferred way that we might offer any sort of assistance with the theme? Too many "cooks in the kitchen" can cause confusion, but I also know the effort was voluntary and it's easy to identify potential issues, harder to fix, and/or find the time to fix.

[adrian]

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.