ryan

@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

@AndZyk Yes, my preferences mostly align with yours on this, so this is the sort of thing I've been experimenting with in my custom styles (repeater headers, asmSelect items, etc.). Though for me it does kind of depend on quantity of items... sometimes I like the lighter touch, other times I prefer the darker (main color), so I'm still kind of hashing out where to settle. For Repeater items, since they open and then represent the toolbar for an entire item, I do think they might potentially benefit from having headers with a darker background, at least when open. What quantity of repeater items do you typically deal with? What do you think about the idea I mentioned above where closed repeater items are light, and open ones (or maybe even hovered ones) have a darker header that uses the main-color (and light text)?

@monollonom Those are part of the admin.less system, and that will remain as-is. For custom theming with LESS, you'd keep AdminThemeUikit in "Original", so that there is no theme layer on top of it, other than your admin.less. Since admin themes are modules, the templates-admin dir is basically there as a last ditch fallback. It also serves as a place for any JS that is common to all admin themes, such as inputfields.js and main.js.

The Uikit theme will continue to be our default and primary theme. And AdminThemeUikit was upgraded with the ability to have themes (or sub-themes) within it. The new "Default" theme is such a sub-theme, a layer on top of AdminThemeUikit. When that layer is turned off, you are back to the "Original" output, without a theme layer on top of it. So AdminThemeUikit will continue to be developed as it is, with the Original look. And themes like the new "Default" will continue to style that output in a way that varies from the Original. But the Original is still the base/foundation of it. The intention is that others can also develop additional sub-themes on top of AdminThemeUikit, using modules. This theme-ability of AdminThemeUikit is not yet documented, but it will be.

We will look into adding these. Okay, can look into this too. This is supposed to be low contrast because it is non-essential information. It's the sort of text that we don't want to have your focus unless you are specifically looking for it. Admittedly I like the contrast, but I also like anything easy on the eyes, so will definitely give it a try. I'm not seeing it currently, but have definitely seen it before, and before the new admin design. I think it is related to the Inputfields JS for 'showIf' dependencies rather than the CSS of the admin. Look closer, there are definitely functionality upgrades here. Just to name a few, the masthead is now sticky and always available, the navigation dropdowns are quite a bit better as they scroll within rather the whole page, the top search now acts more like a command palette (with its own hotkey), and much of the admin appearance can now be easily styled with CSS variables.a I think forcing is a strong word for giving people the option to decide whether they want to use the Original look or the new Default look. In your case it sounds like you'd want to continue using the Original style for AdminThemeUikit. As mentioned a couple of times already, it will always be there, it's not leaving. That's correct. It'll be the default on new installations. The Original option will be there for new installations too, even if it's not initially selected. Users on existing installations will have the option of switching to the new default look if they want to, but it won't be the default on existing installations except on the dev branch while our beta testing proceeds. Do you mean the headers of repeater items, or literally the inputs? I like using the main-color as the background color for AsmSelect items, PageAutocomplete items, and repeater headers, so that's part of my custom CSS. @cst989 Sorry, I'm not trying to call you out. Having a cake to decorate was meant to make you laugh. We have a diverse community with lots of different opinions on design, and all are valid, I didn't mean to suggest otherwise. I've been trying to be clear that I'm no authority on design, and so that's why I'm trusting full time trained designers that know PW really well. They have a lot of success stories in their portfolio, and I'm confident PW will be one of them. But design is always tough because it's so subjective. For your preferences, it sounds like the new design isn't a good fit, and that's fine. But if you like the Original design, then know that it'll always be there too. ProcessWire is slow to get new users in large part because our admin and website often look dated to people that aren't already familiar with ProcessWire. I'm pretty sure that group of people will be more likely to explore ProcessWire with the new design. I think once you see the new website, the overall branding picture will be a lot more clear as well. I don't expect anything designed to appeal to everyone, but I'm confident this will help PW to grow.

@nbcommunication Maybe so. To be fair to the designers, they requested a different solution, but I wasn't sure how to implement in a way that would be as accessible. I will test left aligned labels.

