Leaderboard

Separate color pickers for main color (light) and main color (dark) sound like a good solution to allow proper branding while still being accessible. Also, I would like to second the request for adding CSS variables for the border radius. There are some great additions in the new theme to make things more customizable, but to call it truly "customizable", it should offer the possibility of changing the border radius on buttons and inputs. The current look (very round buttons + completely square inputs) is a bit peculiar, but that's okay as long as we get a way of tuning things ourselves 🙂

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.

Same problem with the EditFieldLinks tweak https://github.com/baumrock/RockAdminTweaks/tree/main/tweaks/PageEdit/EditFieldLinks Do you think these issues can be fixed in the admin style or do we have to fix those issues in the affected modules?

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!

@ryan I know you asked in the blog post about whether this should be in the core or not and there have only been two replies on the post and not much discussion aside from that (unless I missed a thread somewhere), I think it should go in the core. Like you said you only realise you need it when something goes wrong and recently a staff member lost an hour's work to some scenario or other. I've also done it myself from time to time but keep forgetting this module is here. In my opinion, if it's low overhead it should be in the core and turned on by default. If we're uncomfortable with the idea of modules being installed by default, perhaps the installer should make suggestions after installation - like "suggested modules for different types of site". Anything article/blog related should then suggest this module. I do forget certain modules exist too, like this one has existed for 2 years and I forgot. It would be lovely if the Modules part of the PW admin could be overhauled to easier find things from the directory by category or some sort of search like WP/Craft etc does it. Not saying their implementation is perfect but feels like it would take a little hassle out of it by making things searchable and 1-click installable from the PW admin. I'm sure others have discussed that in the past so maybe also a way to suggest features and vote for things too? The forum software can handle polls easily but I'm getting off topic now.

Thanks for your comment @szabesz and the kick in the ass 😁 We updated the README with some Screenshots and explanations. Also inserted a Screenshot in the initial Post above.

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/

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.

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.

First of all thank you to everyone involved in making this new admin theme. This is a really good looking admin theme. 😀 I have not tested it very well, but one small issue I noticed: When you tried to assign a tag to a field, there seems to be an z-index issue with the autocomplete results: Keep up the great work. 👏 Regards, Andreas

Something else to add - I think people maybe don't know things like this exist either. Not sure how best to explain it but since there's no metadata for SEO that would easily match "I lost my page data" with a module called "page edit restore" I'm not sure how easily people would find the module. Google obviously does a good job: https://www.google.com/search?q=processwire+module+to+prevent+data+loss&rlz=1C1ONGR_en-GBGB989GB989&oq=processwire+module+to+prevent+data+loss&gs_lcrp=EgZjaHJvbWUyBggAEEUYOTIHCAEQIRigAdIBCDUyMjBqMGoxqAIAsAIA&sourceid=chrome&ie=UTF-8 But if you type "data loss" into the search on ProcessWire it doesn't return this module (seems to return a lot of things other than that though). There's probably an argument there for someone to go through and add more search terms that don't necessarily relate to a category to make some modules easier to find I think. Any maybe based on my earlier thoughts, a way to categorise modules as suitable for specific types of site (article/blog etc) as well as by the usual categories.

Because "Artificial Intelligence" is a marketing word, and computers will never become intelligent as the definition of intelligence according to the Oxford Dictionary on may Mac is: "the ability to acquire and apply knowledge and skills" You see, LLMs cannot acquire knowledge (nor skills), they are "trained" (which is also a marketing phrase, BWT...), and a database full of data is not knowledge, the dictionary says that knowledge is: "facts, information, and skills acquired through experience or education; the theoretical or practical understanding of a subject" "Understanding" is the key word here. LLMs and fine-tuned models calculate probability which is very far from being a "fact". Another key word is "experience". A computer with experience? BTW, Interesting article to read: https://www.nngroup.com/articles/ai-model-training/ Anyways, thank you for sharing you module! Could you please also add an image or two to the readme, so that people can have a visual view of what to expect in that regard?

I haven't seen this happen for over 10 years as it's a very friendly and helpful community and it's also part of our community guidelines: https://processwire.com/talk/topic/8234-community-rules-guidelines/ 😉 If you see anybody violating the rules just contact one of the moderators - no need to blame anybody upfront. Thx

Hi all 👋 Just dropping in to thank everyone for your input and to acknowledge that I read through the thread. I don't have time to respond at the moment, but will do as soon as possible.

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.

