ryan

@stehlo We are beta testing this admin design on the dev branch, nothing has been released in an official version. If you feel strongly about the new design, you may prefer to stick with the main/master branch while we continue testing and optimizing the new design. I have no idea what you are talking about with regard to being unfinished or cross-browser incompatible, so if you are running into specific issues it would help if you open a GitHub issue report where you can elaborate on what it is you are observing as being unfinished or cross-browser incompatible. I've mentioned this a few times before, but we are not replacing the Original theme, we are adding another styling option for it. If you prefer the original, you should keep using it. Understand that not everyone has the same preferences here. I prefer the new design, it sounds like you prefer the original. We are not taking anything away from the current user base. Providing more options to appeal to a broader audience is not a trap. @bernhard I can't fully duplicate what you've described, using current Chrome on Android 15 (Pixel). Can you provide more details on what device you are using? I am seeing the larger margins between some pages though, it appears for any longer page titles that wrap when the page actions appear, so I can duplicate that part at least. But everything still works as expected, menus, etc., so need more detail on the parts that aren't working there.

This week I’ve bumped the dev branch version number to 3.0.249. This includes a little under 20 commits with various small updates, also including several to the new AdminThemeUikit default theme. This will likely continue for a couple more minor versions on the dev branch as we continue to optimize and improve it. See dev branch commit log for more details. I’m currently developing a portal application in ProcessWire for a client, and also working to finish up the ProcessWire.com website with the new design. We’re getting very close to having it technically ready, leaving just some writing for the homepage and features sections of the site. So the new site could be online in as soon as the end of the month. Stay tuned! Thanks for reading and have a great weekend!

That's the way I use it at least. And it's not much work because it's something usually done while setting up a field, so it's just part of the field creation process. But if you are going back to add it onto lots of existing fields, then maybe that might seem more laborious, as it would be for any field setting, but you'd only have to do it once. In addition, it's not something you'd want to do for every field. I find it useful for certain fieldsets, repeaters, etc. It's kind of a case-by-case basis. I'd forgotten about that setting in AdminThemeUikit where you can select it by Fieldtype. It appears that does not work in the new theme, so I'll have to look into that. Since adding a matrix field involves selecting a type, it's a different kind of input. But there shouldn't be a button on the matrix type at all, so it's most likely a new theme bug to figure out.

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

@adrian Interesting, I've been liking the white background that appears when you hover. The Original theme uses horizontal lines instead, so I thought the white background that only appears on hover was a better alternative, while still creating a strong visual row for the current hovered page. But if you don't care for that look, making the whole background white like you did in the page list seems to work well too. I like your new version much better too. It looks quite good, and easy to read as well. Yes, I've been trying to compile a list of things like this. But if it's something that NOT visible in regular usage, if possible, please post in the GitHub issues too so that we have instructions on how to reproduce. Though this one may already be there. Okay I will make note of this. And we're talking about the dropdowns that appear on submit buttons, and the Add New button in the page list, correct? (since the masthead dropdowns already have variables). How do I reproduce that one? This is how the repeater add-new button looks on mine: and this is how my file upload buttons look: @Mikel Thanks for reporting the small bugs, I hadn't see those yet, will add them to our list.

@adrian I'll read and reply in more detail later but that turned out nicely! It looks great

@adrian I fully support adding whatever CSS vars Diogo and Jan want to add. But I’d hate to throw out the idea of using anything but root-level vars. They seem very powerful to me and a major benefit of using these CSS properties in the first place. I mention it just because my eyes are struggling with it in the screenshots and video above. Especially the white-on-green text. But if the company is used to that usage then I’m sure they’ll like seeing it in their admin either way. I'm not sure. I’ve not had that come up yet, so can’t really well speak to it. But I’m not opposed to it. While very customizable, this admin theme is also something that’s been designed. If “anything goes” and “anywhere” in terms of colors, it’s more of a blank canvas than a professionally designed theme. I don’t think this theme was intended as a blank canvas. So there have to be some constraints in place. Making some things customizable, where planned for by the designers, is great. But other things, like rethinking the foundation of a slightly off-white (or off-black) body background might be going too far, because it changes the whole balance of it. It appears to me the editing tools (Inputfields, etc.) are designed with the idea that they won’t share an identical background color as the body. So if you go pure-white or pure-black with the body background, I agree that it may be problematic. It may be that they can add more CSS vars, but it might also be that it goes outside the boundaries of how the design is supposed to work. But I’m not the designer, so I’m kind of speculating and might be wrong. Maybe so. But I will say that as someone new to CSS variables, it’s been refreshingly easy to change anything I need to with what we’ve already got. There hasn’t been any real fiddling, and the affected markup is not likely to ever change in terms of how it would be identified with CSS selectors. So I'm just trying to say that I think we're already in quite a good spot, being able to do stuff I hadn't thought possible before. But I'm not saying that we should stop there. There's always room for making things better and better, at least where the resources allow.

