New blog: Admin theme redesign

[markus-th]

On 6/7/2025 at 10:54 AM, markus-th said:

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

 

Unfortunately, it still doesn't work.

@diogo Not such an easy fix after all?

[diogo]

@markus-th I had this on my list, but somehow didn't get to doing it. Yes, it should be an easy fix.

[AndZyk]

Is it possible to change the color of links in the new admin theme?
I have set a new main color in the module settings and in the admin.css with --pw-main-color, like recommended.

But the links of modules or the login screen have still this styling:

a, .uk-link {
    color: #e83561;
    text-decoration: none;
    cursor: pointer;
}

There seems to be no CSS variable. Is this intentional?

Regards, Andreas

[adrian]

@AndZyk @ryan @diogo - also reported here: https://github.com/processwire/processwire-issues/issues/2110

[nbcommunication]

@ryan,

You'd mentioned at some point that existing installs could retain the old theme and perhaps users prompted to update to the new one. At the moment if I upgrade an existing site to the dev branch, the new theme is enabled by default. This breaks any custom TinyMCE styling as the new theme overrides it.

Are you planning to implement this prior to the next master version?

Ideally for us, given we have several hundred sites which we update to the latest master when it is available, nothing would change for the users. We could then turn on recommending a theme upgrade on a per site basis, or if we choose to, force the upgrade on the users.

Cheers,

Chris

[Peter Knight]

I’m late to the Konkat theme but having used it recently, I really like it. It seems without any major UI adjustments that it’s just a nicer experience and if I’m not imagining things, a little faster? 

Nice job @diogo and everyone.

If you’re open to feedback, can I add the following.

First, the main grey background is a touch too dark for my personal preference, and interestingly a client mentioned the same, describing it as too industrial. They’re marketing. They like their UI to be friendly and approachable.

The issue is a practical one: a heavy base grey compresses the tonal range before we placed a single element on the page. To make cards or panels register visually at all, you have to resort to strong contrast because a nice, subtle layering just disappears.

Alternatively, with a near-white base you have room to step up gradually, building visual hierarchy through gentle increments. A heavy base leaves nowhere to go without things feeling either too dark or muddy. This isn’t a design lecture… just trying to pinpoint the particular issue.

And I agree it only really affects module builders but interestingly, a client recently remarked that they found it a little industrial and unwelcoming compared to the previous theme.

Next up, buttons…

I find that buttons with 100% border radius never appear as truly aligned as flat side buttons with a subtle border radius. We switched to rounded buttons years ago on an enterprise project, everyone loved the change ( yay, jelly beans!) and now we’re going back to traditional 4px border radius throughout because everything just looks better aligned.

It seems the beauty of using the css vars is I can easily tweak these things myself but wondered if at least the grey background was under consideration?

Otherwise and honestly, it’s a great theme and I’m looking forward to using it more. 

 

[Peter Knight]

Following up on my earlier comment about the background colour - here's a quick side-by-side to illustrate (bottom of post).

The proposed change is simple: lighten --pw-main-background from #eee to #f5f5f5 (a shift of less than 3%)

Three reasons it's worth considering:

• #f5f5f5 is already the background colour used on processwire.com, so it brings the admin in line with the brand.
• It feels noticeably lighter and less industrial in practice. A few of my clients have used that exact wording.
• For module builders, it opens up more tonal room to work with subtle layering and contrast.

I know it's not quite a single variable change. Borders and dividers calibrated against #eee might need a look too, but it's pretty close.

You'll see below that it's just a whisper lighter. But in practice users get brand consistency, general lightness and approachability.

In practical terms, this is involves transitioning from 93% to 96% white.

Copying in @diogo in case this is useful feedback as the theme evolves and celebrates its birthday around now. And finally, in case it needs to be said, the KonKat theme is clean, considered and feels like a proper step forward for the ProcessWire admin. It's a really thoughtful piece of work by people who sweat the details, so I hope this feedback can be taken in that spirit.

 

[adrian]

I agree with @Peter Knight - I set --pw-main-background: #fbfbfb; on all my sites, but I am sure#f5f5f5 would also be a better default.

[MrSnoozles]

I would prefer #fbfbfb; too. That's what I change the background color to on my sites too.

Edited yesterday at 10:05 AM by MrSnoozles

[Peter Knight]

Interesting that you both chose fbfbfb. 
Do you find there's enough contrast between fbfbfb and white?

I think it might be lost on most monitors, but that's simply a guess.
In the attached, I have removed the login panels grey border to help visualise both fbfbfb and f5f5f5 against a white.

[adrian]

42 minutes ago, Peter Knight said:

I have removed the login panels grey border

But don't all elements have the grey border which helps to separate them from the background - I think that is why #fbfbfb works.

[Peter Knight]

44 minutes ago, adrian said:

But don't all elements have the grey border which helps to separate them from the background - I think that is why #fbfbfb works.

 

Yep, they do. That was more a personal preference. IE a grey that is light enough to be subtle but dark enough to sit on a white without needing a border.

[BrendonKoz]

Although a wild guess, having looked at the example proposed images, I'm thinking the darker background color for the admin theme (over the PW homepage for branding) was chosen to better highlight the distinction between input elements' target areas compared to empty/white space. It's a noticeable visual distinction, at least on my monitor.

[jploch]

@Peter Knight The darker color is intentional, there are two reasons why we (Diogo and me) decided for the darker grey:

1.  Contrast: Bringing more focus to the white areas even on screens that have bad contrast/color settings. This is especially helpful when input fields are offset from one another; it makes it easier to distinguish between the fields. It also helps to seperate the navigation and content area. The white hover on the page tree is also benefiting from the darker grey. Also like @BrendonKoz says it helps to seperate the inputs from the background. While the borders already enforce this contrast, I feel like the combination of border and background is what makes it stand out more.
2. When putting screenshots from the admin on the PW website we want them to have a different background color so the image stands out better. This is why we choose a lighter background color for the website. While the image usually has a border, the background still improves the contrast, so the two don’t blend together as much.

All in all, a lighter color would work too, and I certainly understand that some people might find the grey a bit too “grey.” However, I think the darker grey is a more functional default.

[adrian]

51 minutes ago, jploch said:

The white hover on the page tree is also benefiting from the darker grey

This is exactly why I tweaked mine to look like this with the top/bottom border (box-shadow) on hover. You get the definition you need with a nicer grey (IMO).

with:

.PageList .PageListItem:hover {
  box-shadow:
    inset 0 0.5px 0 0 #ccc,
    inset 0 -0.5px 0 0 #ccc;
    border-radius: 0 !important;
}

 

[Peter Knight]

1 hour ago, jploch said:

@Peter Knight The darker color is intentional, there are two reasons why we (Diogo and me) decided for the darker grey:

1.  Contrast: Bringing more focus to the white areas even on screens that have bad contrast/color settings. This is especially helpful when input fields are offset from one another; it makes it easier to distinguish between the fields. It also helps to seperate the navigation and content area. The white hover on the page tree is also benefiting from the darker grey. Also like @BrendonKoz says it helps to seperate the inputs from the background. While the borders already enforce this contrast, I feel like the combination of border and background is what makes it stand out more.
2. When putting screenshots from the admin on the PW website we want them to have a different background color so the image stands out better. This is why we choose a lighter background color for the website. While the image usually has a border, the background still improves the contrast, so the two don’t blend together as much.

All in all, a lighter color would work too, and I certainly understand that some people might find the grey a bit too “grey.” However, I think the darker grey is a more functional default.

Hey @jploch
Thanks for jumping in and providing your design thinking. All solid reasons.