Leaderboard

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.

I already got used to the new toggles. In some cases though they still feel wrong. Like in the example above. Also note that the description clearly says "Check the box next to ..." That means we'd also need to change descriptions across the admin. And we'd need to ask all the translators to update their language packs as well. I think a better approach would be to let checkboxes be checkboxes unless they are whitelisted to be converted to toggles (eg by applying a class like "pw-toggles" to any parent dom element).

Hi @tires Please go to modules > Core > Page List and check this box. Gideon

Thx and sorry for the confusion. It was probably not the best example. Thank you for adding those. What I wanted... Not really. To be honest I just wanted to show why I think the approach you took with this theme is fundamentally wrong. Admittedly, some of my posts lately have not been very constructive, and I apologise for that. The thing is: As you can tell I'm heavily invested in ProcessWire. I don't understand why such fundamental decisions are taken behind closed doors. Why you (Ryan and Konkat) didn't reach out to the community upfront. I even asked Ryan to connect once he announced that someone is working on a new theme. It didn't happen. Why has it been a mystery who is working on this? It's some awesome goals you are tackling. Why not tell that upfront? Why not ask for feedback, concerns or help? Why not just create a module, like everybody else did in the past (AdminThemeBoss, AdminStyleChroma, etc.)? That early adopters can test, provide feedback and maybe think about some decisions before it is too late? I have been on the dev branch for years without any big issues that I can remember. I have always had a lot of trust in the dev branch. Ryan has always been very careful about any new additions. Very careful about not breaking any existing installations. Now that changed. Suddenly we had a new default theme. A theme, that turns checkboxes into toggles. That causes my modules to break, at least in dark mode. All of that enabled by default. And with all the context from the past I had the impression that there must not be much interest in feedback from the community - why else would you develop everything secretly? I'm sorry if that was a misinterpretation as you seem to be open to feedback. I'm just sad as it seems to be too late now for many things. Adding overrides one by one as they pop up still does not feel good, sorry. But I try to be more constructive with my feedback in the future.

I think it's important to acknowledge where ProcessWire is positioned relative to alternatives. As someone who is 67% designer and 33% developer, and an open-source enthusiast, I love ProcessWire. The API is intuitive and the documentation is excellent, making it easy to pick up and run with. I'm delighted by the attention to detail and the friendly community. Unlike Kirby, it's truly open source. I want to build every website with ProcessWire, but I don't. I use ProcessWire when a client needs a multilingual CMS and has the budget for a custom front-end. For everything else, I reluctantly end up using WordPress with Bricks Builder and Simply Static for easier-to-build, secure sites that need a CMS, or Webstudio for easier-to-build, secure sites that don't need a CMS. If ProcessWire had a RESTful or GraphQL API that didn't require extensive work to implement, I could pair it with Webstudio and drop WordPress in many cases. But it doesn't. As much as I wish otherwise, I don't feel like I am an ideal ProcessWire user. Today, I think that user would be someone who meets most of these requirements: Someone who can build a site faster with code than with a visual builder Someone for whom multilingual support is necessary Someone who wants an open-source solution Someone who already knows PHP or wants to learn it (the "kids" are all learning JavaScript first) Someone with the power to choose something new or unknown (no one got fired for choosing WordPress) A new website will help the project better reach those who fit this profile, and I'm excited about that. What we need to ask in all soberness, as well, is how many of these people exist today and will in the future. If this is not a growing audience, the product may need to evolve into something more people are seeking in the first place to restore the growth ProcessWire had in the past. One could do so by creating a first-class experience for those who could use ProcessWire alongside static site generators to attract a whole new audience where commercial options are prohibitively expensive and community options are limited or abandoned. Leaning into the best of a kindred JS framework like Astro could make ProcessWire a landing place for those coming from that very popular ecosystem or tempted to go there. Perhaps ProcessWire should depend upon third-party modules for some of this, but if that be the case, then let's make it easier for those creating them to commercialize their efforts or better surface those modules that are actively being maintained or at least known to be compatible with the latest release. A new website is a huge step, and I'm excited to see it take shape. You all are so generous with your talents and have been a great blessing to me. So don't read this as some big complaint or demand. I just love the product and the community, and want ProcessWire to succeed. I hope this perspective leads to some thinking in other areas. Like I said, I just want to build every website with ProcessWire! 🙂

Good point about the description. I already talked to Ryan about the toggles. We will most likely go back to regular checkboxes as the default (most seem to prefer checkboxes here).

The term @ryan is referring to is called "Design by committee". Here is what Gemini says about it: "Design by committee" is a pejorative term used to describe a project, product, or design that has been created or approved by a large group of people (a committee), where all input is treated equally and decisions are made by consensus or compromise. The common saying, "A camel is a horse designed by committee," perfectly encapsulates the idea: the final product often lacks a clear, cohesive vision and can be over-complicated, ineffective, or even nonsensical, as it tries to incorporate every individual's idea and preference.

