ryan

ProcessWire 3.0.251 has several updates to the AdminThemeUikit default theme by Konkat, a page-finding selector bug fix, and more. This version should fix the majority of reported issues with the new default theme in AdminThemeUikit, as well as cover the scope of Uikit features much more broadly. As we get closer to our next main/master version, we appreciate your help testing it. This version converts to “—pw” namespaced CSS variables. Previously variables were named like "—main-color" (no namespace prefix) and now they all have a "—pw" prefix, i.e. "—pw-main-color". Make note of that if you are using any custom CSS with the default theme by Konkat, as you may need to update your CSS variable names. This version also adds 3 new toggles (available in the AdminThemeUikit module settings). These toggles enable you to customize specific parts of the theme to be more similar to or consistent with the Original theme. They are intended to answer common feature requests for the theme. If you think any of these should be enabled by default, please let us know. Currently they require you to enable them in the module settings. These toggles include: Use bold headers for repeaters, files, images, etc. - This uses the selected “main color” as the background color of repeatable and sortable item headers, which results a treatment that’s heavier and more similar to the Original theme. Use buttons for page list actions - These makes the theme use page list action buttons that resemble those in the Original theme. It also slightly modifies the appearance of pagination links. Highlight focused inputs - This makes the color of an input change (to white or black) when it is the focused input. It makes select and text inputs have the same color presentation. And it makes TinyMCE have a white (or black) background when focused, rather than a muted background. In addition to the above, today’s version also adds version query strings to the CSS/JS files used by the Konkat default theme. Previously it didn’t, which due to browser caching could have caused some to see the incorrect output of the theme. ProcessWire 3.0.251 also fixes a bug with word matching operators that query the database, like those you might use in a $pages->find() selector. (Word matching operators are those with a “~” in them). If you attempted to match a word that was more than 80 characters long, it would cause the word to get filtered out of the query completely, rather than force a non-match. So if your selector was “a=b, c=d, e~=[81 character word]”, then it would behave the same as a “a=b, c=d” selector, with the “e” part no longer contributing to the result. The correct result here is to match 0 pages, but it would instead match public pages that matched selector “a=b, c=d”. It was corrected by truncating the long word to 80 characters, rather than removing it from the query. If you are using full-word matching operators in your site search engines, it’s worth throwing some 81+ character words at them just to see if it causes any issues with your results, perhaps matching incorrect, irrelevant or too many pages. If so, then you may want to upgrade to PW 3.0.251, or truncate your search text to 80 characters before putting it into the selector. i.e. $q = substr($q, 0, 80); Thanks to @adrian for finding and reporting the issue. Lastly, ProcessWire 3.0.251 contains a few other updates, such as the ability for Process modules to use icons in their headlines, a ProcessPageLister fix, and more. ProcessWire Weekly #584 covers a couple of them in more detail. That’s all for this week, thanks for reading and have a great weekend!

This week we have some useful upgrades to ProcessWire’s Markup Regions system. These upgrades make Markup Regions even more flexible and intuitive by reducing the dependence on HTML id attributes. Here is a new blog post that covers it in detail— https://processwire.com/blog/posts/pw-3.0.250/

I'll be on the road today picking up my daughter from a summer camp that’s 4 hours away. So I'm spending the day in the car rather than at the computer. As a result, I don’t have anything major to report this week, but wanted to say hello before I left for the day. Progress continues on everything we’ve talked about in recent weeks. I’m also working on a client project, building a ProcessWire based login portal that is kind of a front-end to a Salesforce system. It uses LoginRegisterPro, FormBuilder and ProFields Custom Fields. I’m making some improvements to those 3 modules as I go. For instance, LoginRegisterPro will be getting an email-to-login option. When enabled, if you submit the login form but leave the password blank, it’ll email you a link to automatically login. The feature is optional and not enabled by default. More next week. Thanks for reading and have a great weekend!

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

Our Toggle Inputfield is a different animal, both in appearance and function. It represents 2-3 different labeled states, and an undecided state (4 states total) whether that means Yes/No/Unknown, On/Off, This/That/Other/None, Boy/Girl, Happy/Sad, Clean/Dirty, Off/Low/Medium/High, or anything else that has multiple named states. Checkbox fields, whether visualized as check mark style or toggle style, represent unchecked or checked, 0 or 1. I think a Toggle Inputfield might better be compared to radio inputs with labeled options like Yes and No, or something like that.

