Leaderboard

There have been several requests and suggestions for the new AdminThemeUikit default theme. Some of them will no doubt find their way into the core CSS files, but I thought this week it would be useful to look at just how easy it is to apply some of these yourself using the custom CSS options in the AdminThemeUikit default theme. I haven't yet run these through Diogo and Jan, so there may very well be even simpler ways to do these things, but I took my best shot at answering some of the requests here. You can specify a custom CSS file (like /site/templates/styles/admin-tweaks.css), or if you are in advanced mode ($config->advanced = true) you can specify custom CSS rules directly in the AdminThemeUikit module settings. Let’s look at how to accomplish some recently requested tweaks. Also attached is a CSS file that compiles them all in one. And all of these work in both light and dark mode, by the way. CSS variables make much of this very easy to do. In this case, we’ll choose colors that are relatively close to black and white, but a little less harsh for those that like to have their screen brightness high. Of course, adjust the colors as needed for your preferences: :root { /* use slightly lighter main background color */ --main-background: light-dark(#efefef, #222); /* also slightly lighter background color for blocks like Inputfields */ --blocks-background: light-dark(#fcfcfc, #111); /* use text color that is not 100% white/black */ --text-color: light-dark(#222, #efefef); } You can adjust the button-background CSS variable: .light-theme { /* if you prefer not to have black buttons on light theme... */ /* use main color for button color */ --button-background: var(--main-color); } .pw .ui-button.ui-state-hover { /* highlight button when hovered */ filter: brightness(1.08); } Set .uk-select elements to use the inputs-background CSS variable: .Inputfields .Inputfield select.uk-select { /* make <select> elements have same background color as text inputs */ background-color: var(--inputs-background); } Here we'll use the main color as the background color for the PageList action links, and then make their text white. This gives more of an Original theme appearance, for those that prefer it: .PageList .PageListItem .PageListActions > li > a { /* make PageList items use action links that look like buttons */ display: inline-block; line-height: 1.3; background-color: var(--main-color); color: #fff; padding: 2px 6px; font-weight: bold; text-transform: lowercase; position: relative; top: -1px; } .PageList .PageListItem .PageListActions > li > a:hover { /* highlight selected action when hovered */ filter: brightness(1.08); } #pw-content-body .PageList ul.uk-pagination > li.uk-active > a { /* optional: update active pagination to use main color */ --blocks-background: #fff; --text-color: var(--main-color); } Like with the PageList action link buttons above, we apply new background and foreground colors to these sortable item-based elements. We also make a few other small tweaks to accompany the color change: .pw .Inputfields .InputfieldPageAutocomplete li, .pw .Inputfields .InputfieldPageAutocomplete li a, .pw .Inputfields .InputfieldPageListSelectMultiple ol li, .pw .Inputfields .InputfieldAsmSelect .asmListItem, .pw .Inputfields .InputfieldAsmSelect .asmListItem.ui-state-default, .pw .Inputfields .InputfieldAsmSelect .asmListItem.ui-state-hover { /* make asmSelect/autocomplete/pageListSelect use the main-color */ --main-background: var(--main-color); --border-color: var(--main-color); --text-color: rgba(255,255,255,0.9); background-color: var(--main-background); margin-top: 0; margin-bottom: 1px !important; } .pw .Inputfields .InputfieldPageAutocomplete li:hover, .pw .Inputfields .InputfieldPageAutocomplete li:hover a, .pw .Inputfields .InputfieldPageListSelectMultiple ol li:hover, .pw .Inputfields .InputfieldAsmSelect .asmListItem.ui-state-hover { /* highlight hovered items */ filter: brightness(1.05); border-color: var(--main-color); } In this case, we'll instruct <input>, <textarea>, <select> and TinyMCE elements to show a 1px border outline using the main-color when focused: .Inputfields input:focus:not([type="submit"]):not([type="file"]):not([type="checkbox"]):not([type="radio"]):not(.uk-form-blank), .Inputfields textarea:focus, .pw .Inputfields .Inputfield select.uk-select:focus, select.uk-select:focus { /* have inputs show a focused state indicated by border color */ border-color: var(--main-color); } .InputfieldTinyMCE .tox-edit-area { /* setup a border in tinymce that we can highlight when focused (requires latest PW dev) */ border: 1px solid transparent; } .InputfieldTinyMCEFocused .tox-edit-area { /* make tinymce show a border (like other inputs) when focused (requires latest PW dev) */ border-color: var(--main-color); } I found that InputfieldTable worked quite well as-is, but making the <table> use a transparent background color seemed to blend in a little better: .InputfieldTable .AdminDataTable tr { /* make InputfieldTable <table> have same background color as its container */ background-color: transparent; } .InputfieldTableRowSortHandle:hover, .InputfieldTableRowDeleteLink:hover { /* make table action links highlight with main color when hovered */ color: var(--main-color); } For the headers of repeater items, we take the same approach that we did with AsmSelect, PageAutocomplete and PageListSelectMultiple items, giving them the same bolder color scheme that utilizes the main color: .pw .Inputfields .InputfieldRepeater .InputfieldContent .InputfieldRepeaterItem > .InputfieldHeader, .pw .InputfieldFileList > li > .InputfieldItemHeader { /* make InputfieldRepeater item headers use the main color */ --inputs-background: var(--main-color); --border-color: var(--main-color); --text-color: rgba(255,255,255,0.9); --muted-color: rgba(255,255,255,0.8); } .InputfieldRepeaterItem > .InputfieldHeader:hover { /* make hovered repeater header slightly highlighted */ filter: brightness(1.05); } There are two CSS variables for this. One to control the border-radius of <input> elements, and another to control the border radius of buttons: :root { --button-radius: 99999px; /* this is the default value */ --input-radius: 8px; /* default is 0 */ } This is one thing I couldn't find a simple way to do with CSS, so I went ahead and added a toggle in the original theme settings (Modules > AdminThemeUikit). You'll now see an option there to "Disable toggle-style checkboxes", should you want it. As you can see from the above examples, one of many nice things about the new default theme is that it's quite simple to tweak it for your preferences. Attached is my admin-tweaks.css example file that has all of the above, and a couple more small things too. Please reply with your own custom CSS tweaks that you like. Thanks for reading and have a great weekend! admin-tweaks.css

@ryan - thanks for the option to disable toggles, but would you consider reversing it because as @bernhard and I pointed out, there are too many situations in 3rd party modules where toggles are just broken so I think the default should be checkboxes still. Also, keep in mind that the inputfield type is called "checkbox(es)", not "toggles".

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

Thx for adding some of my requests. +1! These toggles can be a no-go. And I think the current solution is a no-go as well. Imagine you are a module developer and you want (or need) to use checkboxes in one place. What do you do? Instruct all your clients/users of your module to set their backend to not use toggles? Easy solution? Not really... What if they had some modules installed that rely on the toggle-styled toggles? For example because they built an interface like this: This interface would break when using checkboxes! Because checkboxes don't have this left-right pointing indicator. I think there needs to be a better solution. And I think, again, that the new toggles look nice, but at what cost? I think we module authors have to have the option to control whether something is a checkbox or it is a toggle. This can't be the decision of the style that is being used. Maybe you can make the toggle-styles only apply to container-divs that have the class "toggle-style" or something? That would be a progressive enhancement. All checkboxes would remain checkboxes and if you @ryan decide that toggles look nicer on the page editor's settings tab, go for it and add the class "toggle-style" there. If I develop a module where I think toggles look nicer, I can add the class "toggle-style" too. But if nobody decided to add that class, we should get good old checkboxes. And a working user interface.

Hi everyone, Tracy is now using the brand new AdminNeo project. It's been quite a rollercoaster in the Adminer world with the apparent death of Adminer, to AdminerEvo, and then AdminerNeo, then the revival of Adminer, and now AdminNeo. I have been following both Adminer and AdminNeo and deciding which one to use and while I do worry that AdminNeo might not survive given the long history of the original Adminer (now it's alive again), the theme we were using was written by the AdminNeo developer and I just can't live with any of the Adminer themes by comparison. AdminNeo also introduces a robust external login system (instead of the hack needed by Adminer), so that's where we are now. Along the way I also added styling to page IDs so you can now tell if a page is hidden, unpublished, both, or trashed: I have also added a modal viewer for images, audio, and video, along with download functionality, along with thumbnails for images. And we also finally have a nice interface for the full Adminer Process module (Setup > Adminer) when not in Standalone mode - @Robin S - I think you might actually want to use this now 😜 Please let me know if you notice any issues or have any suggestions.

