ryan

@adrian Okay I think I figured it out. The jagged text is only visible on non-hidpi screens. My dev computer (iMac 27") has a hidpi/retina display, and there was no visible jagged text in any browser. But as soon as I tried it on a non-hidpi screen, I was able to see the jagged text. I've adjusted it so that the filter is completely removed except when it's transitioning between two words. So a few jaggies when animating, but otherwise not. It seems to improve it a lot on the 72 dpi screen I'm testing with here. How about there?

@adrian I don't care for the look of that jagged text in your screenshot either, but I can't duplicate that in Chrome, Firefox or Safari. I'm running on OS X. What browser and platform are you seeing that jagged text in?

@taotoo Thanks, fixed the animation in Firefox. It turns out Firefox needs the SVG filter to be visible, so had to remove the "hidden" attribute and move it off screen with absolute position. I don't know what's up with the MS Edge appearance (I don't have that environment to test in) but if you find what it is, please let me know. @poljpocket I prefer to stick with the term CMS and guide folks into the CMF side of things, since the term isn't so widely known/used. Though I'll continue to use it, just not front and center. @adrian Blur issue should be fixed. The large text size on the homepage is intended. @Alexander That assertion is incorrect. The metrics say this redesign was long overdue. But you are right about a performance issue with the desktop version of Safari (only) related to not using the GPU, I'm working on it.

Just want to mention that none of us here is the audience for the homepage. It's for people that are not yet familiar with ProcessWire or just learning about it. Some will be developers, some won't. The animations are there to communicate ProcessWire concepts in a memorable way, for people that don't already know these things about ProcessWire. But we are the audience for most of the rest of the site, such as sections of the site like the API references and modules directory. So if you don't like animations, don't worry because we aren't adding them elsewhere in the site, but they are an important part of what the homepage is there to communicate. Fixed, thanks. I looked into this, and actually it is working, but is being affected by a feature in the new directory. The new modules directory doesn't show modules that are missing a README/description, or have one that's too short to be useful to anyone. Though they should still appear on the author's page and in search, etc. They just won't appear on the modules homepage. I looked at some of Bernhard's modules and that appears to be what the issue is (example). The directory shows an alert to communicate what the issue is. @bernhard Can you add README files to your repos for the files? There should be enough info there for people to get to know what the module does and to decide whether they want to download/install it, like a couple paragraphs or more. I probably have a few of my own modules that I need to add more info to as well. While I'm not seeing "pretty" change anything, I do like what the "balance" option is doing. I went ahead and added both though. I like how it is here, as there's no chance of visually mixing up which graphic goes with which text. But that's what your screenshot did, taking the text from one concept, and the graphic from another. 🙂 I'll pass along to the designers to see what they think though. Fixed, thanks.

@monollonom It looks like that width:100%; on the uk-card-body is something I added last minute for some reason, I don't know why. I removed it and it seems to correct that issue that was appearing for "other modules by author" list. Hopefully I didn't break something else by removing it. 🙂 I tried the CSS trick you mentioned (very cool!), but I'll have to return to it when I've got more time. For whatever reason, it added an underline to the text and no amount of text-decoration: none !important; seemed to be able to cancel it. @adrian Thanks, code examples fixed. I'll return to the image thing, I may have to cancel that rule for images in the modules directory.

Btw, the old site can be accessed just by appending ?oldsite=1 to any URL (temporarily, anyway).

@adrian Either is fine, but to start, right here is good.

This week I’m thrilled to report that we have a new website online. The site was designed by @jploch and @diogo of KONKAT Studio in Hamburg Germany. Here's a short announcement post about it— https://processwire.com/blog/posts/processwire-website-redesign/

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); }