Leaderboard

Since design is subjective you might not agree that the new theme is actually an improvement over the old one. So let me add some reasons for our design decisions (sorry this will be a longer post): The original theme had too much branding: The original theme added a lot of PW specific branding to the backend. The 3 main colors of the original theme add a lot of character and it wasn’t very subtle with it. Since the CMS is used to create websites/apps for clients wich have their own branding, there was a clash. I think this is also one of the reason why people went to such an extend to customize the look of the backend. Of cause you can argue that the look of the original theme was more unique, and I would agree with that. But as described above it’s not the primary functionality for the CMS to promote the PW brand (E.g. Exel is also not promoting Microsoft but rather keeps it look tied to the operation system). I also don’t think the backend needs to promote the client brand either (It won't be used by potential customers, so why push the client marketing here?). Rather it should be a neutral frame that works for any client/project out of the box without the need to customize it a lot (we still want to support customization as much as possible, as everyone uses PW differently, but the defaults should work out of the box). More in line with the new website/brand relaunch: Once we designed the new homepage, we felt that the original theme doesn’t fit with the promises and brand values we communicate on the new website. (E.g. PW stands out of the way, doesn’t force a look on your frontend/backend, simplicity for editors, modern UI, etc.) Improving contrast and accessibility: The original theme had some problems with accessibility. And while we are not solving all of it in the new theme (it would have been to much work for us), we at least improve some of it: Improved color contrasts: Higher contrast between font and background color (better in line WCAG guidelines) Improved text readability: The old theme used a font stack that relies on system fonts. E.g. users on windows saw a different font (Arial for the most part) than users on mac (Apple System Font). Depending on what fonts you installed you might also saw others. The new theme uses the Inter font for all users. Inter was designed specifically for screens and user interfaces. It has high contrast letter forms and a tall x-height to aid in readability of mixed-case and lower-case text. this might seem like a subtle change, but it actually makes a difference especially for smaller text and text in bold. (This is less about if you like the font and more a decision based on functionality). Improved keyboard accessibility: The new theme improves how the tab key can be used to navigate the backend. You can compare the original theme to ours to see this for yourself (eg. you can now navigate the tree with your keyboard). It’s still far from perfect and I think we can make an effort to improve in this area (there would need to be some changes in the markup, especially how the tab-navigation works). We also added a shortcut to open the search, which gives access to a lot of PW’s features, and we think it would be nice to transform the search into a command palette to access other shortcut actions for the CMS like creating fields/templates/pages in the future (think of it like Macs spotlight or Raycast). A more modern look and feel: I know this one is very subjective. We looked at other CMS options out there that seem to be somewhat similar to PW (e.g. Kirby, Craft, Statamic, Sulu, Datocms and others). And we could see a certain UI trend in their backends: They all use a mono color theme with subtle colors + a main color (a trend you find in a lot of UI’s now a days). To me that makes a lot of sense: It is easier to direct a user through an interface and apply hierarchy when not too many elements scream for attention. To me the way the colors where used on the original theme lacked a clear functional direction and instead where more of a decorative distraction for editors. This also seem to align with feedback we got from our clients (at Konkat we used the AdminThemeCanvas for most project since most clients seem to prefer it over the original theme). Fixed and more integrated nav-bar: I think most people here agreed that the fixed nav-bar is an improvement. Some said they prefer that the navigation is more separated from the rest of the design. We thought because the nav is now fixed it actually is already functionally separated from the rest of the UI (once you scrol), so there is less need for separation. Also users are expecting a navigation to be at the top of the page. If we put the nav in an unusual place (which would not be a good idea anyway), then it would make sense to make it more visible, but like it is now we don’t see the need for it. It would also break the concept of the mono color theme. Support for Dark mode: I already said it, I really don’t care much about a dark mode, but other people do and I think it’s a good feature to attract new users. One benefit of the mono color theme is that it’s easier to support a dark mode. But if dark mode creates too many problems for module developers I would consider removing that feature, but that needs to be discussed with Ryan and Diogo. @bernhard I will also discuss your other technical concerns regarding the CSS overwrites, as I think you made some good points. I will check with Diogo and Ryan and get back to you, I am confident that we can find a solution. If we (Konkat) had more time we would have liked to completely redesign the PW backend from the ground up (E.g. we had early concept with a sidebar instead of the top nav-bar, fixed save buttons and other things). But that would also have been a massive change for everyone, so we were going for a more subtle enhancement with the new theme instead. I hope this helps to get some insight on our decisions for the design of the new theme. We hope to improve it further over time so please keep up the feedback and bug reports.

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!

@Mikel I agree with you. The website and the theme/CMS backend have indeed very different functions. To use an analogy: It’s like an advertisement for a car versus the actual dashboard inside the car. Both are designed for very different purposes. Here is how I would describe the differences in our specific case: The website is mainly a marketing and documentation tool. It’s the face of the brand online. It's what our audience sees, interacts with, and ultimately uses to form an opinion about the business/product (in this case the CMS is the product). The design should reflect the values of the brand and is primarily about attracting, informing, and persuading potential users. The design of the theme/CMS backend (the product) is mostly about usability, functionality, and creating a delightful and efficient experience inside the product. The product also needs to be convincing and coherent with the brand values und promises made on the website. While their primary functions differ, the marketing-focused design and the app interface design are not isolated: Marketing sets expectations for the app's interface: If your marketing promises a "sleek and intuitive" app, the app's actual interface must deliver on that promise. Discrepancy leads to disappointment and uninstalls. A great app interface becomes a marketing tool: If people enjoy working with PW it might lead to positive reviews, word-of-mouth recommendations, and higher retention – all good for marketing. Brand consistency is key across both: This doesn’t mean they need to look the same. But they should both reflect the brand values.

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.

Thank you for taking the time to write these insightful answers @jploch! On vacation, and only with the mobile, is hard to keep up with the thread, i feel like I’m getting way behind and missing a lot of stuff. I just want to respond to a post from @bernhard that I had in mind, but couldn’t find to quote. It’s concerning the look of the UIkit buttons. If I took your request out of context, it was not intentionally, and probably because I didn’t understand your question. I just copied the examples from the UIkit documents, and pasted them directly inside a process module, and they got styled accordingly. Just like with the UIkit alerts previously, whose style I added to our CSS, I honestly thought that’s what you wanted. Please just let me know if I was way off in my understanding.

Thanks for the details @jploch about the goals and considerations that preceded the design process. Some things become clearer because of that, while others still interest me, as I can’t fully comprehend them yet. Let’s perhaps first establish that although both a website and a CMS are interfaces, the latter must follow a different set of visual rules. The approach of trying to unify both visually is understandable in the context you described, but it results in a dysfunctional design language for a CMS. A not ideal interface is either too loud or too quiet – like the new theme. What’s missing is clear differentiation between various element groups (navigation, controls, content, info, to name a few). I‘ve been working in the design field for nearly 30 years and am aware of many trends, fashions, and viewpoints. I’m by no means looking to argue about matters of taste – instead, I’m interested in the underlying design philosophy that guided the development of the new admin style. That said, once again, many thanks for all the work that went into this project!

Hey folks, sorry for not responding earlier; I was swamped with work and then got sick afterward. Thanks for all the feedback so far! And thanks again, @ryan, for asking and trusting us to help with the redesign. The discussion seems a bit heated, but that only shows how passionate the community is about PW. I will leave it to @diogo (he is on vacation for a week) and @ryan to answer some of the technical concerns, as they are the ones doing the implementation. Just know that we are reading and discussing them and take them seriously. I want to add a bit of context to our general design approach and goals with the redesign of the theme and PW website. You might not agree with everything I am saying here, and that's fine. I don't claim to be right in all of it; this is just our current approach. We started out by asking questions to Ryan, reading the forum, and identifying problems with PW's current marketing and brand strategy. As well as doing research and comparing other CMS offerings to PW. here is what we found out: PW user numbers seem to be stagnating (not a lot of new users on the forum). PW's marketing mostly seems to speak to developers (= making clients, agencies, content creators, marketers, editors, and designers look for other options). Lately, more and more of our own clients had been choosing other CMS options over PW because they said it looks too "technical" or "dated" (they looked at the PW website). The design of the PW homepage is too "crowded" to identify the most compelling features of PW (= clients couldn't understand at a glance how PW can solve their problems). The PW website lacks recognition (basic UIKIT look) and doesn't look very approachable/friendly for newcomers. The way the admin backend is shown on the website is not very attractive, and the theme itself looks dated compared to other CMS solutions. The look of the website doesn't reflect most of PW's brand values (Flexible, Powerful, Simple, Easy, Friendly, Open, Secure, Stable, Free). And here are some of our goals with the new website and theme design: Attract new users to PW (developers are still the main target audience, but we want to target a more diverse group of users, see above). Make PW more approachable for new users. Keep existing users happy. Make the PW brand more recognizable. Better highlight PW's strengths and key features. Communicate PW's brand values through the design. Improve the docs. Make it easier to find modules. We realized that it would not be enough to just redesign the website, as the admin theme is the "main product." If people check out the new website and we can make them interested in PW, the second thing they do is install the CMS. So it's important to have good-looking defaults for the new theme that are coherent with the new website, as new users won't do a lot of customization. The reason we decided to include a dark mode in the admin theme is also mainly to appeal to new users. I personally don't care much about a dark mode, but for some it's a selling point. This trend can also be seen in other CMSs that now support it. I hope once the website is launched, it will be a bit more clear where we are going with this. Also be aware that we are not getting paid to do this, we did it because Ryan asked us and we love PW. But our time is limited and we have to make the most out of it. We will probably not achive all of these goals immediately, but we hope to set a good direction for things to come.

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! 🙂

@diogo - that's a kind suggestion, but I don't honestly think that is the right route to take. I strongly believe that we all need to move to adopt your new theme to avoid issues with some users being on the old and some on the new. Despite all the assurances, I am still certain that the old theme will be problematic at some point with core functionality and/or some new modules. I think we just need some refactoring (to prevent the reported issues with the core and modules) and other bug fixes along with more distinct css vars so that any aspects of the new theme's color scheme can be modified easily and so that these css vars will work in the future should PW ditch UiKit at some point.

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

After using the new style/theme from the dev branch for about a week now, I switched back to the default theme from the main branch recently. I wasn‘t able to adjust to the light grey background and the reduced colors on input elements or background of notes and messages. However I guess I am not the intended audience to be attracted by the new style/theme either. I only use dark themes when it comes to VS Code Editor, all other Apps stay in light mode. But that was only after finding a dark color scheme, which pleased my eyes, which took about half a year of trial and error. The 15+ last years I used light themes for coding too. Only setting I do at night is to dim the iPad display for reading. Usually I stick with the defaults offered by the OS system or Apps, as I do find this look the awesome my Posh terminal adjustments just a waste of my lifetime. So I would not bother to have a new light style/theme which covers the edge cases for the most popular modules and pro modules out there and see the dark themes more as a yes we have that too, but it might be involving some tweaks of the CSS to get it working with the modules out there. Hope this won‘t lead to a split in the community or the leaving of PW supporters and module authors out there, as it could be seen on other CMS/CMF systems before. So keep up the good work, just setup a list with reported (real) issues - ideally focusing on light themes first and try to keep out personal preferences as good as possible.

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/

Thank you very much. This adjustment also fixes admin emails being sent when errors occur. Awesome!

Maybe this should be an option in the default theme?

Ah, also, I’m happy to isolate the fixed menu and command palette css and js into modules that can be used with the original theme.

While truly "mono-color" in the strictest sense (only one hue, with only black, white, and gray variations) can be rare for an entire complex web app, many apps employ a highly restricted, minimalist color palette that leans heavily into a single primary color, often with neutrals (like what we do with the new theme). In our theme we have one primary color, but also other colors for alerts/warnings, for code, notes, etc. We also establish hierarchy and contrast through color shades (from light to dark), inverting color (dark on light becomes light on dark), form (E.g. round vs. not round), icons, typography (different sizes, bold/regular), spacing (to group items) etc. Using too many different colors can also have the opposite effect and cause a sensory overload (E.g. in a super market, where everything screams for attention, some of the more subtle designs can stand out more then another red box among the others). There are many successful examples of good working mono color UI’s (not in the strict sense, but mostly neutrals + primary color), from very complex systems like operating systems (eg. MacOs/iOs, Windows, Android), most desktop apps and a lot of popular web apps (E.g. Youtube, Google Docs, Gmail, Netflix, etc). Thats a good and very important point. We where also discussing with Ryan how the CMS landscape changed and where we see PW fit in. It seems there is still a market for a CMS like PW. Take Kirby for example (they clearly took some inspiration from the PW API and they have a similar audience), it's thriving (at least here in Germany). I think that also shows how important marketing is, and that they are doing a good job with it.

Thanks for pointing that out! I think we should also apply the new theme to the frontend editing UI. Will put it on the list..

Hi @jploch, Great work on the redesign so far. I don't think it has been asked yet, but just wondering if any of the design changes are being applied to the frontend editing UI or is any particular details being looked at on this?

Hey @bernhard, thank you for your input and for taking a deeper look into my module. I’ve adopted your suggestions right away.

@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) { // ... } }

Hey @wesanox congrats on your first module 🙂 I just had a very quick look and saw that your module is "autoload": https://github.com/wesanox/WesanoxFrameworkPackage/blob/b50d538b48f295133cf654838b6002cd0c006c4a/WesanoxFrameworkPackage.module#L19 Autoload means that it loads on each and every request even if you don't use it. I think you don't need this in your case. On the frontend you request it with $modules->WesanoxFrameworkPackage anyhow and on the backend I guess you don't need your module to be loaded? Oh, and I think this line is also not needed 🙂 It only tells PHP that "implements Module" refers to "Module" in the ProcessWire namespace. But since you have "namespace ProcessWire" at the top of your file "implements Module" will be enough, because no use statement means it will use the namespace of the file, which is ProcessWire.

@jploch Thank you for this background, and these are awesome goals. Thank you as well for doing this on your own time. If you want to take a look around at the Thunderbird website we worked on a few months ago and see if any comparable 3D assets would be of value for the PW site, let me know. I don't know if it's compatible with the aesthetic, but I'd be happy to contribute the hours to create those for the cause.

I agree with a lot of @bernhard's issues, but if I am understanding his suggestions about aligning CSS vars with UiKit's classes, then I don't agree with that suggestion. I think the CSS vars need to be agnostic in this regard (for when PW moves away from Uikit at some point). This is why I am wanting things like: --text-color --text-color-hidden --text-color-active --text-color-hover --top-menu-text-color --top-menu-background-color --top-menu-text-color-active --top-menu-background-color-active --top-menu-text-color-hover --top-menu-background-color-hover --dropdown-menu-text-color --dropdown-menu-background-color --dropdown-menu-text-color-active --dropdown-menu-background-color-active --dropdown-menu-text-color-hover --dropdown-menu-background-color-hover Same for button text, color, background, border-radius including hover state, etc. It's really not that many but will mean that we don't have situations like where --blocks-background is used for the text color of a button. I haven't put proper thought into these yet, but hopefully you get the idea. And, definitely no vars that reference other vars meaning that you can't override one without affecting the other. There are actually a lot of good articles online for css variable best practices - I know I need to read more about this.

@JayGee Happy to hear the module is useful! I haven't used page breaks before so I hadn't tested that. Since diving further into htmx driven FormBuilder forms outside of this module I've recognized a few places where it can be improved. Another item that needs to be handled is file uploads. Work keeps me from doing things so I won't be able to handle this immediately. How critical is the issue for your use case? MarkUp Regions shouldn't be a problem so no worries there AFAIK.

The "setHeight" function sets the height of a filler div to equalise the height of inputfield columns in the admin, so everything looks neat and tidy. I like this and the overall attention to detail in the admin UI, but I've notices a couple of issues with this method of equalising columns. 1. The function fires on document ready but this doesn't allow time for CKEditor fields to load and these can change the height of a column by quite a bit when loaded. Perhaps setHeight should fire on window load instead of document ready? (Edit: I tried this and it doesn't solve the issue. Probably needs to fire on a callback from CKEditor). Or perhaps a CSS-only solution could replace this Javascript approach, utilising display:table-cell or flexbox? 2. The function fires even when the viewport is narrow enough that the layout has switched to single column. In this case the heights don't need to be equalised because the columns are stacked on top of each other, and the extra filler space looks weird. This issue affects the Form Builder module too, where the filler div can cause the form to expand beyond the height of its iframe. I cludged together a CSS fix for this like so... @media only screen and (max-width:767px) { .maxColHeightSpacer {display:none !important;} } ...but it might be better to use something like enquire.js to make sure the function only fires above a certain breakpoint. Edit: just discovered another small issue... 3. The function doesn't fire after images and files are added to a field, which of course changes the height of the field. Is there an AJAX callback for image/file uploads I can use to retrigger the function? Any thoughts?

What about this? $wire->addHookAfter("Pages::added", function($event) { $page = $event->arguments(0); // check for page template if necessary here $page->setAndSave('check', 1); }); PS: Did you see @Robin S module?