Leaderboard

Which approach to take depends on where you want the added markup to appear, relative to things like description and notes. Demo: $wire->addHookBefore('InputfieldText::render', function(HookEvent $event) { /** @var InputfieldText $inputfield */ $inputfield = $event->object; if($inputfield->name !== 'text_1') return; $inputfield->prependMarkup('<div>prependMarkup</div>'); $inputfield->appendMarkup('<div>appendMarkup</div>'); }); $wire->addHookAfter('InputfieldText::render', function(HookEvent $event) { /** @var InputfieldText $inputfield */ $inputfield = $event->object; if($inputfield->name !== 'text_1') return; $event->return = '<div>before render</div>' . $event->return . '<div>after render</div>'; }); Related request: https://github.com/processwire/processwire-requests/issues/536

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?

@adrian I fully support adding whatever CSS vars Diogo and Jan want to add. But I’d hate to throw out the idea of using anything but root-level vars. They seem very powerful to me and a major benefit of using these CSS properties in the first place. I mention it just because my eyes are struggling with it in the screenshots and video above. Especially the white-on-green text. But if the company is used to that usage then I’m sure they’ll like seeing it in their admin either way. I'm not sure. I’ve not had that come up yet, so can’t really well speak to it. But I’m not opposed to it. While very customizable, this admin theme is also something that’s been designed. If “anything goes” and “anywhere” in terms of colors, it’s more of a blank canvas than a professionally designed theme. I don’t think this theme was intended as a blank canvas. So there have to be some constraints in place. Making some things customizable, where planned for by the designers, is great. But other things, like rethinking the foundation of a slightly off-white (or off-black) body background might be going too far, because it changes the whole balance of it. It appears to me the editing tools (Inputfields, etc.) are designed with the idea that they won’t share an identical background color as the body. So if you go pure-white or pure-black with the body background, I agree that it may be problematic. It may be that they can add more CSS vars, but it might also be that it goes outside the boundaries of how the design is supposed to work. But I’m not the designer, so I’m kind of speculating and might be wrong. Maybe so. But I will say that as someone new to CSS variables, it’s been refreshingly easy to change anything I need to with what we’ve already got. There hasn’t been any real fiddling, and the affected markup is not likely to ever change in terms of how it would be identified with CSS selectors. So I'm just trying to say that I think we're already in quite a good spot, being able to do stuff I hadn't thought possible before. But I'm not saying that we should stop there. There's always room for making things better and better, at least where the resources allow.

Hey @ryan - one side-effect from your example: setting --menu-item-backgroud-hover to a white like you have also sets it for the big Add New button on the page list screen, which means it doesn't show anything. This is one of the reasons I really believe we need separate CSS vars for the main nav vs other elements and also separate ones for the top level as well as the dropdowns, and perhaps even the next level down again (Pages > Tree etc), because the font size and padding on these is not easily adjustable (not critical though).

I tested using your example and that does work quite nicely - one of the key things I missed was the --masthead-input-xxxx vars which make a big difference. But as I have noted, the key thing I want is a dark back for the top level of the menu, but not for the dropdowns which is where things get particularly problematic. One thing I noticed while testing your example CSS is an issue with setting light vs dark mode from the user's profile settings. The first time I tried to set to light mode (instead of auto), the page list hover background went black - going to back to auto fixed it, but now it's stuck on dark mode and no matter what I do, I can't change it to light mode - even after clearing all cookies/sessions. As long as we are working towards no bugs in any situation, I am OK with it, but honestly I think it's a waste of effort. I know it's a personal thing, but I feel like the whole dark mode thing will fall out of favor once people realize it's not actually a better experience for user interfaces.

I honestly quite like much of how the new theme looks and appreciate lots of the decisions and work that has been put into it. It's the problems with tweaking it that are proving the killer for me - css vars should make it easier, but they way they currently are is making it harder. Please try to change the top menu to a darker background with white text you'll quickly notice that many side-effects aren't easy to fix. The problem is that if it doesn't work for some modules but the project developer really wants to use it (or their client does) but then later they discover a new module they want to use doesn't work well with it, then what to do?

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.

Very well said. Although if you start inviting module developers into a conversation where does/should it stop. I agree with the way this was approached, and the dev branch has always been available for this sort of thing. Some of the criticism has come across as negative but I don't think it was meant to, it seems everybody wants the best from this especially KONKAT.

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

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

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

If not targeting UiKit variables which will exist globally for all "modern" themes (regardless of user choice), how would you be sure to properly assign/override something like a primary color? That would only allow you to custom-target this new theme/style, unless the goal is to make those named CSS variables part of the base theme? I understand that easier-to-read names make things simpler, but as PW has used UiKit for so long, its usage is fairly well entrenched, even in the many Pro Modules (ryan's, jploch's, and bernhard's, maybe kongodongo's too but I'm not familiar with his). Forgive me if I'm mistaken, but doesn't the standard admin style (css/less file) override affect all admin themes by default? If so, is there a way to ensure we're properly targeting overrides for the intended theme/style, or applying a global override? I haven't messed with that for this very reason of uncertainty.

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.

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.

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!

@combicart, check Ryan response at this post:

I think you could try installing a more recent version of the Google API client that is php 8+ ready, cause that seems to be a 8+ error and from the path i can tell it's the google library that is being an issue.