I am a big UIkit user too so I might be biased but I kind of share this sentiment! Maybe something we could work out as a community it to have a clear pathway to handle UI in the admin, so in order of "theming relevance" (?) have something in the docs that explain this pathway: jQuery UI CSS UIKit Less compiling of its theme (eg. keeping the UIkit's flavor of dark mode to keep the rest of components that are not used in the core admin UIs) ProcessWire theme CSS variables Aside from the visual nuances, I think having this part as organized as we can will benefit us all since all parts are useful in their own way! Then again, thanks for all the work put into this!

Thanks @jploch for your time, the thoughtful perspectives and the in-depth explanations behind the new theme direction. I’d like to add that – regardless of trends like monochrome color palettes – there are universal usability best practices, especially when it comes to complex interfaces. Renowned usability experts like Jakob Nielsen have shown that color differentiation and clear visual hierarchies are crucial for orientation, error prevention, and efficiency. Relying on just one color (even with accent tones) can make it harder for the user to distinguish between navigation, controls, content areas, and information messages, particularly in a CMS as flexible and powerful as ProcessWire. On the marketing and positioning front, it’s also important to recognize how much the market has changed. Many users today are looking for ready-made, hosted CMS solutions with out-of-the-box themes, rather than building or customizing everything themselves. When ProcessWire started, there were far fewer quality options available; now, even agencies often prefer SaaS CMSs for their convenience. So it raises the question: who is ProcessWire really for in 2025? Is it still mainly aimed at developers and agencies who need maximum flexibility, or is there a desire to broaden the target group? I believe clarity in both design and communication about the intended audience will help keep PW competitive and attract the right users, whether they value flexibility and control, or are seeking quick, plug-and-play solutions. Thanks again for all your efforts and the open dialogue – these conversations are what keep the community strong!

Would you say @jploch that what you want are expressions of functional concerns (e.g. "I'm having a hard time knowing this is expandable", "The text is hard to read", etc.) instead of design preferences (e.g. "Make the buttons bigger", "Make all the text brown")? I suggested at one point that less contrast was easier on my eyes when reading a lot of text, but maybe that was too design-by-committee-like. What would helpful feedback look like?

Recently, we did a lot of testing, including installations on different systems, and in that context, a small import/export functionality proved very useful: New in version 2.4.3: Import/Export Configuration Functions: Introduced logic for importing/exporting user data table configurations using JSON files. Added code to automatically create an import directory (UserDataTableImport/) if it does not exist. The module scans for the latest JSON file in the import directory and, if found, decodes the configuration and applies it to the module settings, removing the file after a successful import. This allows easy migration or backup/restore of configuration settings between environments. The process is very simple and self-explanatory: you’ll find the relevant fields at the bottom of the config page. A JSON file is exported or imported, containing all the settings of the page. We hope all of you find it just as useful as we do!

Quoting a statement from the other thread here, as that explains a lot and with that context I can totally understand why you disagree with me in aligning css variable names with uikit less variables. In that case it's a valid strategy 🙂

I have the TinyMCE editor text area in black text on white background despite having set dark mode. I see from the blog announcement that the screenshot there is correctly white text on black background in dark mode. Do I have to set a dark-mode specifically for TinyMCE somewhere? (Also I had to remove my old customised CKEditor so *perhaps* that has left some crud causing this… perhaps…)

I fully agree on your example of the supermarket, which is something I often mention myself when talking to clients. But nobody would claim that the “classic” ProcessWire theme is too colorful, would they? It is well coordinated and offers enough possibilities to make COLORFUL distinctions if you need them. Deciding between "green, red and yellow button" will always be more self explaining and less prone to errors as deciding between "left, middle and right button" Because you mentioned UIs from OSs, just a small example from the Apple Developer Docs: Having three equally colored buttons at the top left corner would not be that practical, would it? 😉 As someone who has developed many interfaces, I can only say that our user tests have ALWAYS shown that more than one color is needed in addition to black, grey, white, which, as we know, are basically not colors 😉 For us, the new default style of the UIKit Admin theme is currently not a viable option. We’ve decided to hold off until the final release, ideally with the ability to define a secondary color.

Hi @bernhard This is one of the greatest quote I have ever quoted.😄

I hope I suggested aligning css variables and less variables, not uikit classes 🙂 At least that's what I meant! But to be honest I'm not sure about this suggestions either. I think part of the suggestion was to make it feel less wrong. Having css variables and less variables side by side just hurts and having them follow different naming conventions - if any - hurts even more. I probably hoped that having them at least named equally would make it less painful. But if that really worked at all or was even possible to achieve? I don't know. This question should have been asked long time ago. I have raised my concerns regarding css variables right from the beginning by pointing to an open request for UIkit to support css variables from 2021. Anyway - I appreciate your efforts to help to improve the situation! I hope I can add something useful: --dropdown-menu-background-color @navbar-dropdown-background UIkit uses semantic variable names. The component is called "navbar" (not "menu" like you suggest). Here are all UIkit components. Also UIkit uses the term "background" for background colors and "color" for text colors. You are using "--text-color" where - in UIkit - the "text" would be redundant (and thus left away) and the less variable would be something like "@global-color", which would tell any UIkit user that it's the text color from the global component. For an example look here: https://github.com/uikit/uikit/blob/develop/src/less/components/navbar.less @navbar-dropdown-color as another example tells anybody knowing UIkit that this is the variable for the text color of the dropdown (not the background). Now one could argue that this can be confusing for anybody not knowing UIkit, and I agree. I just wanted to mention that these conventions are there and they have been there since 2017, so any change should (have) IMHO be well considered. Following these conventions would make your variable names a bit less verbose (--top-menu-background vs. --top-menu-background-color). Though that alone can be the fuel for a lot of discussion. So I'm not sure what would be best. I still can't believe that we opened this can of worms... On the positive side, what LESS can NOT do: If you have multiple navigations on one page and you want to style them differently (eg one background red and one background blue) you simply can't do that. There is only one variable and that applies to all dom elements using the .uk-navbar class. This is where CSS variables shine! There we could do this: :root { --navbar-dropdown-background: red; } #my-custom-nav { --navbar-dropdown-background: blue; } This could mean that we probably COULD more or less stick to uikit variable names but at the same time have the flexibility to style different sections of the UI differently. Though I wonder how such a setup would be translated to the old LESS based themes. Whatever, it would result in something like this: DOM: <div class="uk-navbar-dropdown"> LESS: @navbar-dropdown-background CSS: --navbar-dropdown-background My feeling is that this would make a LOT more sense then what we have so far. But I admit I didn't think that that through, so there might be culprits. Your example on the other hand would result in this: DOM: <div class="uk-navbar-dropdown"> LESS: @navbar-dropdown-background CSS: --dropdown-menu-background-color Which does not really look beautiful to me 🙂 But maybe your setup works better in real life. In the rock theme I invented the @rock-primary color that sets several uikit variables once, for example. So I understand that we probably don't need a 100% match. As much as I would have loved to help with this, I just fear that any effort in that direction is wasted love (word pun as we won the ESC with that song recently and I have to take this admin theme stuff less seriously ^^). I guess - like you already mentioned - what is likely going to happen is that the new theme will receive updates, make use of cool new features (why wouldn't we) and then the old ones are going to die, which means many of the 1200+ modules in the modules directory will have to be checked and updated or will sooner or later break or at least look ugly in at least one theme. I think that's the reality that we are facing. To be fair: I have spent many hours already in the new theme and all technical implications and flaws aside I have to say I like it. I like many aspects, and it definitely looks and feels more modern. Maybe this step was necessary and maybe many new users will join our community. Maybe many of them will buy my modules and messing around with those new css variables and overrides will pay off one day. Who knows 😄 It's just that I didn't choose ProcessWire to make a lot of money. I chose it to enjoy my job.

@Morphosis, the value of a populated "single" Page Reference field... ...is a Page object. So it's redundant to get the ID of the Page Reference field value and then get the Page object from the ID, because you already have the Page object. So you probably want something like this: // If the Page Reference field is populated (i.e. its value is not a NullPage having an ID of zero) // and there are some images uploaded to the selected page if($page->gallery_cta_source->id && $page->gallery_cta_source->gallery_images->count) { // Then output the images foreach($page->gallery_cta_source->gallery_images as $image) { // ... } }

Have you tried a simple var_dump($int); exit; after your third line of the last code block in your template file? Then I would to a $match = $pages->get('id=' . $int); var_dump($match); exit; to see if your result is a null page or a match. For debugging I would install Tracy Debugger from the PW module repository and then just add some bd($object); calls to get an idea of whats going on.

I would like to echo the request to get back proper checkboxes. ProcessWire provides distinct inputfields for checkboxes vs. toggles, so I'm confused to find that all of them now look like toggles. It's rather unintuitive and, as Bernhard mentioned, not amazing for module developers. Not sure what problem the global switch to toggles was solving, but I don't think there was a problem to begin with. Checkboxes are great, toggles are great, let's keep them separate 🙂

@Mike-it some steps: Double check that you've picked the correct "Free" or "Pro" subscription type on the module config page. This is an issue with a DeepL account, API key, or a Free/Pro setting. If you receive that error again, next to the "check credentials" there is a +2, click on the chevron-down and see what the additional message is that may be hidden. There is only one place in the module that can return that error message and it is based on the HTTP response status. So in that case, DeepL is indeed returning an HTTP 403 and Fluency is just relaying the information. The error message you're seeing is the "polite" message from Fluency. Any errors returned by a translation service are logged so there may be a more specific message in the fluency-engine log if DeepL provided one.

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!