Leaderboard

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!

As noted above regarding z-indexes, they also seem weird for top nav menu dropdowns. It looks like they are set to 200, but they still appear behind Tracy panels when they are set to 100. I haven't narrowed down the exact required index, but setting Tracy to 50 lets the menus dropdown over Tracy panels. In the original theme, the menus are also set to 200, so it must have something to do with the new fixed header nav messing with things.

Hey ProcessWire Community, We recently built a user data table module for a client. It was solid – tailored for specific fields, neatly formatted, and with just the right amount of complexity. Then we thought, “Why not turn this into a fully configurable module for ProcessWire’s admin?” And to make it even more interesting, we decided to pair up with AI to build it. Spoiler: AI is not great at ProcessWire. ⸻ Why AI? We figured AI could help with some of the more repetitive coding tasks – like parameter parsing, formatting logic, and output generation. But AI had its own plans. It decided to take every simple task and turn it into a five-step process involving nested arrays, regexes, and a lot of unnecessary conversions. What We Learned: • AI is good at suggesting solutions – even when they’re completely wrong. • AI will confidently map dates to currency values and sum() text fields. • AI thinks that everything is a map() – and if it’s not, it should be. • ProcessWire is flexible, but it doesn’t bend to AI’s will – and that’s a good thing. But have a look for your own: User Data Table or https://processwire.com/modules/process-user-data-table/ It is more or less production ready and we test it in some client projects as it really comes handy when showing user related data as a table in the backend. We even forced AI to do the Change log and the Readme files, so it should be not too hard to test. 😁 Example 1: (detailed example including configuration can be seen in the README file) UserAdminTable with users that have the 'member' status (showing their created value on :hover), their visits of certain pages (with modal opening for details), their purchases (with modal opening for details) and the Total of their purchases. All column titles are clickable for sorting asc/desc, direction is indicated after sorting. Example 2: (detailed example including configuration can be seen in the README file) UserAdminTable with standard user fields and one virtual field showing `created` value as column with minimal configuration.

Couldn't have said it better. This is on the dev branch and is amazing so far. Massive thanks to all involved. And all the people giving feedback is amazing as well. By the tine this is ready for prime time it will be awesome.