@zilli If you are using the new AdminThemeUikit design, which bugs or aspects not fully addressed are you personally running into? Much of what I’ve seen so far have been ideas and suggestions, many of which have been addressed and will continue to be (though I will leave to the designers to decide which). When it comes to bugs, of course there will be bugs with anything as new and significant as this. But the bugs I’ve seen are relatively small and simple things, or with modules outside the core, all of which is very much expected at this stage. The amount of issues is extremely small relative to the scale here, so I've been impressed at how few issues there actually are so far. I disagree. I think Google says it well, so I’ll quote: "Design by committee" [or community] refers to a project where a large group of people, often with varying expertise and perspectives, are involved in the design process, leading to a lack of a clear, unified vision and potentially a diluted or mediocre final product. It's a negative term often used to describe a situation where too many opinions are being considered, hindering progress and resulting in a compromise that doesn't satisfy anyone. Quality comes from finding a professional you trust and letting them apply their expertise towards a solution. Diogo and Jan have been using PW longer than most here, they are at the top of their game and I have a huge amount of trust in their work. BETA TESTING is exactly what we are doing right now. That’s what the dev branch is for. If there are issues personally affecting you, I’d encourage you to open an issue report (none have been reported yet on GitHub). Earlier you implied it was released too early, but "keeping under wraps" implies releasing too late. So I'm confused. But to be clear, nothing is under wraps, it is all available for testing and feedback on the dev branch. That is the stage we we are in. I don’t understand this statement, especially in the context of this conversation. Tight control is not a term I’ve had attributed to me before, in any area. If I think about where I would value control being tight, it would be with matters of security or avoiding scope creep. Wonder no more. This is why we are here typing to each other and why the new admin design exists. It's the reason why we’ve come up with a fresh look for the admin, and shortly will be launching the new website as well. These are some of the most important changes for growth in the history of PW. The old admin and website are about a decade old, and were designed by me – I haven’t been a professional designer in about 20 years, and I think that was increasingly becoming apparent in PW’s appearance both in the admin and on the website. Long time users may be used to it, and some may prefer to keep using the Original design for AdminThemeUikit, which is fine… it will always be there. But we’re focused in getting new users. @jploch and @diogo do this for a living, are at the top of their craft, know what they are doing, and I’m extremely happy with and thankful for their work. My opinion is that what they’ve come up with is exactly what was needed. I don't expect everyone to agree, as we are a diverse crowed here and that's a good thing. @nbcommunication As I understand it, it is frowned upon to create a “Christmas tree” with design elements like this, especially where user input is involved. @cst989 Design is always subjective and it’s perfectly fine to have opinions and preferences. I think the new design speaks very much to what ProcessWire is conceptually and presents it is a way that is more modern, clear and customizable. Even if it is old, I do still like the Original design too (and it’ll always be there) but I think it had more to do with what I found attractive at the time, over what was right for the application. Whatever one feels about what's pretty or attractive is not the point. This is for an application that people use all day, not a cake to decorate. I think the new design reflects PW’s concept and framework better. And it has real systems design thinking behind it rather than just being pretty (though I think it's pretty too). Diogo and Jan know very well how to appeal to our target audience, as well as how to expand and diversify our audience. They are pros and this is what they know how to do far better than me. Having used the new admin for quite some time now, I feel I'm benefitting from it a lot. It's far more then just a pretty face and really grows on you the more you use it.

@bernhardI think that functionally the new look is better in this regard because the lines are limited to the actively hovered page. That makes more sense to me. I'm not sure the Original lines have any actual purpose. So not sure why I put them there other than it was part of the design style/trend 10 years ago. 🙂 Though if someone can find a strong functional reason for the lines where it provides some benefit to the user, then that would be worth having a toggle for. You mentioned that it would "help" some users. Is that because it's a more obvious clickable element? That seems more functional to me, and maybe something worth having a toggle for. I'm indifferent myself, as I don't really have a preference one way or the other. But worth passing along to the designers to see what they think. From the PW standpoint, this is the "message" notification, which is one that's informational and not supposed to call attention to itself. In that respect, I think the color is ideal and much more consistent with the purpose of it. But maybe something to get used to, as the Original design was more "in your face" with it's message notifications, even if it wasn't really supposed to be. The Warning and Error notifications are supposed to call attention though. I have that same "doesn't feel quite right" with most dark modes. But have to admit, the one in the new admin design feels just right to me. Maybe that's because I've been using it more than a month now. But once I tried it, I was hooked. Of course, there's always room for improvement. The new design makes it easy to adjust things with the CSS options, so it's easy to test things out, such as the background color you mentioned. If you have more specific suggestions over what would make it feel right to you, definitely share them. As of Friday's updates, if you provide an SVG logo that has as fill="currentColor" then it will inline the SVG and the new design will be able to use the new light mode or dark mode main color for the logo automatically from its CSS. Thanks, I didn't realize that, I think the the installer must have been in light mode when I tested it. I will test it in dark mode and fix the colors. I will look into adding this, not as new configuration values, but as extra inputs that get populated with the hex code when the color picker changes, so that you can change it if needed. Probably just a little JS should solve it. There's no plan to drop the original Uikit theme, but it's no longer going to be the default (at least for new installs). But we do plan to remove the AdminThemeDefault and AdminThemeReno from core and maintain them in as modules separate from the core. Maybe. We can see where we're at when we get closer to merging to master. Though if we did that, I wouldn't want existing installs to be unaware of the new addition either. So for existing installs, maybe an option to select it on a user-by-user basis, and a one time notification that tells users about it and how to switch between the two. Currently only the superuser can make this change, but I think it would be good for it to be selectable on an individual user basis.

Thanks for all the feedback on the new admin design last week. Based on the amount of feedback and requests we’ve received, it sounds like there’s a lot of interest and enthusiasm in the new design, which is fantastic. I’ve been making note of all the suggestions and will talk through them with Diogo and Jan at KONKAT Studio next week. There have been several good ideas mentioned. I was able to implement a couple of them already, including separately configurable light/dark mode main colors, and inline embedding of custom SVG logos (so the color can be styled). Personally I’m loving the new dark mode and have been spending most of my time in it. But I’m really digging the new light mode too, so I suspect I’ll settle into the “auto”, getting the best of both worlds according to the time and/or daylight. If you’ve not yet upgraded to ProcessWire 3.0.248 you are in for a treat when you do. Like anything new and on the dev branch, there may be some things yet to add and fix, but even in this initial release, I think you’ll find the new admin design to already be a beautiful and refreshing upgrade. At least that has been my experience. Thanks again to @diogo and @jploch for their great work with this. Have a great weekend!

@Mikel This is what the two custom CSS configuration options are for, so that you can tailor to your preferences, and especially with regard to colors. The original Uikit theme color set was inherited from the Reno admin theme. I also like that color theme, but it's not great for having a customizable main color or a dark mode. However, it's likely easy to get to, probably just a matter of adjusting a few CSS variables with one of the custom CSS options. The hope is that others will come up with custom color themes (such as a Reno color set) and post them to share. @bernhard Thanks for all the feedback! How do I duplicate those notifications? I don't recognize what I'm seeing in your screenshot. I tried ProcessWire.alert() and ProcessWire.confirm() but both are styling correctly. I'm not sure but I think that was what the designers preferred for the light theme. I think it looks good too, but I'm sure main colored buttons could also work well. Either of the custom CSS options should enable this. I think this is also likely a good use case for the custom CSS options. I think it's likely a subjective decision to have greater contrast between selects and text inputs on the light theme, to avoid one looking like the other. But it seems like it could work either way, as on the dark theme they are more similar in appearance. Not yet, but it's been requested a couple of times, so I'm guessing we'll likely add as an option. I do not agree that toggles suck. But I agree with you that there are specific instances where a regular checkbox would be preferable, like any kind of one time action or confirmation (deleting something, etc.). So it makes sense to me that that it should be something you can turn on/off. Just tried, but it works for me. Are you missing the leading "/" before "site/", i.e. "/site/" ? I don't usually like having to do extra file_exists() checks, but maybe it makes sense here. Perhaps the admin custom CSS file could be pre-populated with a /site/templates/styles/admin.css or something like that so that it would be the standard it uses, unless you opt to change it to something else. Probably the PW issues repo for now, unless Diogo and Jan would prefer they go in a separate repo, I will ask them when we speak next. I see what you mean, the text and the link are too similar here when the trash is open and you hover it. Why choose a color that isn't readable? For anything that has customizable colors, there's a responsibility to choose an appropriate color. In this case, unless you disable dark mode, you'll want to choose a color that works for both. The three predefined color options are there as good examples. Maybe we'll add separate main color choices for light and dark mode, I'm not sure, but it will still be the responsibility of the person configuring the color to choose something that is legible. I'd skip the white version, your logo looks great in dark mode. Sure. We're already doing it for the PW logo, so makes sense we should for custom SVG logos as well. Most likely it's something that PW doesn't use, so it isn't styled, but I'm sure it can be. I think we do use uk-alert boxes, but always of a type like "primary" or "warning" or "danger", etc. So maybe we just need to add a style for alerts that aren't of a specific type. Since PW has not had a dark mode before, I'm sure there will be modules that aren't ready for it, including some of my own too. But hopefully there won't be a lot of such cases, and most should be easy to resolve.

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

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

This week I’m going to briefly tell you about what we’ll have for you next week. If all goes according to plan, the new admin theme will be committed to the dev branch by this time next week. Technically it’s not a new admin theme in the module sense, but rather a new look for the AdminThemeUikit theme. (The original look will be there too, should you want to keep using it.) There are a lot of cool things about the new look, but here’s a few things to whet your appetite: 1. It comes with a “dark” mode, and a really fantastic dark mode at that. Every user can choose whether they want a light or dark version of the theme, or they can switch on-the-fly from any page. Both the light and dark versions of the theme are equally beautiful and refreshing. 2. The configuration screen lets you choose what your “main” color is for the theme, whether using predefined traditional PW colors, or a color picker where you can choose your own. 3. This theme also customizes the look of TinyMCE, so that it fits right in with the rest of the interface. 4. If you want to change more about the appearance of theme than what’s on the module config screen, you can do so with a custom CSS file. And there are more than 30 CSS variables that are easy to understand and customize. More next week, so stay tuned!

This week on the dev branch there are some issue fixes and new features. ProcessWire’s modal JS alert functions have been upgraded to use Uikit modals. Previously they were using Vex modals, but it appears that Vex is no longer maintained, so when we ran into an issue with them it just made sense to switch to Uikit for this, at least when AdminThemeUikit is the current admin theme. The JS functions affected are ProcessWire.alert(), ProcessWire.confirm() and ProcessWire.prompt(). All of which can be found in ProcessWire’s main.js file used by admin themes. ProcessWire’s Markup Regions output method was updated this week to support class removal by wildcard or regular expression. When you specify a class attribute with a class name that starts with “-“ that means that you want to remove that class from the element you are overriding/appending/prepending. Previously you had to specify the full class name you wanted to remove. Now you can specify a wildcard like this: <div id="content" class="-uk-width-*" pw-append></div> That would make it remove all classes from #content that start with "uk-width-". You may place the wildcard anywhere in the expression that you want to, enabling you to remove by prefix or suffix. But if that’s not enough, you can also specify a regular expression like this, which would do the same thing as the above: <div id="content" class="-/^uk-width-.*$/" pw-append></div> That's probably overkill for most, but between the “/“ delimiters, you may use any PCRE regular expression. Usually when we add a class to a markup region, we just specify it like a regular HTML class attribute. But if you want to add a class that would match what you are removing, you’ll want to prefix your class name with a plus sign. That tells the Markup Regions processor not to remove it even if it matches your rule. For example, the following would remove all uk-width classes and then add a uk-width-1-4 class: <div id="content" class="-uk-width-* +uk-width-1-4" pw-append></div> Regarding the new ProcessWire website: it’s nearly done except for the homepage. I’m saving the best part for last. I’m not saying the site will launch tomorrow, as there’s still a lot of detail work to take care of too. But I did want to say that a lot of progress has been made and hopefully it won’t be too much longer before we launch it. Thanks for reading and have a great weekend!

I hope you’ve had a good week. My kids have been on spring break from school for the last week, so we took them to the beach for a week. The weather was great, so I didn’t get much time at the computer. We’ve just returned and now I’m anxious to focus on ProcessWire. While I don’t have much to say this week, hopefully by this time next week I’ll have much more to write about, so stay tuned and have a great weekend!

Something else I wanted to mention is that for the last couple months, I've been manually verifying new accounts in the forums because we were just getting way too many spam signups. So now I'm manually researching every signup before they can post here. If an email address or IP shows up on any stopforumspam lists, or even just looks spammy, I don't approve it. Only about 1 out of 10 signups ends up with an approved account, as I'm pretty sure the rest are spam. If you sign up for a forum account here, ideally use an email address that is connected with a real company or organization, rather than a name followed by a bunch of random numbers @ gmail.com. Or, if you arent sure, you can always drop me a note on the contact form just letting me know you are a real person here for PW or webdev, and then I can approve the account right away. As soon as the spam signups slow down (hopefully they will!) I'll turn the automatic approval back on. We're also going to update the IP.Board version soon and that may help as well.

I'm currently traveling so don't have anything major to report this week, but wanted to check in. I am posting this from my phone in the car (don't worry, I'm not driving) and I'm not great at typing from my phone so will keep it short. 🙂 Progress continues on the ProcessWire admin design and the website, and I can't wait till we can share it with you. We may soon get another master/main version merged from the dev branch, as there have been a few updates in the last several weeks that I think our stable version would benefit from, and a few more to come as well. More soon! Thanks for reading and have a great weekend!

@artfulrobot I don't know much about this, but interested to learn. Thanks for the specific examples, I will give that a try. Usually when I've got low contrast text it's because it's supposed to be low contrast text, so that it doesn't catch the eye unless you are specifically looking for it. Kind of like disclaimer text, but maybe not quite that low contrast. So I guess it's a matter of finding something that is still low contrast, but not too low contrast. Not sure if the jQuery UI modals support that or not. Also a little worried about making them too easy to close (accidental keypress). But I will look into this. Or if you already know how to make it work, please let me know. I'm not sure I know what this specific example is, as there is no filter text on the pages list. Is that something added by a module? There is Pages > Find (Lister) but it does retain filter text when submitting the form with enter.