AI, Cursor, Windsurf, Claude Code... you name it. In terms of ProcessWire they all need a strong hand that guides them through different tasks, ways, and whatever its in the way. You need to oultine your part in ProcessWire in great detail. You need to define hooks, the solutions to use - from ZIP to TempDir. You have to outline the forms it needs to render and the fields to use from start to finish. You could give an existing module as baseline, but beware it knows what to do then. But extending existing modules works pretty good - see my fork here of GUID/UUID Generator Whatever tool you use, it knows the baseline I knew 2 weeks into ProcessWire back in 2014 after doing the tutorials and reading the forums. Hint: Let Composer/Cascade finish the tutorials - it's wild! And let them create rules, workflows and memories from it. You will reach a junior-junior grade PW-dev this way. BUT (big time)... it's great and even superior in terms of PHP. Do the outline, from start to finish, do what you know in terms of ProcessWire. Let the AI/IDE/Agents do the PHP part, including docs, and you will be happy. Sure... not that much fun as people have that use NextJS (13, and maybe 14, but not 15) or AstroJS (2,3, and parts of 4, but not 5)... but hey... that's still only JavaScript (maybe Typescript) those AI/IDE/Agents are good at - the concepts still need either docs or a solid foundation. In the JS-world everything is a pattern, everything is JS or TS, the concepts are the same. But framework-specific... is another story. Laravel works great. Ok, maybe not the latest version, and maybe not all the extensions, like Forge and Filament. But yeah, it works. Even migrations. Depending on the database. And don't try Supabase or Neon. That's super wild. But... older versions with just *.blade.php - works! Flux, InertiaJS, VUE, React? meh I am still not a coder/developer/programmer BUT... I know how to write a technical concepts and know how to outline modules, hooks, whatever in ProcessWire. The moment I realised that those tools are great at PHP, and s*ck at ProcessWire - I understood what to do. A new project I work on, a NextJS/AstroJS/ProcessWire-combo, has already 50+ documents to outline which tool does what and how to do it. And I didn't even really start to outline anything in terms of modules or hooks. The ProcessWire part, or at least a big part, is already outlined here: https://github.com/webmanufaktur/pwai/tree/windsurf Which is the latest commit with most of the stuff needed - for my projects. But yes... those AI/IDE/Agents only see patterns and try to match up - in frameworks. To give a bit more helpful details here: AutoTemplateStubs is a great addition to help your tools to understand what's happening. In case you hate to do everything yourself: RockMigrations has some nice .vscode snippets that help and most AI/IDE/Agents understand it and can create templates and fields right from migrate.php. Noice!

Hi everyone! And thanks for the great work in the new admin, I kind of also agree on the checkboxes! I'd skip the white version, your logo looks great in dark mode. I'd also vote on the customization of the logo! I think @bernhard's logo on the screenshot is just a nice coincidence, but I'd say most of the times it wont work out of the box? Been testing it a little bit my block building setup using repeater matrix ,also nested repeaters, and at first glance I kinda miss the depth the repeaters added with a slightly darker background color. Will report back with more concrete examples!

Thanks everyone for the work on this! A couple of issues I noticed right away: Tab indicator not positioned correctly. Add new button padding (Repeater Matrix) I also really need checkboxes back - toggles don't work en masse and I also heavily rely on https://github.com/baumrock/RockAdminTweaks/tree/main/tweaks/Inputfields/CheckAllCheckboxes for being able to quickly check all checkboxes. This came from AOS originally, but I ported over to RockAdminTweaks.

Hey @ryan @diogo @jploch thx for your work on this! I have some questions: 1) UIkit notifications seem to not use the theme's styling: 1.b) Is there a reason why primary buttons are black and not in the primary color? 2) Could you please add an option to make the button's border radius customisable? 3) Could you please add an option to make all input's border radius customisable? Ideally both would use the same setting by default but could be also set differently. This was one of the changes proposed by @Chris-PW when we were working on a new admin style and I think it makes sense to have everything that can take user input (<input> <textarea> <button> etc) have some rounded borders. We already have lots of lots of lines in the admin to help with grouping content, wrapping inputfields etc. and all those lines add up. Having all clickable elements look slightly different from everything else (but identical on their own) helps a lot in my opinion. 4) Is there a reason why <select>s have white background and regular inputs have a light grey? 5) Is there an option to disable the new toggles and get back to good old checkboxes? See https://axesslab.com/toggles-suck/ Even if one prefered toggles over checkboxes in general, I think there are some situations where they are absolutely counterproductive, for example here: 6) I tried do add the file site/templates/admin.css with the following content: :root { --border-color: var(--main-background); /* --inputs-background: var(--blocks-background); */ } I then put both "site/templates/admin.css" and "/site/templates/admin.css" in the AdminThemeUikit config for "Custom CSS File", but it had no effect. Strangely when I put "wire/modules/AdminTheme/AdminThemeUikit/themes/default/examples/borderless.css" it worked! I also tried with this content: div { border: 1px solid red; } Still no luck. 7) Would it be possible to have the admin theme load one CSS file by default. Similar to what we know from /site/ready.php it is often so much nicer to just place a file in a predefined location than to have to update a module's config somewhere. This might not sound like a lot to do, but when working with migrations and automated deployment workflows these things get more tedious, because you can't simply change the module config, you have to migrate these changes and then commit them. Also a predefined location reduces the risk of typos, of missing leading slashes, etc. 8 ) Where to report bugs/issues/requests? In the PW issues repo? Here in this thread? Somewhere else? 9) When editing a page in a modal (just add &modal=1 to any page edit form) there is a lot of unused space at the top: 10) On the page tree I think it is ok to have the action items text-only in this case (though I'd probably prefer the old style here): But on the trash we have some text followed by the action buttons and there this text-only style is really not good imho: 11) +1 for this: I'm using #0a2b99 for the primary color and links are near to not readable in dark mode: 12) @ryan As you can see in the screenshot above when using dark mode I'd probably want to change the logo to a white version. If that image were an <svg> this would be quite easy to do with CSS, but at the moment it is using <img src='...'> Could you probably update the theme to make it inject SVG markup for the logo directly? 13) Regular UIkit <div class='uk-alert'> are not styled properly (they use the default uikit blueish), which is even worse in dark mode: Thx!