@adrian I tried a few times to duplicate this but not having any luck. If there are more specific steps you can outline to reproduce it, please let me know. But to me it sounds like maybe the ajax request that saves the color mode changes is failing. Check your browser tools network tab, it may be that there's some PHP or JS error preventing it from completing its job.

@adrian Only if you set your body background color to the same color (white). Those menus will blend right into the background if you do that. For the light theme I'd suggest having a light, but not pure-white background. Likewise, for the dark theme, a dark, but not pure black background. Unless you make your body background pure white or pure black, you aren't going to run into that issue. An alternative would be to target those dropdowns with a different color, but if it were me, I'd focus on the body background color instead because I think there are more visual benefits for doing that with this theme. I'm still learning how to use CSS vars, but this seems to work for me. Basically, if the element has pw-dropdown-menu class, then I set the variables to use different colors, so that the visible primary nav at the top uses different colors than the dropdown nav that appears. I'm just using boring #ccc and #333 as example colors for the dropdown, but I'm sure you can come up with better colors. :root { --masthead-background: var(--main-color); --masthead-active-color: white; --masthead-text-color: rgba(255,255,255,0.8); --masthead-border-color: var(--main-background); --masthead-logo-color: white; --masthead-input-background: var(--masthead-background); --masthead-input-color: var(--masthead-active-color); --masthead-input-border: var(--masthead-text-color); --menu-item-backgroud-hover: rgba(255,255,255,0.25); .pw-dropdown-menu { --masthead-background: #ccc; --masthead-active-color: #000; --masthead-text-color: rgba(0,0,0,0.8); --masthead-input-background: #ccc; --masthead-input-color: #333; --masthead-input-border: #333; } } I think that main color (pea green?) is probably not a great choice because it's not dark, nor is it light. It's right in between. So it seems like it's always going to have contrast issues, especially when text is involved. I'd suggest going a little darker with it so that it falls more in an accessible color range. Btw, I don't know if that background in your screenshot is supposed to be blue or not. I'll check with Diogo and Jan on that.

What are you suggesting with the question, that we should drop dark mode? But to answer your question, I would say the same thing you'd do in any issue situation, report the issue. But by the time this is on the main/master branch, I don't think there will be any remaining concerns about dark mode. In any case, we already have options for disabling dark mode in the module configuration, in your /site/config.php file, or dynamically at runtime, enabling you to disable dark mode entirely, or just in specific cases. It seems like we already have a lot of options for those that aren't keen on dark mode.

@adrian I tried this but didn't run into any side-effects, it seems to work really well. I based it off one of Diogo's examples. In this case, my main color is the "red" predefined option, but you could set the main color to be any darker color that you want, and the CSS rules below should still work. What side-effects were you running into? :root { --masthead-background: var(--main-color); --masthead-active-color: white; --masthead-text-color: rgba(255,255,255,0.8); --masthead-border-color: var(--main-background); --masthead-logo-color: white; --masthead-input-background: var(--masthead-background); --masthead-input-color: var(--masthead-active-color); --masthead-input-border: var(--masthead-text-color); --menu-item-backgroud-hover: rgba(255,255,255,0.25); /* "background" without "n" required for the moment */ } #pw-masthead .uk-navbar li a.hover { color: white }

They don’t have to be. It’s for my own reference and documentation, since I maintain the module PHP. I could delete the lines defining those settings and it would make no difference. If a 3rd party adds another theme in the same way, any of its custom settings defined in its config.php file will get stored alongside those of AdminThemeUikit in the same way. That’s why they are namespaced with the theme name, i.e. the prefix “default”. I agree. The main/master branch will keep existing installations on the Original theme. But on the dev branch, I think we have more room and I didn’t think most would know about it unless they were in our small regular group of people that visit here. We want to encourage those on the dev branch to use and help test it. If the original theme is selected, none of the other theme settings (like dark mode) appear. The feedback I’m referring to is “this theme is fundamentally wrong”. That’s a broad overarching negative statement referring to the entire theme and by extension those of us working on it, and I’m not sure how to read that as anything other than dismissive. To be taken seriously, I’d suggest wording like: “My opinion is that [some aspect] of the theme might work better if [it did something you suggest]”. That way you narrow down to specific things, and not the overall project and people. Anyway, I think you’ve already been following up with more specifics and GitHub reports, and that is useful feedback. Whether helpful or not, it is the true reason why some things may not be appearing the way you expect at this stage. When it comes to Uikit features that we have not used in ProcessWire, we would not have known to style them, and would not have provided custom styles for those. So if you don’t report them, we won’t know about them. I think it may have appeared that we accounted for them before because there was no dark theme to make them obvious, and the fallback Uikit styles weren’t too objectionable. I think it’s good the dark theme is pointing out the things that we hadn’t thought to give design consideration to before, because now we can. Can you be more specific? I don’t think it’s too late for anything. But if your definition of “anything” is “everything” (i.e. “throw everything out and start over”) then that is not something I’d consider. Personally I love the new theme, it’s exactly what I think was needed, for new users at least. When it comes to the design and CSS behind it, I consider this more outside my expertise, so I aim to learn from it. I’m interested in the quality and usability of the result and not as concerned about how it achieves that result. Though I do like the technical aspect of the CSS variables, where I can customize so much without having to compile anything. I’m running my own custom version of the theme (with a custom CSS file) where I’ve been able to tweak things exactly as I like them with very little effort. That’s good, and if we were starting from scratch and building a new admin theme from the ground up, I think we might take a similar approach. But we are talking about a new skin of the existing admin theme with a focus on attracting new users. This is not about reinventing the wheel, it’s about making design improvements to what’s already there. This project is not about implementing everyone’s feature requests (though that is an ongoing and long-term goal). There is no budget and nobody is getting paid. It’s funded entirely on the generosity of KONKAT. They are donating their skills and time to benefit all of us, and the entire project, and to help ProcessWire grow, and I’m very thankful for that. They are a business, not a charity, so they have to work within their bandwidth and means. So it’s up to them to decide how best to work with the time they have. I don’t follow. Either you are confused, I am, or we both are. Dark mode is experimental because it is something new we’ve not had to account for before. So there are likely more situations to uncover and fix in dark mode than light mode. But I also think it is here to stay. If there are people that don’t want it or have situations where it’s best not to have it, it’s completely optional and can be disabled site-wide or just for specific cases or modules.

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.

@adrian The problem is that you set your #pw-masthead text color to be white (#fff). It sounds like you want your search box to use the reverse. So all you would need to add is this (which doesn't strike me as messy): #pw-masthead .pw-search-form { --masthead-text-color: var(--text-color); }

@adrian Whether it's the intention doesn't really matter in this case because it's the physical reality of how it is constructed. They are the same AdminTheme, same markup, different styling. It also supports the ability for you to add your own themes. But if you want to do something more than what the Original does then you will still want to create a separate AdminTheme module. Same here and this is totally expected. That's why we're introducing and testing this on the dev branch. But my preference would be that people report issues on GitHub rather than complaining or saying they don't like dark mode. We're working hard to help ProcessWire grow and bring something great to our current and future users. By the time we're done with it, the goal would be that it makes no difference to module developers whether the user is on Original or new Default. You can't make modules that only work with the new theme. The new theme (or others using AdminThemeUikit's theme system) all are limited by what's in AdminThemeUikit Original theme. Someone would have to create a new AdminTheme module if they wanted to do what you are suggesting.