I don't have strong feelings about checkmark style versus toggle style checkbox controls. It sounds like some people do. I'm fine with regular checkmark style being the default rather than the toggle style, but I divert to the designers. I don't understand the strong feelings because they both represent the same selected (1) or not selected (0) states. You posted a screenshot with "light" (left) and "dark" (right) labels, and that is not what we are doing. Those labels make it represent something else. That relates more to our dedicated toggle Inputfield, which has an entirely different appearance. In the physical world, the checkmark style represents something we would do with a pen, and the toggle style represents something we'd do with our hands on a machine. If I think of an airplane cockpit, there won't be any physical check boxes and marks. The same is true with literally any physical tool or machine we interact with. On my Android phone at least, there are no checkmark style inputs in the OS, they are all toggle style. So I'm quite used to them being one and the same as check marks, which is probably why I don't notice one way or the other. But I do prefer checkboxes when they are unlabeled and in the far-most right column of a table, like a delete checkbox, because it uses a little less space, even if a toggle style checkbox might be easier to click/tap vs. an unlabeled checkbox.

@adrian No, it is not a matter of time before the old one is no longer supported. I've said this a few times already, but the Original theme is not leaving. It is "base" theme of ProcessWire, and the one which the new Default theme depends upon. If some new feature is added, it has to be accounted for in the Original theme before the new Default one. If these themes were like PHP classes, then the Original would be like WireArray, and the new Default would be like PageArray... one inherits from and depends on the other. The new Default theme is not a separate theme the way that AdminThemeReno was a separate theme. If the Original style suits your needs better, there is no reason to transition.

@adrian I'm still learning about CSS properties/variables, so I might be missing something. But based on what you've said above (and in other places), I'm wondering if you are missing the cascading and inheriting aspects of CSS properties/vars? Maybe you are thinking of them like PHP variables? They are quite a bit more powerful than that. If I understand it correctly, the actual number of variables you can customize is the number of CSS variables multiplied by the number of elements using it that can be targeted with a selector. We probably have thousands of customizable properties just with the set of variables we have now, where the selector is like the namespace for the variable. So when you set a value of something like --blocks-background, you are setting a default/fallback value if setting it within :root { ... }, and then, it may be overridden further down the tree. In your masthead example, you would target the --blocks-background within #pw-masthead, or something more specific within it. In your PageList example, you would target --muted-color within .PageList, or something more specific within it. So in my mind, it doesn't make sense to have tons of CSS variables unless you plan to treat them like PHP variables, which would be using them incorrectly. The current set of CSS variables seems well thought out to me, but I'm still learning.

I don't know if they need to be that specific, I didn't have time to try out different versions. I wanted to post stuff that I knew would work the first time, but I wouldn't be surprised if many could be simplified. If you find any that can be let me know and I'll update the post.

@bernhard Dark mode in particular is experimental, so I definitely wouldn't expect everything to work perfectly at this stage. Plenty of my stuff doesn't display perfectly either. It would be good to start a GitHub issue report to keep a list of things like Uikit classes not yet accounted for in the styles. In light mode, we didn't necessarily have to account for everything since it would fallback to Uikit's defaults, so dark mode is a good pointer to finding such things. If Uikit supports something then we want to also. It would be best to open a GitHub issue report for it rather than here. Perhaps it can be one of those ongoing ones that we keep open for awhile until everything is covered. As far as targeting dark or light mode with a CSS selector, prefix your CSS selector with ".dark-theme" or ".light-theme". I've only had one instance where I needed to do that, as I've been able to cover most other light/dark things with the CSS variables, but it's good to know about nevertheless.