I think the lack of contrast between the the background of the repeater and the current background makes the whole repeater group like a blob of text, diminishing the effect of the vertical spacing of the items. I'd also vote for having a stronger contrast, maybe if not the main color, the same "inverted" color scheme. I'd also argue that completely turning the background white could help! Although this new color scheme got me thinking I would love nested repeaters to have a lower contrast version haha, with CSS variables it's now super easy to make ti work, no CSS overrides! Exciting times!

Hey all! This won't be a complete response to everything that was raised in this thread yet. Just wanted to quickly drop some notes before they vanish my mind 🙂 I will start by the end though, since it was @ryangorley mention that brought me here. You're completely right about how a clear communication of objectives helps everyone to accept the inevitable subjectivity of design (yes, I believe that, even with very defined objectives, design is still highly subjective). @jploch and I planned to write a blog post detailing, not only our thought process, but also a detailed description of how to customize the new design. We didn't have the time or headspace to do it but, with Ryan, we decided to launch on the DEV branch anyway, so this discussion and bug finding could happen as soon as possible. I now believe that this blog post wouldn't have answered most of the questions that people are raising, so in hindsight I think launching early, even with it's shortcomings, was the right choice. I would also like to remind everyone that, as Ryan referred multiple times, this is not a new theme but a skin on top of the uikit theme (it's ok to call it a sidegrade, although we consider that some aspects of it are definitely upgrades). Again, we accept and expect that not everyone will genuinely like the new theme more than the current one. Those people will have a natural resistance to this change, and there's not much we can do about it, either than respecting (the biggest sign of respect is that the current theme will stay in the core, with an easy switch). For others the resistance will stem from a feeling of "lost opportunity", in thinking that this will inevitably be the ProcessWire theme for the next multiple years. We discussed changes much more profound than these, but those would take time and would certainly not involve the community, if done in closed doors. So we decided to go with the more "superficial" and quick solution. The goal is for it to work in this moment, and to welcome new users who may come with the new site with something more coherent with what they'll find there. Those bigger changes, and others, can still happen as much as they could before. To finish. Meanwhile I sent Ryan a few small corrections based on things pointed out throughout the whole thread. Hopefully they will make it soon enough to the DEV branch. Thank you all for testing, giving your opinions and finding these bugs 🏆

