Leaderboard

From the start, I asked myself why I was somehow not completely satisfied with the display of the checkboxes as switches: We actually use switches quite heavily in some of our webapps, so I looked at the examples and therefore suggest making the “inactive” status brighter. This makes it easier to recognize the status of the checkbox. Below is an example of iOS switches. I also find it problematic when the theme color is red: To me, this makes the checkbox appear “false” even though it is “true”. Making the “unchecked” state lighter in color, also would help in this case. Below is an example of one of our web apps. There we chose to give both states a color: That makes it easy to understand the state of the toggle (checkbox).

There is a free online event on ::: June 17, 2025 ::: 13:30–18:30 CET/CEST ::: 07:30–12:30 EST/EDT ::: 11:30–16:30 UTC https://lp.jetbrains.com/phpverse-2025/ @ryan what about taking part as a speaker on such events to make PW more popular?

I absolutely love URL hooks and have used them extensively since they were introduced. I don't know if I'm alone in this, but the only thing that bugs me about how they work is when they conflict with URL segments in templates (especially if you have URL segments enabled on the home page, e.g in an SPA type scenario). IMO it would be great if URL hooks could have an extra bool parameter to set whether or not they take precedence over URL segments. E.g. $wire->addHook('/stripe/{route}', function($event) { switch ($event->route) { //CASES GO HERE default: throw new Wire404Exception(); return; } }, true); //<------ option here A number of times I've run into scenarios that require workarounds (or manually naming URL segments) to avoid conflict with home pages with URL segments which wouldn't be necessary if we could just instruct the hook to kick in before URL segments. Obviously this would need to be opt-in and at developer risk. I hate to be that guy that's always tagging you into threads @ryan.... but I'm guessing I may be overlooking a logical reason why this is a bad idea or that this doesn't exist?!

😄 Yes, that would be not so nice. But we created the app (and the toggles) for a small user group with no color blind members and the mission was to visualize the states of many projects and subtasks at one glance. The green/red scheme achieved the best results in our test settings, so we went with that. 😉👍 But have a look for yourself: https://frameless.at/en/case-studies/real-estate-marketing/

Absolutely! Had the problem several times and it just hit me again 🙂

Thanks 🙂 i will try your suggestions and let you know how it goes.

Skeumorphism is so back! Ask Airbnb crew! /j

We just discovered something funny: The design of the column width slider handle is from a galaxy far, far away, isn´t it? 😉

@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? Makes sense to me. Ah okay, I see it now. Adding to our list of updates. @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.

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

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:

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

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

Thx for adding that detail! Considering that Ryan mentioned the nature of the new style being like extending PHP classes, I wonder why settings of the default theme are part of the AdminThemeUikit module. Visible or not - technically they are built into AdminThemeUikit, which feels strange. I'd expect AdminStyleKonkat to be a separate module and therefore all dedicated settings would be on the module config of AdminStyleKonkat. Again, this module could still be part of the core and it could still be turned on by default. At least for new installations - I still think it would be good to not change the style with the upgrade without asking. Settings that apply to all styles on the other hand would be part of the module config of AdminThemeUikit. For example the CMD+K hotkey is independent of the style and thus would belong on the config screen of AdminThemeUikit, which would mean this feature can be used by any style. I think this would be a very clear setup that clearly separates the responsibilities of the THEME and the STYLE and this would very well reflect what Ryan mentioned as strategy.

@jploch sorry for all the posts, but as you can tell I'm spending a lot of time in the PW backend, so I report things as they pop up. Take your time to evaluate them and to respond. Expanding on this suggestion it confuses me a lot to see this part of the GUI inside of AdminThemeUikit: I think it would make much more sense if these settings were defined on the settings page of AdminStyleKonkat, as it makes no sense to me to allow darkmode settings on AdminThemeUikit if I'm using AdminStyleRock which does not offer a darkmode. @ryan I hope this is considered to be constructive feedback and I hope it helps you to understand why I got a very different impression of what this new "theme" is or should be.

Thank you. Thank you.

Because the code of the module would be identical to AdminThemeUikit, and the new theme is still all Uikit. I want AdminThemeUikit to remain PW’s main admin theme, just with more options for the appearance of it; especially one that helps us attract new users. Were it a 3rd party thing for people to install then a separate module would still make sense. But for this case, it would just be unnecessary overhead. I forgot to respond to this one and I'd consider it important. It sounds like you totally misunderstood my request. I'm very much for using AdminThemeUikit and I very much support all the mentioned goals. I was just questioning why it was not built in a way that followed what we pushed to the core in 2021. And probably released as a module first, and then, when early adopters had time to test and give feedback, was merged to the core and set as the new default. I think this approach would have signalled the appropriate care and it would also have helped to identify which parts need to be part of the new theme and which parts need to be addressed in the base theme. If keeping and supporting all existing themes is a goal, then I think this approach would have best signalled this and would have had the best chance to make it happen. Take this comment for example from my rock theme: // @ryan // early stage idea // can we move those colors to the base theme (eg --pw-gray-200)? // then all styles could inherit those colors // and all module developers could rely on them. // the problem now is that modules use their own colors // often based on reno, which make the style break when // someone uses AdminStyleRock or any other style/theme You see that I even used css variables in this comment, so I'm definitely aware of their possibilities and benefits. But the more complex things get the more careful we have to be. --- I can't understand what you mean by "code would be identical to AdminThemeUikit". Just have a look at AdminStyleHello if you did not already. I built it in 2022 to propose a clean way of how to extend the base uikit theme in ProcessWire. I don't see how that would be considered to be "identical to AdminThemeUikit"? As it is not too late for anything may I ask if the current setup can be changed? Could the new theme be called "AdminStyleKonkat" and could it be built in a way that I proposed with AdminStyleHello in 2022 (or better 😄 )? I think this would help in reducing confusion about what is a theme and what is a skin and it would clearly show that all styles are just a skin on top of AdminThemeUikit and all are equally supported and the user can choose whatever he/she wants. If AdminStyleKonkat was built in that way I'm not sure whether supporting AdminStyleRock made sense, as it tackled the same goals, but I think this does not matter. I think the current situation is confusing. We have AdminThemeUikit and there we have two options. The "default" theme and the "original" theme. Then we have some themes and styles lying around somewhere in the modules directory. Like AdminThemeBoss (which is also a skin on top of AdminThemeUikit as far as I know and which seems to also tackle similar goals with having neutral colors and one primary color) or AdminStyleRock. If a user wanted to use one of these modules he had to install it as a module and then he had to go to AdminThemeUikit to select "original" theme. If he didn't do that, the style might cause problems and the user would likely think that the style is broken and can not be used. This has already happened in only two weeks of having the new theme on the dev branch: https://github.com/processwire/processwire-issues/issues/2078 I think this setup is confusing and I think the process for users is currently confusing as well. I could think of the new style being a module (AdminStyleKonkat) and any other style being the same. Being a module does not mean it can not be in the core. I don't understand that conclusion. We have many modules in the core, some of them being installed by default, some being ready to install with the click of a button. AdminThemeUikit could, for example, then pick up all modules that are installed and follow the naming convention "AdminStyle..." and list them as an option to choose from: vs.

There is a lot of talk about “design by committee,” which I also think is wrong. But nobody asked for this, not even @bernhard. I have followed his posts very closely and all I can see is that he had hoped that the community would be consulted before the design phase. And I absolutely agree with him on this point, because if wishes and ideas had been solicited beforehand, I am quite sure that this thread would have been much less emotional. Now to my “problems” I currently manage nearly 50 active ProcessWire projects, and the advance announcements of a more modern admin theme naturally raised expectations that have now turned to disappointment for me, as many of my installations run on UIKit-based custom modules that are sure to cause problems with the CSS overrides. For me, this means that all development systems will soon need to be updated to the DEV version in order to identify and address any problems. I hope to find the time soon to contribute constructively to improving the theme.

Serious question: If it's not too late for anything, then why is feedback like this not considered to be helpful? What I tried to point out is that when using UIkit like explained in their docs, then we would not have these issues at all. To change the primary color all you'd have to do is this: @global-primary-background: red; Then all primary buttons will use that color. All progressbars will use that color. All UIkit components will use that color. And any component that they might add in the future will use that color as well. Which means that any developer in the world can not only use what the core uses but anything UIkit has to offer. Framing that as "features that ProcessWire traditionally did not offer" is what I consider as not being helpful. We, on the other hand, are using thousands of overrides at the moment. Anything that Diogo didn't think of will possibly cause issues. Cause frustration or ugly fixes on our side and cause Github issues on your side and I think your time can be spent better. Seeing reno green shine through tells me that the new theme must be extending (if you don't want to call it overriding) the reno theme and not the base theme, that I carefully split apart from the reno theme in 2021 to make exactly that possible: Properly extending the base theme without applying layer by layer of overrides. Exactly like you mentioned with PHP classes. What I see in the new theme does not match what I read in your announcements and explanations, sorry. I consider that to be a very valuable feedback for anyone that is open to hearing it. Unfortunately for many reasons I got the impression that it's too late for such input. And I understand that this is a difficult situation. That's why I apologised. It does indeed not help if anybody complains about fundamental issues if it's not possible to change them. I get that and as I said I'll try to be more constructive with that situation. But please don't pretend that it's not too late for anything and that we are at an early stage in the process. This feels dishonest to me on my cost. Obviously I also do not think that micro-managing a professional designer would be helpful and that's not what I have been suggesting. I just don't see anything wrong in asking the community for input upfront. At least that's what I did with my calendar module and I think it was a very helpful and pleasant process: What features should a PW calendar module have? The community was just as great as it has always been. It does of course not mean to ask the community to decide every button's color. But it might help to reduce the risk of having blind spots. It might make the process even more creative, not less. It might help in making the community feel heard, accepted and valued. And it might even help in saving development time by cutting on features that sounded/looked cool at first but raised serious concerns in the community. And one more thing about the term "secret": You have some good evidence here. It was not my point though, and it might have been more constructive to ask me what made me feel like that than proving me wrong. I know I'm not the only one feeling like this. English is not my first language, but that sounds ironic to me and I'm not sure if it is the best time for being ironic after I apologised. I'm not sure how a user will feel when using dark mode for everything and some pages suddenly appear in light mode, but at least this means that it's no longer a go/no-go decision when somebody wants to use one of my modules, so thank you for that. Do i interpret this correctly as that darkmode is not any more considered to be experimental and is here to stay? --- @ryan please be reminded that I still very much admire what you have built and achieved. I'm sorry that you have expected a different feedback. But I hope it's ok to not only cheer if we like what we see but also raise our voice if we don't. Thx and all the best

We (Konkat) would not have taken on the task of redesigning if a larger group of people had been involved in the initial design process. And I'm sorry if anyone felt left out. We have limited time and capacity and this was the most productive way for us to work on the project. That said, we are now listening and are open to constructive feedback and bug reports. The theme is not set in stone, we are open to adjust things.

I worked as a designer for many years and learned you don’t get good results from the process you described, getting others involved upfront. There would be no point in having professional designer if it’s “design by community”. It’s important to me to get unhampered original creative thinking until the designer is happy with it. Following that, then it’s reaching out to the community, which is exactly what we are doing. I also did not see the the redesign until it was finished. I strongly believe in finding a designer you trust and then trusting them to do what they do best. Though I am thrilled with the result, it’s the first time I’ve used an admin design that felt like home to me in the same way that the original one does, and even improved upon it. But that’s the subjective aspect, we’ll all have different opinions. So that they could work without interference until they were ready to share. But also I like to build anticipation and reasons for people to visit the website. Because the code of the module would be identical to AdminThemeUikit, and the new theme is still all Uikit. I want AdminThemeUikit to remain PW’s main admin theme, just with more options for the appearance of it; especially one that helps us attract new users. Were it a 3rd party thing for people to install then a separate module would still make sense. But for this case, it would just be unnecessary overhead. This is where we are. Both you and I are early adopters that are testing and providing feedback. I still am. This is why everything is optional and the Original theme option will always be there. The dev branch is historically stable, but it’s also always been the branch where new things are introduced and tested. Nothing has been developed secretly, I’ve been writing about it every week since we started, and it’s been shared with everyone months before it will be on our main/master branch. I get the impression that you think we should micro-manage the designer, and that’s not an approach that I think is helpful. It’s not too late for anything. You are welcome to share ideas and make suggestions, that’s what I was hoping people would do. But we need constructive ideas and suggestions, and saying “this theme is fundamentally wrong” is not helpful. Diogo added what you asked for, and then this was your response. It sounds like your modules use some Uikit features that traditionally aren’t used in PW’s admin, so that became apparent when your module was used in dark mode. Since we want thorough Uikit support regardless of mode, it makes sense to me that that we should find and correct issues to account for display issues as they pop up. But you are saying it doesn’t make you feel good. Maybe this will make you feel better: I have added an option where you or your module(s) can disable dark mode entirely: $config->AdminThemeUikit(‘noDarkMode’, true); I have added an option where you or your module(s) can disable toggle style checkboxes entirely, even if someone enabled it in the AdminThemeUikit module config: $config->AdminThemeUikit(‘noTogcbx’, true); Though note that since it's been requested so much, toggle-style checkboxes are no longer a default. These options above can be set globally or on a per request basis. For instance, if you want to limit the “no dark mode” option to just when your Process module runs, then you could set it from your Process module’s execute() method. If you wanted to disable it for all requests, you could set it from an autoload module’s ready() method or directly in your /site/config.php file. Maybe it’s a language thing, but at least in English, and where I'm from, a checkbox is an option with a selected or non-selected state, that doesn’t behave like a radio. You could just as easily call a check-mark in a box a toggle, because that's also what it does, toggling something selected or not selected. A typical client is going to see checkbox and toggle as synonyms, that's my experience. If we used the term checkbox literally, then we’d be talking about paper and pens, and instead debating whether marking an “X” in the box counts as “selected” or if they have to draw a literal 2-line check mark. When we’re talking about checking on a computer, we’re talking about clicking something to select it (or deselect it). This is the style of checkboxes many of our phones use too. No need to change the description. That's my experience anyway, but I'm sure someone will reply to tell me I'm wrong because someone wrote a blog post. 🙂 Thank you.

Good point about the description. I already talked to Ryan about the toggles. We will most likely go back to regular checkboxes as the default (most seem to prefer checkboxes here).

I already got used to the new toggles. In some cases though they still feel wrong. Like in the example above. Also note that the description clearly says "Check the box next to ..." That means we'd also need to change descriptions across the admin. And we'd need to ask all the translators to update their language packs as well. I think a better approach would be to let checkboxes be checkboxes unless they are whitelisted to be converted to toggles (eg by applying a class like "pw-toggles" to any parent dom element).

Thx and sorry for the confusion. It was probably not the best example. Thank you for adding those. What I wanted... Not really. To be honest I just wanted to show why I think the approach you took with this theme is fundamentally wrong. Admittedly, some of my posts lately have not been very constructive, and I apologise for that. The thing is: As you can tell I'm heavily invested in ProcessWire. I don't understand why such fundamental decisions are taken behind closed doors. Why you (Ryan and Konkat) didn't reach out to the community upfront. I even asked Ryan to connect once he announced that someone is working on a new theme. It didn't happen. Why has it been a mystery who is working on this? It's some awesome goals you are tackling. Why not tell that upfront? Why not ask for feedback, concerns or help? Why not just create a module, like everybody else did in the past (AdminThemeBoss, AdminStyleChroma, etc.)? That early adopters can test, provide feedback and maybe think about some decisions before it is too late? I have been on the dev branch for years without any big issues that I can remember. I have always had a lot of trust in the dev branch. Ryan has always been very careful about any new additions. Very careful about not breaking any existing installations. Now that changed. Suddenly we had a new default theme. A theme, that turns checkboxes into toggles. That causes my modules to break, at least in dark mode. All of that enabled by default. And with all the context from the past I had the impression that there must not be much interest in feedback from the community - why else would you develop everything secretly? I'm sorry if that was a misinterpretation as you seem to be open to feedback. I'm just sad as it seems to be too late now for many things. Adding overrides one by one as they pop up still does not feel good, sorry. But I try to be more constructive with my feedback in the future.

When using vanilla JS you need to make sure that this header is set. This is what tells PW it's an ajax request. jQuery sets it by default, vanilla JS doesn't.