Leaderboard

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.

@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.

Hey everyone, I'm excited to share my first module WesanoxFrameworkPackage — built to simplify my workflow and experiment with some ideas. Description: Included Frontend Libraries - These libraries are bundled and loaded automatically (if the files exist): AOS 2.3.1, Swiper 11.2.6, Bootstrap 5.3.3, jQuery 3.7.1 All files are stored in the module’s internal /styles/ and /scripts/ folders. How to Use Add the following lines to your template files: // Outputs <link> tags for CSS assets echo $modules->WesanoxFrameworkPackage->renderStyles(); // Outputs <script> tags for JS assets echo $modules->WesanoxFrameworkPackage->renderScripts(); I'm always happy to improve things, so feel free to share your thoughts or ideas — and thanks in advance for any support. 🙂 Edit: I missed the links – I'm sorry: https://processwire.com/modules/wesanox-framework-package/ Github: https://github.com/wesanox/WesanoxFrameworkPackage.git

In my opinion this would be a good idea. I get that the idea was to have an easily themeable look. That's a good goal. But — again, in my opinion — real world use cases are pretty much bound to bring in situations where more specificity is required, so we may have some work to do to find the sweet spot between control and simplicity. (By the way, I am not dismissing Bernhard's worries or the points he's made. I'm not particularly familiar with Uikit, so can't say if e.g. aligning our new CSS variables more with the variables it has would make sense or be feasible.)

Ok so here I am again. Very sorry for that. Maybe I'm overreacting. I hope so! But I tried to go on and work on support requests for my modules just to get confronted with the next missing override (uikit progress bar) a few clicks later 😞 So I went ahead as requested and created an issue on github to collect and report all problems caused by missing overrides in the new theme. While posting this screenshot I realised something concerning though 😞 Now I'm wondering: Why are these elements actually showing up in RENO green? Why does that matter so much? Some background... So with all the context I can't believe it 😞 That's why I got so concerned when seeing these elements showing up in RENO green. (and not in the default UIkit blue from the global PW base style without any overrides applied) IMHO it shows a design layer that should not be there which shows what I'd consider to be a fundamental problem with the approach that this theme takes. So I want to add to my list from above: Can the new "theme" please use the base style (pw.less) as a foundation? I fear that the more layers we have that override each other the more complex and the more prone to errors it will get Is there any chance that the new theme properly uses UIkit hooks to add support for CSS variables instead of overriding everything? I think that the readability and the long time maintainability of the new theme would benefit a lot from that. Especially when the same convention for variable names is being used (which I already asked for).

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.

Thanks a lot, @ryan, for posting such detailed examples! I agree with many of the concerns regarding having multiple “style” layers stacked on top of each other, as well as what @bernhard wrote about “reinventing the wheel.” It reminds me of the horrible experiences we had when a client decided to purchase a “professional” Bootstrap theme… I counted four different style systems overwriting each other countless times. It was a mess to work with and almost impossible to make any changes without writing a lot of extra code. We’re still experimenting with the new admin style, showing it to some clients and collecting feedback. The main response we’ve received so far is that everyone felt somewhat uncomfortable with the non-white background (“dull”, “depressive”) and missed the colors on the input elements. What everyone did like were the productivity improvements like the fixed navigation and the hover-toolbar in the page tree. Maybe I’m wrong—time will tell—but from a strict UI designer’s standpoint (which is my profession), the hype around “dark modes” introduced by operating systems is… well, just hype when it comes to software like a CMS. Most “regular” users are happy once they’ve learned an interface well enough to complete their tasks. If that interface suddenly changes just because it gets dark outside, it’s… let’s say, at the very least, irritating. Lastly, I think there’s a typo in the custom CSS example linked in the admin style config: /* -------------------------------------------------------------------- */ /* ---- THEME WITH COLOR MASTHEAD VARIABLES -------------------------- */ /* ---- (these depend on the default theme variables) --------------- */ /* ----------------------------------------------------------------- */ :root { ... --masthead-menu-item-backgroud-hover: rgba(255,255,255,.2); } I believe there’s an “n” missing—shouldn’t the variable be like this? --masthead-menu-item-background-hover Cheers to all of you—have a pleasant and productive week!

