Leaderboard

We just discovered something funny: The design of the column width slider handle is from a galaxy far, far away, isn´t it? 😉

Text Readability A module that uses the PHP Text Statistics class to evaluate the readability of English text in textarea fields according to various tests. The available readability tests are: Flesch Kincaid Reading Ease Flesch Kincaid Grade Level Gunning Fog Index SMOG Index Automated Reability Index Spache Readability Score Dale Chall Readability Score Coleman Liau Index The results of the enabled tests are displayed at the bottom of textarea fields – either when the "book" header icon is clicked, or at all times, depending on the option selected in the module configuration. An interpretive tooltip appears when you hover any of the result values. Requires ProcessWire >= 3.0.246 and PHP >= 7.2.0 Why is readability important? Readable.com says: And: The Wikipedia article on readability has useful information too. Module configuration Select which readability tests you want to enable. For each test there is an "about" link to information about the test. Select whether the results of the enabled readability tests should be shown only when the header action icon is clicked (default), or if the results should always be shown. For multi-language sites, select which ProcessWire language represents English (as the tests are only intended for English text). Advanced If you want to disable the readability test results for a particular textarea field you can hook TextReadability::allowReadabilityResults. Example: $wire->addHookAfter('TextReadability::allowReadabilityResults', function(HookEvent $event) { $field = $event->arguments(0); $page = $event->arguments(1); // Disable readability results for the "body" field on the "home" page if($field->name === 'body' && $page->template == 'home') $event->return = false; }); https://github.com/Toutouwai/TextReadability https://processwire.com/modules/text-readability/

There is a free online event on ::: June 17, 2025 ::: 13:30–18:30 CET/CEST ::: 07:30–12:30 EST/EDT ::: 11:30–16:30 UTC https://lp.jetbrains.com/phpverse-2025/ @ryan what about taking part as a speaker on such events to make PW more popular?

And/or maybe a hover tooltip that shows some more info about each particular score, eg if the Automated Readability Score is 5, then the tooltip would display: Age: 1-18 Grade Level: 5th If you want some help setting this up, I'd be happy to create some JSON that contained all this info for all the scores that your module could parse. Actually, ChatPT to the rescue. This prompt "Automated Readability Index JSON of scores to ages and grades" returns: { "0": { "grade": "Kindergarten", "ages": "5-6" }, "1": { "grade": "1st Grade", "ages": "6-7" }, "2": { "grade": "2nd Grade", "ages": "7-8" }, "3": { "grade": "3rd Grade", "ages": "8-9" }, "4": { "grade": "4th Grade", "ages": "9-10" }, "5": { "grade": "5th Grade", "ages": "10-11" }, "6": { "grade": "6th Grade", "ages": "11-12" }, "7": { "grade": "7th Grade", "ages": "12-13" }, "8": { "grade": "8th Grade", "ages": "13-14" }, "9": { "grade": "9th Grade (Freshman)", "ages": "14-15" }, "10": { "grade": "10th Grade (Sophomore)", "ages": "15-16" }, "11": { "grade": "11th Grade (Junior)", "ages": "16-17" }, "12": { "grade": "12th Grade (Senior)", "ages": "17-18" }, "13": { "grade": "College Freshman", "ages": "18-19" }, "14": { "grade": "College Sophomore", "ages": "19-20" }, "15": { "grade": "College Junior", "ages": "20-21" }, "16": { "grade": "College Senior", "ages": "21-22" }, "17": { "grade": "Graduate Level", "ages": "22+" }, "18": { "grade": "Graduate Level", "ages": "22+" }, "19": { "grade": "Professional Level", "ages": "22+" }, "20": { "grade": "Professional Level", "ages": "22+" } } So it should be easy to do the same for all the other indices.

It's a holdout from the original theme, it likely was overlooked in the new. Probably should be removed in the base theme (imho) realistically, though that's a matter of opinion. I'd imagine it would potentially be easier to style it if it were a browser-native control instead of a range slider that was created prior to browsers having native interfaces for it. This CSS might clean it up a bit. The new theme could likely use some CSS variables in place of the colors below, I simply targeted the base CSS instead. .ui-slider .ui-slider-handle { border-width:0; outline:none; border:none; width:17px; height:17px; background-color:transparent; background:currentColor 0 0 no-repeat; border-radius:21px; box-shadow: 0 2px 2px gray; } @ryan If we're using the admin.css override, and users are allowed to choose their admin theme, is there currently a way to target our overrides to the sub-themes/styles individually? I see the main theme name is appended to the body classes, but not the sub-theme name, and since we can only have one override file, currently... Is there a way to handle that scenario that I'm not seeing? I'm also wondering if there might be opportunity for others to provide sub-themes to the AdminStyleUiKit, and if so, perhaps the naming of the options should be something other than "Original" and "Default"? Default is typically a word assigned to what would be chosen for someone, not a choice to be made. (I do understand the reasoning, though.) I'd be quite happy if Konkat chose a name for their theme/style, whether it just be Konkat, 2025, some iteration therein, or anything their hearts desire! If a body class were added for subthemes, it'd be weird seeing "Original" or "Default". 😉 - - - Installed the DEV branch. The dark mode looks more like a high contrast mode to me. I'm not yet sure what suggestions I have for it, but compared to the light mode, it's quite jarring. (For what it's worth, I use dark mode by default in systems that offer it.) I'll try to think on that a bit more.

Back or not, having only one lone icon/image among non-skeuomorph icons/images is, at the very least, questionable.

You can do this with the $buster API

Not so fluent with composer. So consulted the docs. Seems like composer update --with-all-dependencies will do it.

I'm surprised a textarea field value can be null rather than an empty string. Maybe something to do with multi-language. I'm casting $text to string in v0.1.3 so hopefully fixed. Thanks for the report.

Sorry, now I am seeing: Deprecated: strip_tags(): Passing null to parameter #1 ($string) of type string is deprecated I guess it needs to be after: if(!$text) return;

Good idea, I've done that in v0.1.2

@Robin S - I just did a little bit of testing between various online Flesch Kincaid Reading Ease calculators and the same text resulted in very different "reading ease" scores. Your module - 52.5 https://serpninja.io/tools/flesch-kincaid-calculator/ - 37.85 https://hemingwayapp.com/articles/readability/flesch-kincaid-readability-test - 50 https://goodcalculators.com/flesch-kincaid-calculator/ - 46.8 https://charactercalculator.com/flesch-reading-ease/ - 43.16 https://codebeautify.org/flesch-kincaid-grade-level-calculator - 31.9 https://app.readable.com/text/?demo - 50.4 ChatGTP - 47.2 ChatGPT also tells me that the reason for the differences I am seeing is due to the counting of syllables and sentence boundaries, etc so I guess the key thing is getting used to what your module returns and compare relatively with other field content on the site. One thing I didn't understand though is why the readable.com demo wasn't returning the same score as your module given that https://github.com/DaveChild/Text-Statistics?tab=readme-ov-file#useful-links links directly to it as a demo of it in action. But looking into it, I realized that when I was pasting the text into these calculators, it was just text and not the HTML that is part of RTE field content. So, I added $text = strip_tags($text) and now I get the same 50.4 that the demo on readable.com does. Do you think it makes sense to add that?

@adrian, I've added most of your requests in v0.1.1. But not the colour-coding because the results don't fall into universal good or bad categories - it depends on the intended audience, e.g. you would expect a high grade level on a website for an academic journal.

This module is a remake of Ryan's classic Comments module, but uses its own code and is based on the FrontendForms module. This is the third module in the "Frontend" series, alongside the FrontendContact and FrontendLoginRegister modules. To use this module, FrontendForms must be installed. Otherwise, it won't work! If you don't have this module installed yet, please download and install it first! This module has a large amount of configuration settings supports pagination supports UiKit3, Boostrap 5 and Pico 2 CSS frameworks out of the box and a lot more The download link as well as many more images and the documentation for this module can be found on Github. Please note: This is the first version in an early alpha stage, so using it on live sites is not recommended. This module should be available in the module directory eventually, but it still needs a lot of testing. If you discover any issues or have ideas for improving the module, please post them here in the forum or directly on Github. Happy testing!

Here is a live example of the comment module using UIKit 3 markup: https://www.schulfreund.at/nachhilfekurse/chemie-nachhilfe/

Hi guys. Sorry reliving my appreciation with Processwire after a really long break. I have a test environment and production. Test is where I play and when things are final, I put it in Production. Problem is how do I migrate the structures and fields to Production? 😕 What's your best practice to ensure that live data is not ruined? Thanks in advance and sorry for the noob q.

Hey there, Pip! Welcome back. 🙂 If you're only going to migrate once, developing up until it's ready to be launched, you can typically just get a backup of your SQL and move it to the production's database (along with your /site/ files and related structure). If you're going to be doing development after the website is launched, and you need to make sure that the development you do does not affect data created on the production website, you'll want to look into something like RockMigrations, or any of the other migration modules.

Hello everyone, I would like to give you an overview of the recent changes and improvements that have been incorporated into the ProcessDataTables module since version 0.6.0. Maybe there is something interesting for you! As we are testing the brand new UIKit style the screenshots are made using that theme. From 0.6.0, the UI for import/export is now clearly structured, visually improved and much more user-friendly. The new pagination (from 0.6.2) ensures better performance and overview for large data records. The value for the rows per page for DataTables is defined in the config area. Before this version there was no native pagination, i.e. all data records were loaded at once - problematic with large amounts of data. Now the navigation is performant and user-friendly, large tables are divided into pages.

Hey @Robin S - this is really useful, thank you as always. A couple of thoughts. Would you mind passing the text through Hanna first. I have a lot of tags in some content and readability is very poor unless I add this to your module. $hanna = $this->wire('modules')->get('TextFormatterHannaCode'); $text = $hanna->render($text); What do you think about adding some easy way to identify if each of the scores is good or not - at the moment you have to look up the docs, but perhaps color coding the values (red, orange, green) or some other way would help to alert us to issues. Thanks again!

The send() method in WireMailSMTP is hookable, so depending on how your service's Oauth2 requirement works you might be able to create some sort of supplemental solution.

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!

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 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 @ryan I'm preparing to add some new features to RockCalendar (looking at you @FireWire 😉 ), so I thought it's a good opportunity to see how it works with the new theme! As you can see, the light mode looks a lot better and the dark mode totally loses the day headlines (Sun, Mon, ...) Could you please share some information how we as module developers can make our modules work with the new style? It might sound easy for you or the style authors or any CSS ninja out there, but it might not be easy for backend-focused devs. In this specific case I'm wondering: How can I make the headlines show up properly in dark mode? Which color would I set? Which css variable would I use? How can I make buttons like "today" and "left / right" at the top right look like all other buttons (like publish, for example)? Regarding the buttons I'm quite confused for a long time and it might be the right time to mention it now: Many buttons use "ui-button" as class. As far as I understand this was the class coming from jQueryUI and with the old style this was giving it some rounded corners (compared to default uikit buttons). Then UIkit was added to the mix and from that time on I thought we can use "uk-button uk-button-primary" to style our buttons. At least to get matching colours. That meant that anybody using admin.less to customise their backend and changing the primary color saw a button in the primary color. Now we have another layer on top. A style using CSS variables, overriding UIkit, which overrides jQueryUI. This might be wrong - I don't yet understand how all of them play together and which layer overrides another, but I think you get my point and I'm happy to be corrected or get an explanation of how these layers are supposed to work together. May I also ask for some help or explanation how we can deal with that to provide good and reliable modules? What classes shall we use for which elements of the UI? This also brings me back to this question I raised earlier regarding all the UIkit UI components: Most likely it's something that PW doesn't use, so it isn't styled, but I'm sure it can be. I think we do use uk-alert boxes, but always of a type like "primary" or "warning" or "danger", etc. So maybe we just need to add a style for alerts that aren't of a specific type. To be honest I'm very confused about your statement, so it would be great to get some more details here. I understand that jQueryUI has been used for several aspects of the admin (like the drag&drop etc). And I understand why UIkit was added to the mix in 2017. What I do not understand is how UIkit is supposed to be used by us developers now. Using ProcessWire as the CMS of choice does not only mean to use the backend and all its features as is, it also means (for me and I guess many others) to build something on top of it. This does often not only involve the frontend (where we have full freedom), but also the backend. It might involve adding some details here and there via hooks, it might involve building custom inputfields or it might involve building custom process modules (aka custom admin pages). I always thought that having UIkit as a common ground is something that I/we can rely on. At least as long as the UIkit theme would be supported. That meant to me, that I can build anything for my clients (both direct clients or clients using my modules) that is based on any of the UIkit components listed on their docs (eg https://getuikit.com/docs/accordion). Now your statement makes me wonder whether that is still the case. It sounds a bit like that some components are simply not supposed to be used, which would be unfortunate and less than ideal, in my opinion. I'm a bit confused and afraid how I would ideally build a module (or upgrade any of my existing ones, which are a lot...) to make them work well with the new style, the old default style and maybe also the rock style, if anybody prefers it over the others. As you stated several times anybody is free to choose whatever admin style he/she wants. But that means in return for me as a module developer that I have to support all these options. When using UIkit, there are some proven standards that the company Yootheme defined. We have "uk-button-primary" for primary buttons. We have "uk-text-lead" for slightly bigger leading text. We have "uk-text-muted" for subtile grey text for explanations and such. We have tooltips to add additional information on hover, etc. All this is documented well on their docs. So it is obvious for anybody how to use it. It is not obvious to me any more in how to use anything related to UIkit when I have to expect that at least one of my clients/users might possibly be using the new style and might possibly be using dark mode 😞 For example I just added this hook to ready.php: wire()->addHookBefore('Inputfield::render', function ($event) { $inputfield = $event->object; if ($inputfield->name != 'title') return; $inputfield->description = '<div class="uk-text-lead">This is a test</div>'; $inputfield->entityEncodeText = false; }); Which renders fine in light mode: But does break on dark mode 😞 I wonder what the idea is to solve such issues? Are we supposed to NOT add any standard-UIkit markup to any of our backends that is not part of the PW core admin theme and that is not supported by the new style? Or are we supposed to add custom css overrides for such cases to our modules? Or are we supposed to report such issues whenever we find them and then wait for you or the authors of the new style to add support for it? Or do you think the the new style could be improved to support default UIkit markup without breaking? What would be the correct way to add a slightly more prominent intro text to my title field that works properly across all new and old (uikit based) styles? Thx in advance - it got a bit long, sorry! But this change basically effects years of my work...

@ryan I would say that in most cases design seems subjective because the guiding objectives have not been well defined or communicated. Brand cohesion is a reasonable objective, and it sounds like we're going to eventually get some more visibility into that. Other objectives brought up here are worthy too. When/if @jploch @diogo have a minute, it may be helpful for us here or in a short blog post to learn how you all are prioritizing things. Design by committee doesn't work well, but if we have a rubric for providing feedback, we can provide forward momentum versus resistance. Just my $0.02.

We will look into adding these. Okay, can look into this too. This is supposed to be low contrast because it is non-essential information. It's the sort of text that we don't want to have your focus unless you are specifically looking for it. Admittedly I like the contrast, but I also like anything easy on the eyes, so will definitely give it a try. I'm not seeing it currently, but have definitely seen it before, and before the new admin design. I think it is related to the Inputfields JS for 'showIf' dependencies rather than the CSS of the admin. Look closer, there are definitely functionality upgrades here. Just to name a few, the masthead is now sticky and always available, the navigation dropdowns are quite a bit better as they scroll within rather the whole page, the top search now acts more like a command palette (with its own hotkey), and much of the admin appearance can now be easily styled with CSS variables.a I think forcing is a strong word for giving people the option to decide whether they want to use the Original look or the new Default look. In your case it sounds like you'd want to continue using the Original style for AdminThemeUikit. As mentioned a couple of times already, it will always be there, it's not leaving. That's correct. It'll be the default on new installations. The Original option will be there for new installations too, even if it's not initially selected. Users on existing installations will have the option of switching to the new default look if they want to, but it won't be the default on existing installations except on the dev branch while our beta testing proceeds. Do you mean the headers of repeater items, or literally the inputs? I like using the main-color as the background color for AsmSelect items, PageAutocomplete items, and repeater headers, so that's part of my custom CSS. @cst989 Sorry, I'm not trying to call you out. Having a cake to decorate was meant to make you laugh. We have a diverse community with lots of different opinions on design, and all are valid, I didn't mean to suggest otherwise. I've been trying to be clear that I'm no authority on design, and so that's why I'm trusting full time trained designers that know PW really well. They have a lot of success stories in their portfolio, and I'm confident PW will be one of them. But design is always tough because it's so subjective. For your preferences, it sounds like the new design isn't a good fit, and that's fine. But if you like the Original design, then know that it'll always be there too. ProcessWire is slow to get new users in large part because our admin and website often look dated to people that aren't already familiar with ProcessWire. I'm pretty sure that group of people will be more likely to explore ProcessWire with the new design. I think once you see the new website, the overall branding picture will be a lot more clear as well. I don't expect anything designed to appeal to everyone, but I'm confident this will help PW to grow.

Hello, The collaborative efforts of @diogo and @jploch are truly commendable, and the new admin theme brings a fresh look to the ProcessWire interface. That said, it feels like some aspects weren’t fully addressed. The theme includes certain design choices that have sparked debate and a few bugs that slipped through. In my view, this isn’t a reflection of any lack of competence from @ryan, @diogo, or @jploch—far from it. Rather, it highlights how the project was managed, which, to me, mirrors how ProcessWire itself has historically been managed under Ryan’s leadership. A project like a new admin theme could really benefit from being more community-driven. A simple round of beta testing with some of the most active and experienced members of this forum could have prevented many of these issues before release. Keeping it under wraps usually doesn’t work as well as we hope, especially considering how diverse the use cases for ProcessWire are. And this does reflect on ProcessWire itself. I sometimes wonder whether Ryan truly wants PW to grow bigger, gain more visibility, and capture a larger market share. If he does, some of the actions we see don’t seem fully aligned with that goal. As for why Ryan continues to keep such tight control, I honestly don’t know—whether it’s a matter of personality, or perhaps he hasn’t yet found people he fully trusts on the technical side. That being said, none of this discussion would even be possible without Ryan’s incredible work on ProcessWire. Regardless of what the future holds, we’ll always be grateful for that. I’m simply sharing my thoughts with the hope of contributing to its improvement. That’s all.

@bernhardI think that functionally the new look is better in this regard because the lines are limited to the actively hovered page. That makes more sense to me. I'm not sure the Original lines have any actual purpose. So not sure why I put them there other than it was part of the design style/trend 10 years ago. 🙂 Though if someone can find a strong functional reason for the lines where it provides some benefit to the user, then that would be worth having a toggle for. You mentioned that it would "help" some users. Is that because it's a more obvious clickable element? That seems more functional to me, and maybe something worth having a toggle for. I'm indifferent myself, as I don't really have a preference one way or the other. But worth passing along to the designers to see what they think. From the PW standpoint, this is the "message" notification, which is one that's informational and not supposed to call attention to itself. In that respect, I think the color is ideal and much more consistent with the purpose of it. But maybe something to get used to, as the Original design was more "in your face" with it's message notifications, even if it wasn't really supposed to be. The Warning and Error notifications are supposed to call attention though. I have that same "doesn't feel quite right" with most dark modes. But have to admit, the one in the new admin design feels just right to me. Maybe that's because I've been using it more than a month now. But once I tried it, I was hooked. Of course, there's always room for improvement. The new design makes it easy to adjust things with the CSS options, so it's easy to test things out, such as the background color you mentioned. If you have more specific suggestions over what would make it feel right to you, definitely share them. As of Friday's updates, if you provide an SVG logo that has as fill="currentColor" then it will inline the SVG and the new design will be able to use the new light mode or dark mode main color for the logo automatically from its CSS. Thanks, I didn't realize that, I think the the installer must have been in light mode when I tested it. I will test it in dark mode and fix the colors. I will look into adding this, not as new configuration values, but as extra inputs that get populated with the hex code when the color picker changes, so that you can change it if needed. Probably just a little JS should solve it. There's no plan to drop the original Uikit theme, but it's no longer going to be the default (at least for new installs). But we do plan to remove the AdminThemeDefault and AdminThemeReno from core and maintain them in as modules separate from the core. Maybe. We can see where we're at when we get closer to merging to master. Though if we did that, I wouldn't want existing installs to be unaware of the new addition either. So for existing installs, maybe an option to select it on a user-by-user basis, and a one time notification that tells users about it and how to switch between the two. Currently only the superuser can make this change, but I think it would be good for it to be selectable on an individual user basis.

Hello, After spending a week with the new admin theme, my feeling is that it is definitely a step in the right direction, making the admin feel more like an application, and many thanks to all who've worked to get it where it is. That said, there's quite a few issues I and the team here have picked up on. Most of these have been highlighted already. Here's some observations interspersed with some issues: Page Tree A number of colleagues have commented on the removal of the 'lines' on the page tree. I much prefer the new look, but it may be useful to have the option to toggle this on/off. I also like the 'text' style of the action buttons, but feel a more button-like style on hover would help. Colouring Something I'm not keen on is the lack of colour for the messages. Having the primary alert colour being the same as the background makes it hard to notice. We think the background colour (#eee) in light mode is too dark. #fafafa feels better. I also miss the colour of AsmSelect items. Having these in grey makes them blend in too much. Dark mode I prefer dark mode, but I've found myself switching to light mode on all the installs I've worked on. I can't pin down the problem though. It might be that the muted grey background makes the actual UI (fieldsets) too stark. It doesn't feel right. I agree with other comments that there needs to be an ability to customise the logo and colour for both modes. The installer needs to be tested in dark mode. All the input text is white on an input on a white background! (longest, most frustrating PW install ever!) Colour picker I think there should be at least two more fields beside the colour picker input, one for HEX value, and another for RGB. Editing one updates the others. On Safari, the native colour picker doesn't give you the option to input a value so I needed to login on Chrome to set the value I actually wanted. ... My main concern with this is the rollout when this reaches the master branch. We have a setup where we can update all PW sites on a server at once, and as it stands I think we'll need to go into each site to specify light mode. We want the rollout to be successful with our clients, and we'd prefer to adopt the new theme gradually, as and when we're working on a site. I think retaining the original UIkit theme as the default should be considered. Cheers, Chris

As noted above regarding z-indexes, they also seem weird for top nav menu dropdowns. It looks like they are set to 200, but they still appear behind Tracy panels when they are set to 100. I haven't narrowed down the exact required index, but setting Tracy to 50 lets the menus dropdown over Tracy panels. In the original theme, the menus are also set to 200, so it must have something to do with the new fixed header nav messing with things.

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

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

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