Hello, After spending a week with the new admin theme, my feeling is that it is definitely a step in the right direction, making the admin feel more like an application, and many thanks to all who've worked to get it where it is. That said, there's quite a few issues I and the team here have picked up on. Most of these have been highlighted already. Here's some observations interspersed with some issues: Page Tree A number of colleagues have commented on the removal of the 'lines' on the page tree. I much prefer the new look, but it may be useful to have the option to toggle this on/off. I also like the 'text' style of the action buttons, but feel a more button-like style on hover would help. Colouring Something I'm not keen on is the lack of colour for the messages. Having the primary alert colour being the same as the background makes it hard to notice. We think the background colour (#eee) in light mode is too dark. #fafafa feels better. I also miss the colour of AsmSelect items. Having these in grey makes them blend in too much. Dark mode I prefer dark mode, but I've found myself switching to light mode on all the installs I've worked on. I can't pin down the problem though. It might be that the muted grey background makes the actual UI (fieldsets) too stark. It doesn't feel right. I agree with other comments that there needs to be an ability to customise the logo and colour for both modes. The installer needs to be tested in dark mode. All the input text is white on an input on a white background! (longest, most frustrating PW install ever!) Colour picker I think there should be at least two more fields beside the colour picker input, one for HEX value, and another for RGB. Editing one updates the others. On Safari, the native colour picker doesn't give you the option to input a value so I needed to login on Chrome to set the value I actually wanted. ... My main concern with this is the rollout when this reaches the master branch. We have a setup where we can update all PW sites on a server at once, and as it stands I think we'll need to go into each site to specify light mode. We want the rollout to be successful with our clients, and we'd prefer to adopt the new theme gradually, as and when we're working on a site. I think retaining the original UIkit theme as the default should be considered. Cheers, Chris

If you're having trouble managing the "Active URL" status through the CMS interface, I found that a direct database update may be the solution. Here’s a working SQL command to set status2818 = 0 for all selected language/pages(both published and unpublished): UPDATE pages SET status2818 = 0 WHERE published IS NULL OR published IS NOT NULL;

Hi @Stefanowitsch, Thanks, yes this is a bug. It was affecting the webP generation when using <picture> and was just defaulting to 90 for quality. I've pushed a fix for this and refreshed the module so it should be available for upgrade now. As for webP being larger than the original - I've found this to be the case for some images. There's some good info on this in this thread: Cheers, Chris

Ah perfect. I forgot to mention that I get the same result logged out as well as logged in. But it doesn't matter since $a->getLanguages() works fine. thanks!

If, by chance, oddities discovered during the creation of the template - (CSS et al), testing, and reports of usage - could be included in a document by the theme authors somewhere for future work (next iteration of a template?), that would be amazing. Absolutely outside the scope, but likely appreciated by others, for sure! 🙂 Some of the issues will be module-specific, but issues with core, or (more) "commonly" used modules (ex: InputfieldIcon) might be worthwhile to be noted there... Just a thought, after reading all of the feedback thus far. The unfortunate thing here is that once you offer a light/dark mode, prior colors that worked in whatever theme was used previously (in the PW backend, this would essentially be a light theme, by default) just might not work -- and they could have been set as a primary color from a prior theme customization, or even as bernhard said, the company's primary color. For my company's primary color, it is a sort of putrid green (#649a44). Even in light mode it doesn't work well, but is terribly difficult to read in dark mode (when I was developing a light/dark mode for the frontend). I had to use color mode saturation/lightness adjustments to make it appear as though I'm using the same color, while in effect they're fairly significantly different colors (but visually, to the eye, looks right-on-target). This isn't something that can be done by simply assigning a single color. Even with CSS color function adjustments (lightness, saturation, lab colors, etc.) it's a bit of a "magic number" game. BTW - related 👉 Safari: How to have the browser pick a contrasting color automatically via CSS (🤞 for other browsers to implement this too) That said, the custom CSS file override option still works just fine. Since this theme does offer customizations though, the determination would mostly be, "Where does it make sense to offer a customization right in the theme, and where should the dev take the extra effort themselves?" Primary color, I opine, would likely be a configuration option that would often need to be customized further for light/dark compatibility, and therefore makes sense to offer the option in the theme. Similarly for the logo image used in the backend. Just because we may think a certain logo image is fine as-is (ex: bernhard's logo), the client might not, but may also demand it. It's definitely something we can adjust, either with admin JS and/or CSS, but if it may be a common request or need due to the light/dark mode offering, it also seems to make sense to offer the option here (imho). Love seeing the work, excitement, and feedback thus far. I haven't had a chance to give this a whirl yet, but appreciate the massive amount of work that's gone into it, and the early testers that are enthusiastically offering their feedback!! This community is so awesome. P.S. - Is there any preferred way that we might offer any sort of assistance with the theme? Too many "cooks in the kitchen" can cause confusion, but I also know the effort was voluntary and it's easy to identify potential issues, harder to fix, and/or find the time to fix.

Thanks for all the work! I can see clear improvements on lots of places. A couple of things that I bumped into, some of which have been mentioned already: We not just need separate color pickers for light and dark themes, but also logo url fields (I have a white logo which now disappears completely in light mode) Primary buttons should be in the primary color, which is not the same as black! I find these very unclear and even distracting when quickly scanning the page. Return or optionally enable regular checkboxes, please. Accessibility is low. Low hanging fruit: make sure you get :focus, :focus-within working, right now its impossibly hard to see when a 'toggle' or close button is selected. Use https://wave.webaim.org/ to check the rest. (this is a tip for all reading this) Selected icons (in edit template / field) disappears from the list: Again thanks for the work and looking forward to whats next!

I also think there are use cases for both classic checkboxes and toggle switches. Both might work well in the same context, but there are also situations where they are not interchangeable. This is all about UX ;)

Any chance we could have css variables for page list action buttons for color, background, border-radius and padding? I really want to go back to the look of them being buttons. Or, we need to separate the usage of --blocks-background, because at the moment it is also used for the hover color when the page list actions are displayed. I don't like the grey page background so I have changed --main-background to white, so I need to change the color of the page list actions hover but if I change that to something useful it makes all fieldsets look awful because --blocks-background is also used for those. Actually, it seems that --blocks-background is also used for some button text colors --button-color: light-dark(var(--blocks-background), var(--text-color)); - this is problematic because you can't override --blocks-background without overriding --button-color I honestly think there needs to be quite a bit of tweaking of the css variables to make things usable.

Hi, if you're using markup region and thus append the _main.php file to tour template, just go to your sitemap model config and check this checkbox (files tab) to prevent appending the full html thing around your xml 🙂 have a nice day