That sounds too good to be true. I'm not sure I understand how that is supposed to work, for example: Does that mean that the sticky navbar, which is great, will somehow also be moved to the base theme to make the rock and reno themes benefit from that addition as well? Does that mean that the CMD+K hotkey will be moved to the base theme as well? If that is the case, I apologise. Because then it means that I misinterpreted the current setup. My interpretation from what I saw in the code and folder structure was that there is a lot of stuff going on in the new theme that seemed to me like it was designed to be part of the new theme only. Sorry @ryan, but this does not work! If you have a <button class='uk-button uk-button-primary'> anywhere in the backend the hover effect that you showed will not be applied to that button. If that's expected and "uk-button-primary" is not supposed to be used, then it would be great if you could add docs about how to add basic UI elements like a primary button to the PW backend in a correct and reliable way. Thx. Sorry @diogo but what might look like a simple line of css to you is actually much more. First, I can't just fallback to #000 when supporting other themes (like reno or rock), it needs to be a LESS variable. So it would probably be something like var(--text-color, @global-color). This also shows why I think it would be great for module authors to have css variables and uikit variables at least follow the same naming conventions, if we have to support both from now on. Second, this line of css is one line that was not necessary before. This might mean for many modules that they need to provide a CSS file now. Still sounds like I'm making a mountain out of a molehill? I'm not. Having to provide no css file compared to 1 css file means that we need to deal with a lot. We might need to add an additional build step. Maybe even an automated CI workflow. Or we need to add a dependency (like RockDevTools) that watches our LESS assets and compiles them to CSS that every module user can use without any hassle. These are all a lot of costs. I'm just wondering whether they have been considered. @diogo you are taking my example out of context! I was trying to explain the problems that evolve from the PW backend using different classes for different things (ui-button vs. uk-button-primary etc). And your out-of-context reply shows me that there seems to be a blind spot about the fundamental problems that we are facing now. UIkit has hundreds of classes. My point is that trying to override them instead of actually using them is a very bad idea! So please try <h1 class='uk-text-primary'>Hello World</h1> This is what I mean by the cake does not taste. Having to file github issues for all UIkit classes that are not yet "properly" overridden by the new default theme is... Not elegant. It's not what ProcessWire has been for me for such a long time. It's not fun. --- PS: Don't want to restart the discussion about details here. I just tried to respond to answers that are related to and underline what I wrote above. For me it's not about details. For me it's about the bigger picture.

What we are doing here is basically reinventing the wheel. We are trying to invent a new design system that makes it easy for developers to be used and to be customised. But we already have this design system. It is called UIkit. It is in the core. It is built on logical and semantical components (base, text, buttons, background, utilities, ...) and it has thoughtfully defined and well documented (!) variables and concepts. Yes, it uses LESS (or SASS), which is not the coolest technology on earth. But this decision has been taken by @ryan in 2017. If the decision was that CSS variables are superior and we proceed with them: More than happy! I'm using CSS variables all over in my projects (on the frontend). But keeping UIkit/LESS as the foundation and then adding a new theme with 3200+ lines of overrides just does not fit with the genius and beautiful image that I have had of ProcessWire. To me it looks like somebody was decorating a cake here. Adding layer over layer to make the cake look good. For me it just doesn't taste 😞 It never really did (ui-button vs. uk-button-primary, etc), but it was ok. It was the reality that I grew up with. Now it's different. Now things got a lot worse and I think this was not necessary. I guess I was hoping that all the effort that was put into a new admin style would bring some fundamental improvements of the overall situation. @ryan, you have pushed so many great updates over all those years and you have solved so many problems in a way that just left me behind with deep respect and amazement. Now we have yet another layer of complexity to deal with when working on backend modules. I'm not happy this time 😞 I appreciate all the effort that you put into making PW attract new users and I understand that it must be frustrating to get such a harsh feedback by some of us. Especially after putting so much work into it. The thing is: It did not have to be like this. Why not ask the community upfront? Before all the work has gone into it? To have an unbiased view? To keep the risk and emotions low (for everybody)? To hear what others might think of such a fundamental change? To get feedback and maybe even good ideas? Or to explain what is considered to be fundamental and what is considered to be experimental? The question is: What now? The decision was obviously taken long time ago, so I guess we have to deal with it (even though I think it would be the best to take it back completely). If you ask me - as a long term member and contributor - what I'd like to see to make things less painful for now and make things better long term, here are my suggestions: make the css variables used in the new theme be aligned with UIkits less variables (--main-color vs. @global-primary-background ...) remove dark mode completely, or, at least, disable it by default and add a warning that it is experimental - I think it will cause 99% of work for very little benefit add docs for the new theme and the concepts it uses rewrite the whole admin theme/framework from ground up with a modern stack (css variables + Alpine JS + darkmode) as soon as possible Thank you and all the best for the future of ProcessWire

I really agree with @teppo here - setting css vars outside of the root context seems dangerous. I am not expecting an infinite number of css vars, just not reusing of ones that don't seem semantically correct, like my example of --masthead-active-color also being used for all submenu items and --muted-color being used for hidden pages along with page list actions. It honestly feels like --muted-color may as well be called --light-grey in the sense that it's describing a color, rather than a usage which defeats the flexibility of css vars. I'd be happy to compile a starting list of the vars that I think we need (and what they should be used for) and then have other passionate and skilled folks her chime in to help refine. I think with a little brainstorming we can end up with something really powerful and flexible and all defined at the root level.