I don't know if they need to be that specific, I didn't have time to try out different versions. I wanted to post stuff that I knew would work the first time, but I wouldn't be surprised if many could be simplified. If you find any that can be let me know and I'll update the post.

Also, as I mentioned in the other thread, along with changing the text color away from pure black, I still think another very important tweak is the color of the dropdown menu items - I still think they need to be the same color as the top level menu items when not selected. At the moment it looks like all submenu items are selected because they are the same color as the selected top level item. All items (top or dropdown) should be the lighter color unless it's the current page.

hey @bernhard no worries, hope you feel better! Thanks for the extensive answer, I always appreciate following the logic behind the scenes, especially on real case scenarios 😉 Of course with Processwire almost everything is possible out of the box! I mostly wondered as I have built some solutions for clients without ever going down the Module path, and was simply wondering if these were things you already thought about 🙂

Following on from @Tiberium's suggestion, which is how I've done such things myself in the past, if you want to extract text for search out of just about anything there's Apache Tika. It's in Java so, again as suggested, you'd need some sort of VPS or dedicated server – or perhaps you could make it part of a pipeline (e.g. on a local machine) to deliver content to your site.

@combicart, check Ryan response at this post:

Do you mean the files content or just their names? I use https://github.com/teppokoivula/SearchEngine for this sort of things.

Because "Artificial Intelligence" is a marketing word, and computers will never become intelligent as the definition of intelligence according to the Oxford Dictionary on may Mac is: "the ability to acquire and apply knowledge and skills" You see, LLMs cannot acquire knowledge (nor skills), they are "trained" (which is also a marketing phrase, BWT...), and a database full of data is not knowledge, the dictionary says that knowledge is: "facts, information, and skills acquired through experience or education; the theoretical or practical understanding of a subject" "Understanding" is the key word here. LLMs and fine-tuned models calculate probability which is very far from being a "fact". Another key word is "experience". A computer with experience? BTW, Interesting article to read: https://www.nngroup.com/articles/ai-model-training/ Anyways, thank you for sharing you module! Could you please also add an image or two to the readme, so that people can have a visual view of what to expect in that regard?

Thx for sharing! In case you don't know or anybody is interested in alternatives: RockDevTools is free and provides asset merge/minify plus live reload: