Leaderboard

Actually, in case anyone is interested, this is my current complete setup. I've given up on the colored top nav because it really doesn't add anything and in reality does look kinda ugly :) :root { --text-color: #444; --muted-color: #999; --button-radius: 10px; } .ProcessPageList { --main-background: #FFF; } .PageList .PageListActions a, .PageList .PageListActions a:hover, .PageList .PageListerActions a, .PageList .PageListerActions a:hover, .PageList .PageListMoveNote a { color: #fff; border-radius: 3px; background: var(--text-color); padding: 2px 6px; font-size: 12px; font-weight: bold; line-height: 1.4; text-transform: none; display: inline-block; } .PageList .PageListActions a:hover { background: var(--main-color); } h1, .uk-h1 { font-size: 1.6rem; } This results in: @ryan - this still needs fixing though: But, otherwise pretty happy. Toggles and dark mode are disabled in config.php and we still have branding accents, no horrid grey background for the page tree (sorry KONKAT) and my eyes aren't bleeding from the #000 text 😁 Not sure if everything is perfect yet, and I'd rather not have to override CSS vars at non-root level, but it's time to move on and enjoy the fixed nav, scrolling fields and templates dropdowns although we still do need the dropdowns to have a higher z-index than the top-level menu so that Tracy panels can slot into place like they used to. @ryan - is that something you could look into please?

This should be a fairly easy fix. Thanks for reporting it!

One of our test users of the new admin style informed us that there is a minor visual bug on the "close" button of the slide-in pagetree. As I was able to reproduce it, here you can see the issue: Also present when hovering the "close" button

I'm currently looking at Grav/Kirby/Statamic etc. for certain simple sites where MySql doesn't make sense, but I'd much rather use PW with SQLite.

@adrian I'll read and reply in more detail later but that turned out nicely! It looks great

I'm of the opinion that this is highly opinionated. 😉 One might say that ARIA rules are a waste of effort because the majority of people realize it's not actually a better experience for user interfaces. It's all personal perception. From my own experience, I find that building a template from scratch with having a toggleable (or auto-determining) dark-mode and light-mode in mind is far, far easier than starting with a light mode as a main default, and then trying to tack on dark mode functionality. KONKAT's determination to go primarily monochromatic should make that quite a bit easier, but it's still not easy. And getting dark mode right so that it feels fresh and elegant to a wide population is quite difficult. That doesn't mean that dark mode doesn't have its place though, and that - to feel modern and accepted to a wider audience - it may be a feature that perspective CM(F)S users would look for, whether they use it or not. If nothing else, it's a marketable feature. We'll have to see if KONKAT will expand their CSS variables so that adjusting one color doesn't affect colors of other areas that wouldn't normally be affected. I need to install the dev branch soon so that I can provide some proper feedback and comparable override solutions. I suspect KONKAT is using the cascade with their CSS variables in a way that works, but can cause situations as you're showing above, adrian. (And these are useful things to discover!) CSS variables are great, and they make things quite a bit easier, but there are, and may, be times when you'd need to (or want to) more specifically target the cascade when overriding CSS vars. I suspect most of the issues here are related to that - just needing slightly adjusted CSS selectors, or some additional ones. One thing to note when overriding the CSS - from one of Ryan's prior posts I learned about the new light-dark() CSS method which is awesomely useful for CSS themes that take advantage of light and dark modes. If you're forcibly applying a static color regardless of mode (for branding, perhaps) like Ryan's last example for the masthead, it's less imperative, but for other areas... If you want to make sure older browsers continue working as well, you might need a fallback value, just in case (the light-dark() method came about in 2024).

Hi @teppo, I have a FieldsetPage field that I would like to index (including its subfields like Repeater, RepeaterMatrix...), but the field is not listed in the backend under "Select indexed fields". And consequently not indexed, nor the fields it contains (that are in the list of fields to index). Using the latest version, 0.38.6. Am I missing something? Thank you. Problem solved, I forgot my compatible fields override. Sorry for the noise.

Thank you. Thank you.

@bernhard We value your input very much and I think you are a blessing to the PW project. But currently I am focusing on covering the general design concerns. Since Diogo is out of office I would like you to give us some time for a proper response. But let me quickly address one of your main concerns. I agree that we should make an effort to keep the CSS layers as low as possible, at the same time I see a lot of benefits of CSS vars (also for module development, e.g. for PAGEGRID in my case, we can get into that later). Initially Diogo had the idea to base the new theme/skin on the stripped down version (without the reno-less files) you are using. I'm not sure what impact that had at the time or why we didn't do it. And maybe there's something I'm not considering at the moment, but to me it makes perfect sense to remove all Reno styling from our theme and use the base UIKIT as a foundation.

Serious question: If it's not too late for anything, then why is feedback like this not considered to be helpful? What I tried to point out is that when using UIkit like explained in their docs, then we would not have these issues at all. To change the primary color all you'd have to do is this: @global-primary-background: red; Then all primary buttons will use that color. All progressbars will use that color. All UIkit components will use that color. And any component that they might add in the future will use that color as well. Which means that any developer in the world can not only use what the core uses but anything UIkit has to offer. Framing that as "features that ProcessWire traditionally did not offer" is what I consider as not being helpful. We, on the other hand, are using thousands of overrides at the moment. Anything that Diogo didn't think of will possibly cause issues. Cause frustration or ugly fixes on our side and cause Github issues on your side and I think your time can be spent better. Seeing reno green shine through tells me that the new theme must be extending (if you don't want to call it overriding) the reno theme and not the base theme, that I carefully split apart from the reno theme in 2021 to make exactly that possible: Properly extending the base theme without applying layer by layer of overrides. Exactly like you mentioned with PHP classes. What I see in the new theme does not match what I read in your announcements and explanations, sorry. I consider that to be a very valuable feedback for anyone that is open to hearing it. Unfortunately for many reasons I got the impression that it's too late for such input. And I understand that this is a difficult situation. That's why I apologised. It does indeed not help if anybody complains about fundamental issues if it's not possible to change them. I get that and as I said I'll try to be more constructive with that situation. But please don't pretend that it's not too late for anything and that we are at an early stage in the process. This feels dishonest to me on my cost. Obviously I also do not think that micro-managing a professional designer would be helpful and that's not what I have been suggesting. I just don't see anything wrong in asking the community for input upfront. At least that's what I did with my calendar module and I think it was a very helpful and pleasant process: What features should a PW calendar module have? The community was just as great as it has always been. It does of course not mean to ask the community to decide every button's color. But it might help to reduce the risk of having blind spots. It might make the process even more creative, not less. It might help in making the community feel heard, accepted and valued. And it might even help in saving development time by cutting on features that sounded/looked cool at first but raised serious concerns in the community. And one more thing about the term "secret": You have some good evidence here. It was not my point though, and it might have been more constructive to ask me what made me feel like that than proving me wrong. I know I'm not the only one feeling like this. English is not my first language, but that sounds ironic to me and I'm not sure if it is the best time for being ironic after I apologised. I'm not sure how a user will feel when using dark mode for everything and some pages suddenly appear in light mode, but at least this means that it's no longer a go/no-go decision when somebody wants to use one of my modules, so thank you for that. Do i interpret this correctly as that darkmode is not any more considered to be experimental and is here to stay? --- @ryan please be reminded that I still very much admire what you have built and achieved. I'm sorry that you have expected a different feedback. But I hope it's ok to not only cheer if we like what we see but also raise our voice if we don't. Thx and all the best