https://www.youtube.com/watch?v=EoEeRWHJ8xs A checkbox is a checkbox and should not be confused with a toggle, I think. A toggle is not a skin for a checkbox. https://infyom.com/blog/user-interface-design-tips-checkbox-vs-toggle-switch/ https://uxdesign.cc/the-good-the-bad-and-the-toggle-2abc0fbbd099 Quotes: A toggle switch requires two steps: selection and execution, whereas a checkbox requires only the selection of an option, and the execution/saving action is normally required later or at a different area. Usage recommendations Do not use toggles in forms. Use checkboxes or radio buttons instead. Do not use toggles in filters or multiple selections of elements. Inhale. Use toggles for settings and changes that have an immediate effect on the UI (same applies for the segmented control). Avoid mixing toggle button groups and segmented controls. Exhale. Avoid using switches with multiple options.

@ryangorley Thats a really nice website! I also like the 3D assets. I am not sure if/how 3D will fit with our current design approach. But I will keep it in mind and discuss with the others.

Hi nice post. Just missing the content somehow. Would be nice to post a link to the PW modules directory with your module or at least to your Github (or similar VCS) repository. But the code examples look great by the way 🙂

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.

Ah, almost forgot about the toggles vs checkboxes. Independently of what is decided concerning the usage of toggles, our css selector is clearly too aggressive and id trying to turn, into toggles, some checkboxes that should be left alone. We’ll need to fix that. Funny, just before submitting, i noticed this 😆

I know this is the intention and I understand how the new one depends on it, but even if it remains that way indefinitely, module authors (in particular @bernhard) are already having to deal with differences between the two - will he support both or at some point give up and only support the new? At some point new modules will come along that only work with the new theme and so those of us using the old one will have unusable modules. Software changes and in my experience you need to upgrade to the latest implementation sooner than later because at some point it will bite you and the longer you leave it, the more you will need to do to fix things.

In your specific case, you would style the headlines with color: var(--text-color, #000); This will use the text color of the light or dark theme, and default to black, if the variable is not present. For the "today" and "left / right" buttons you can use background-color: var(--button-background); color: var(--button-color); // and for the hover state background-color: --button-hover-background color: --button-hover-color Adding <button class="uk-button uk-button-default">normal button</button> <button class="uk-button uk-button-primary">primary button</button> styles the buttons correctly for me It's true that this is a skin on top of Uikit, and we inherit the decisions of Uikit to style every single element individually instead of inheriting colors. This means that you can use Uikit elements, but that their colors will aggressively try to override ours. This works well in most part for light themes, but, in your case it is breaking on the dark theme. There are two things we can do simultaneously to mitigate the problem: 1. switch to a dark uikit base for the dark theme. 2. override the uikit color with our variables for at least their most important components. For now, the most reliable way to style markup that you add to the admin, is to do what I described before for your calendar.

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 🙂

I think this has already been reported but can't find it. There is a really bad FOUC on smaller screens - the top nav shows before being hidden for the hamburger menu. Also, the close button on the hamburger menu is broken. And another crazy css variable reuse --main-background also determines the background color when hovering over menu items in the hamburger menu. This doesn't work with the colors I am trying to work with.

--muted-color is also used for the page list action links but these should be highlighted, not muted. But regardless of what you think they should look like, they definitely shouldn't be tied to the same color as hidden pages. And is there a reason it's --muted-color and not --muted-text-color?

Sorry to keep going, but we desperately need more css vars. --blocks-background controls the color of so many things it makes it effectively useless. It impacts the top nav, the actual field blocks, the color of button text (what's with that?), the page list actions hover bar, and probably more. I love css vars (I never jumped on the less/sass bandwagon), but they only work if they are distinct enough to modify everything as needed because if we need to mix and match between css vars and class/id targeted overrides it becomes an awful mess very quickly and things will surely get broken with future PW changes. I really am trying to figure out a way I can turn on the new theme for users because I know that it's only a matter of time before the old one is no longer supported (that's not a slight, it's just reality when there is limited time and resources to maintain things). I really wanted the background of the main nav to be darker color with white text, so went with: :root { --main-background: #FFF; --text-color: light-dark(#444, #efefef); --muted-color: light-dark(#999, #efefef); --masthead-text-color: #FFF; } #pw-masthead { background-color: #c3d152; } but you end up with the placeholder for the search box white as well. I am sure I can override that as well but my point is that it gets messy fast without more specific vars to work with.

If what I said above describes your situation, I have tested and the following works. I used the HTML5 datetime picker, TIME only. ProcessWire will default to a date of 2010-04-08 as mentioned in my previous post, so we use that always, just with different times. $startTimeString = "2010-04-08 09:15:00"; $endTimeString = "2010-04-08 11:00:00"; $courses = $pages->find("template=course,start_time>=$startTimeString, start_time<=$endTimeString, end_time>=$startTimeString, end_time<=$endTimeString"); bd($courses,'COURSES');

My best guess is that it's an htaccess issue - most likely an AllowOverride setting that isn't letting mod_rewrite kick in as needed. If you're not familiar with these settings in Plesk, it might be best to submit a support ticket. First thing I would try is to add some gibberish text to the top of the PW root .htaccess file to see if it's being loaded and go from there.