There have been several requests and suggestions for the new AdminThemeUikit default theme. Some of them will no doubt find their way into the core CSS files, but I thought this week it would be useful to look at just how easy it is to apply some of these yourself using the custom CSS options in the AdminThemeUikit default theme. I haven't yet run these through Diogo and Jan, so there may very well be even simpler ways to do these things, but I took my best shot at answering some of the requests here. You can specify a custom CSS file (like /site/templates/styles/admin-tweaks.css), or if you are in advanced mode ($config->advanced = true) you can specify custom CSS rules directly in the AdminThemeUikit module settings. Let’s look at how to accomplish some recently requested tweaks. Also attached is a CSS file that compiles them all in one. And all of these work in both light and dark mode, by the way. CSS variables make much of this very easy to do. In this case, we’ll choose colors that are relatively close to black and white, but a little less harsh for those that like to have their screen brightness high. Of course, adjust the colors as needed for your preferences: :root { /* use slightly lighter main background color */ --main-background: light-dark(#efefef, #222); /* also slightly lighter background color for blocks like Inputfields */ --blocks-background: light-dark(#fcfcfc, #111); /* use text color that is not 100% white/black */ --text-color: light-dark(#222, #efefef); } You can adjust the button-background CSS variable: .light-theme { /* if you prefer not to have black buttons on light theme... */ /* use main color for button color */ --button-background: var(--main-color); } .pw .ui-button.ui-state-hover { /* highlight button when hovered */ filter: brightness(1.08); } Set .uk-select elements to use the inputs-background CSS variable: .Inputfields .Inputfield select.uk-select { /* make <select> elements have same background color as text inputs */ background-color: var(--inputs-background); } Here we'll use the main color as the background color for the PageList action links, and then make their text white. This gives more of an Original theme appearance, for those that prefer it: .PageList .PageListItem .PageListActions > li > a { /* make PageList items use action links that look like buttons */ display: inline-block; line-height: 1.3; background-color: var(--main-color); color: #fff; padding: 2px 6px; font-weight: bold; text-transform: lowercase; position: relative; top: -1px; } .PageList .PageListItem .PageListActions > li > a:hover { /* highlight selected action when hovered */ filter: brightness(1.08); } #pw-content-body .PageList ul.uk-pagination > li.uk-active > a { /* optional: update active pagination to use main color */ --blocks-background: #fff; --text-color: var(--main-color); } Like with the PageList action link buttons above, we apply new background and foreground colors to these sortable item-based elements. We also make a few other small tweaks to accompany the color change: .pw .Inputfields .InputfieldPageAutocomplete li, .pw .Inputfields .InputfieldPageAutocomplete li a, .pw .Inputfields .InputfieldPageListSelectMultiple ol li, .pw .Inputfields .InputfieldAsmSelect .asmListItem, .pw .Inputfields .InputfieldAsmSelect .asmListItem.ui-state-default, .pw .Inputfields .InputfieldAsmSelect .asmListItem.ui-state-hover { /* make asmSelect/autocomplete/pageListSelect use the main-color */ --main-background: var(--main-color); --border-color: var(--main-color); --text-color: rgba(255,255,255,0.9); background-color: var(--main-background); margin-top: 0; margin-bottom: 1px !important; } .pw .Inputfields .InputfieldPageAutocomplete li:hover, .pw .Inputfields .InputfieldPageAutocomplete li:hover a, .pw .Inputfields .InputfieldPageListSelectMultiple ol li:hover, .pw .Inputfields .InputfieldAsmSelect .asmListItem.ui-state-hover { /* highlight hovered items */ filter: brightness(1.05); border-color: var(--main-color); } In this case, we'll instruct <input>, <textarea>, <select> and TinyMCE elements to show a 1px border outline using the main-color when focused: .Inputfields input:focus:not([type="submit"]):not([type="file"]):not([type="checkbox"]):not([type="radio"]):not(.uk-form-blank), .Inputfields textarea:focus, .pw .Inputfields .Inputfield select.uk-select:focus, select.uk-select:focus { /* have inputs show a focused state indicated by border color */ border-color: var(--main-color); } .InputfieldTinyMCE .tox-edit-area { /* setup a border in tinymce that we can highlight when focused (requires latest PW dev) */ border: 1px solid transparent; } .InputfieldTinyMCEFocused .tox-edit-area { /* make tinymce show a border (like other inputs) when focused (requires latest PW dev) */ border-color: var(--main-color); } I found that InputfieldTable worked quite well as-is, but making the <table> use a transparent background color seemed to blend in a little better: .InputfieldTable .AdminDataTable tr { /* make InputfieldTable <table> have same background color as its container */ background-color: transparent; } .InputfieldTableRowSortHandle:hover, .InputfieldTableRowDeleteLink:hover { /* make table action links highlight with main color when hovered */ color: var(--main-color); } For the headers of repeater items, we take the same approach that we did with AsmSelect, PageAutocomplete and PageListSelectMultiple items, giving them the same bolder color scheme that utilizes the main color: .pw .Inputfields .InputfieldRepeater .InputfieldContent .InputfieldRepeaterItem > .InputfieldHeader, .pw .InputfieldFileList > li > .InputfieldItemHeader { /* make InputfieldRepeater item headers use the main color */ --inputs-background: var(--main-color); --border-color: var(--main-color); --text-color: rgba(255,255,255,0.9); --muted-color: rgba(255,255,255,0.8); } .InputfieldRepeaterItem > .InputfieldHeader:hover { /* make hovered repeater header slightly highlighted */ filter: brightness(1.05); } There are two CSS variables for this. One to control the border-radius of <input> elements, and another to control the border radius of buttons: :root { --button-radius: 99999px; /* this is the default value */ --input-radius: 8px; /* default is 0 */ } This is one thing I couldn't find a simple way to do with CSS, so I went ahead and added a toggle in the original theme settings (Modules > AdminThemeUikit). You'll now see an option there to "Disable toggle-style checkboxes", should you want it. As you can see from the above examples, one of many nice things about the new default theme is that it's quite simple to tweak it for your preferences. Attached is my admin-tweaks.css example file that has all of the above, and a couple more small things too. Please reply with your own custom CSS tweaks that you like. Thanks for reading and have a great weekend! admin-tweaks.css