Thanks for the feedback. We have a color for Delete/Error/Danger, that should be used in this case. I would consider it a bug if that is not the case. Adding the class "uk-button-danger" should do it, but that doesn't seem to work. We will fix it, I think we need to carefully go through the UIKIT docs and cover all the color based classes they are using. It should look like this: on a side note: To me the contrast of the secondary button of the original theme is way to low, I know that it is supposed to be muted, but it is barely readable. And the blue field title on light blue background is also to low in contrast.

Thank you for your response, @jploch. I really appreciate when a conversation is held at this level. Regarding data on user preferences: We have such data because we regularly collect it during design processes for user interfaces through test series. These tests have shown us a clear pattern so far: decision-makers—i.e., those who pay for the project—are generally drawn to sleek, modern, and shiny interfaces; those who actually work with them (daily) prefer a bit more color in the interfaces because it allows them to orient themselves more quickly. Of course, I agree that one can fine-tune the use of colors in the “Classic” style of the admin theme, but our clients – or rather, those who actually worked with it 😉 – have always been happy with the look and feel. By the way: in our view, a CMS is not meant to reflect corporate design any more than MS Word, InDesign, or any other software solution is. Since you want concrete feedback and suggestions, we are currently developing a small test tool with the most common UI elements that we use in the backends we manage to identify any potential issues. We usually provide our clients with 2–3 different admin themes that they can choose freely. (That is also where our data comes from.) Here is a first example (more to come) showing why we would like the option for a second color – on the left, the AdminTheme UIKit “classic” style; on the right, the new “default” style: By the way, we really like the decision to have the open/close arrow point in the correct directions! In closing, we would like to thank you again for the openness of the discussion and your willingness to engage! As a design agency, we unreservedly support your stance on “design by committee.” At the same time, we also understand developers like @bernhard, who have invested a lot of time in creating their modules and make their living from it, and who would have welcomed a discussion beforehand. At frameless, we have been convinced by ProcessWire for many years and use it for every web related project we develop ourselves. We currently see an opportunity with this redesign to position the platform as effectively as possible in the changing market for the coming years. So, thank you for your thoughts and implementations!

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?

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

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

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

Since I had to update more and more projects lately and also the PHP version of some of these projects was set to >=8 in the meantime I created a fork of the module and updated mPDF to version 8.1.3. With only some small changes in the WirePDF module I can now continue to use Pages2PDF without any restrictions. Maybe this is helpful for someone. https://github.com/markusthomas/Pages2Pdf