Search the Community

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

It's dropdowns on submit buttons, the Add New button (page tree) and the top menu. What actually happens here (and maybe it is expected, but seems weird to me) is that if I want to override: --main-background for the page background at the root level, this automatically sets the --menu-item-backgroud-hover to the same color because of the reference to it. This means I need to re-set --menu-item-backgroud-hover again which works, but I think these references might might be part of the confusion we'll all be having and it's not initially obvious that changing one will impact the other so you might break things without realizing it. So maybe all that is needed is not referencing one var with the value of another? Sometimes it works, but often it doesn't. If I do that though, I can avoid that lower level override of --main-background and just go with the following - in this case I am playing with the menu hovers matching the main color, but you can also easily just reset it to the: #eee which I still might go back to. :root { --text-color: #444; --muted-color: #999; --button-radius: 10px; --main-background: #FFF; --menu-item-backgroud-hover: var(--main-color); } .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; } Sorry, it's only impact repeater matrix fields from what I can see.

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?

Thanks for all your thoughts there @ryan - really appreciate your input. The one thing I would say about the new grey background is that I think it looks OK when editing a page - I think the contrast between the background and the input fields is quite nice. What I really struggle with is the page tree and the action buttons white background on hover - that is probably my biggest issue with the new theme. Everything else works (except for some bugs that need ironing out), but that page tree view is just really ugly IMO and I know I am not the only one with concerns about it. One solution to this is: .ProcessPageList { --main-background: #FFF; } and of course to need to deal with the action hover, but in this case I like the buttons back so I have also added: .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); } One other thought for now - I really like the margins between fields when editing module settings, eg: but when editing a page, there are no margins: I thought the setting below would change that, but it doesn't seem to have any impact that I can easily see - it least it certainly doesn't match the module editing layout: Is it another option somewhere else?

Hi @diogo - thanks for your thoughts! I think the key thing here is that if you like the look of the new theme (and there are many things I do like), then it's great (checkbox/toggle issues aside), but if you don't like the look or just want to theme it easily to match a client's brand, then it's really painful to adjust - I think that is what most of us are taking issue with. The key things I want to be able to do easily are: set the background and text color of the top level nav without it impacting the color of the dropdowns (like we could before) change the grey background to white and be able to fix the issue with the background color of the page actions row - personally I would really appreciate an option to go back to the button look without css overrides, but just being able to set the background of the rows without it impacting other things (I can't remember now what it was) would be fine. change the inactive state of buttons to match the primary color rather than using it for the hover state Honestly, that would satisfy everything for me. Thanks for considering. Other than Modules > Refresh, I am curious what else are actions and not pages? I really think the active class here would be great. Sorry, but even though this sounds good in theory, I really don't think it works in practice. You can't overwrite variables that are the dependents of other variables without consequences (unless there is something I am missing). And the contrast issues prevent changing 5 or 6 variables to get things working if you decide to go with darker over lighter colors for backgrounds. The thing is though, that with AdminStyleRock you only needed to change a couple of things to make a significant change. You can't actually do that with the new approach (and have it remain readable). But, I really love CSS vars and want to make this new approach usable. The issue with page list actions comes about when you want the background to be white and not the new grey. Now the white background highlighted color of the page list actions row doesn't work so the links to "edit" aren't very visible at all. Changing the background color of these has been other consequences because of the few css vars issue. So, I ended up restoring the actions to buttons using .PageList .PageListActions a, .PageList .PageListActions a:hover,.PageList .PageListerActions a,.PageList .PageListerActions a:hover, .PageList .PageListMoveNote a {

Of course RockMigrations can do that. Example migrate.php: <?php namespace ProcessWire; $rm = rockmigrations(); // install modules $rm->installModule('TracyDebugger'); $rm->installModule('RockDevTools'); $rm->installModule('RockFrontend'); $rm->installModule('AdminThemeUikit', [ 'toggleBehavior' => 1, // consistent 'themeName' => '', // original theme ]); $rm->installModule('RockAdminTweaks', [ 'enabledTweaks' => [ 'General:QuickAdd', 'Inputfields:CopyFieldNames', 'Inputfields:ImageDownload', 'PageList:TemplateLink', 'PageEdit:PrevNextPage', ], ]); $rm->installModule('Less', [ 'useCache' => 1, ]);

I found a solution - even though I don't understand in depth, what is going on: The Userrole not only needs the right to delete the content-element pages, but also needs the right to use the delete button in the pagelist: =>modules => processPageList => allow trash for non superusers Perhaps this will be helpfull for others ...

Using the new theme on mobile seems very hard to me at the moment. The menu button is not available and the page tree with all pagelist actions is... somewhat strange. pagelist actions are sometimes not visible at all, sometimes they appear when clicked, sometimes they don't.

@adrian I'm still learning about CSS properties/variables, so I might be missing something. But based on what you've said above (and in other places), I'm wondering if you are missing the cascading and inheriting aspects of CSS properties/vars? Maybe you are thinking of them like PHP variables? They are quite a bit more powerful than that. If I understand it correctly, the actual number of variables you can customize is the number of CSS variables multiplied by the number of elements using it that can be targeted with a selector. We probably have thousands of customizable properties just with the set of variables we have now, where the selector is like the namespace for the variable. So when you set a value of something like --blocks-background, you are setting a default/fallback value if setting it within :root { ... }, and then, it may be overridden further down the tree. In your masthead example, you would target the --blocks-background within #pw-masthead, or something more specific within it. In your PageList example, you would target --muted-color within .PageList, or something more specific within it. So in my mind, it doesn't make sense to have tons of CSS variables unless you plan to treat them like PHP variables, which would be using them incorrectly. The current set of CSS variables seems well thought out to me, but I'm still learning.

This week on the dev branch are 8 issue resolutions. The most significant one #2035 (found by @Jonathan Lahijani) is that when you trash a page with children, and then later restore it, the page gets restored correctly, but the children/descendants only partially get restored. By that I mean that the children would get moved out of the trash, but they'd continue to have trash status. So those pages could silently behave like they were in the trash, making them visible in the PageList but otherwise inaccessible. There wasn't really any way to fix it interactively, since you can't manually assign or un-assign trash status, at least not without using the API. While I suspect this bug has been around for a very long time, I couldn't find any installations where I had trashed and restored a nested structure of pages like this, but was able to reproduce it manually. Just in case any of your installations have pages like that, the PageList (as of this week's commits) now highlights them with both trash and warning icons. Fixing the issue is just a matter of editing the page and clicking Save. If you want to quickly check if you have any pages affected by the issue (in almost any PW version), you can paste in the following URL, assuming /processwire/ is the path to your admin: /processwire/page/search/for?status=trash&has_parent!=7&include=all While it might be rare to trash and restore a structure of pages, I want to make sure nobody is affected by it so I'll likely update the current main/master version within the next week, merging the current dev branch. Coming in ProcessWire 3.0.246 is support for another type of conditional hook which enables you to match the return value, or properties of the return value, for any hooked method. Currently conditional hooks let you match things from the object being hooked, or the arguments of the method being hooked, but it's not previously been possible to match the return value of of methods with conditional hooks. Next week it will be, which I think as a useful improvement to our hooks system. More on that next week. Thanks for reading and have a great weekend!

Yes, variables can be changed in a specific scope. That being said, I was also uncertain whether utilizing this was a good idea, or recommended. Mainly as it seems that it might be prone to cause issues at some point in the future. To demonstrate, take this for an example (even if it was not used with variables specifically in the context of this thread): .PageList .PageListItem .PageListAction > li > a:hover That is a rather specific selector. If at some point in the future we needed to add an extra level of markup between ".PageListActions" and "li", or wrap the "a" tag in a "span" tag, etc. that would break styles relying on this selector. (Yes, it's just CSS, but that would still be an undesired outcome.) This is a benefit of having more, and more specific, CSS variables as well: if there was a --page-list-actions-link-hover-brightness variable, it would feel safe to use that. At the very least it would be less likely that someone decided to remove support for it from the admin style, as they would see right away that it will likely cause issues. (And no, I am NOT suggesting that we need to go to this level with our variables; just using this as a hypothetical example!) The point I'm trying to make here is that if this is what we are suggesting and/or recommending users to do, then we should be very, very mindful of making any structural changes in the admin. This may already be the case, so perhaps I'm just stating the obvious 🙂 If not making changes to structures in the admin seems unreasonable, one option might be to define "safe contexts", kind of like hooks for CSS variables — i.e. add a list of IDs or classes that "will not be changed or removed, no matter what". Things like "#pw-masthead", or "#pw-masthead .pw-search-form" from Ryan's examples, or ".pw-dropdown-menu" from Diogo's reply 🤷‍♂️

Thanks for sharing @ryan. Do the CSS selectors need to be this specific? Or is it because we have to overwrite styles written with less that tend to produce these (thanks to the nested selectors)? For example: .PageListActions a { } /* instead of */ .PageList .PageListItem .PageListActions > li > a { } /* or */ .InputfieldRepeaterItem > .InputfieldHeader { } /* instead of */ .pw .Inputfields .InputfieldRepeater .InputfieldContent .InputfieldRepeaterItem > .InputfieldHeader { }

The admin page list seems to be hiding the content of page labels inside square brackets. For a page titled Some Title [old], it will display as Some Title, removing the content inside the brackets. Oddly enough, a page titled Some Title [old content] displays correctly as Some Title [old content]. My guess is that ProcessWire is trying to interpret the part in square brackets as dot-field notation and trying to access a field value. Since there's no field named 'old', it will drop the brackets and everything inside entirely. Is this documented behavior? Can this be turned off? (Tested on latest dev branch, 3.0.171 and 3.0.181)

I have to leave town later today for for my daughters gymnastics meet, so I'm getting the weekly post out early this week. I bumped the dev branch core version to 3.0.245 as well. While there isn't anything major in this particular core version, it does contain some updates to the ProcessPageList module that were needed to make in order to make it possible to build the new PageListFilter module (the one I mentioned last week). These updates focus on making some parts of the PageList more hookable. To go along with those core updates, I've released the PageListFilter module that I mentioned last week. This is an admin helper that enables you to filter pages in the page list with a click, such as first letter (A-Z, etc.). I've already found it quite handy on some of the ProcessWire installations I work with, I hope some of you find it useful too, please let me know what you think. Thanks and have a great rest of the week and weekend!

What is your intention with this module? I think it would make more sense to add the tweaks directly to RockAdminTweaks, no? https://github.com/netcarver/RockAdminTweaksPool/blob/697240eb651dd873585b7f2630a81f2d905192ca/assets/RockAdminTweaks/AdminOnSteroids/BypassTrash.php#L28 --> this is not needed any more, because tweaks are only loaded in the backend, so it will always be template == 'admin' Regarding styles and scripts: I've added a "loadJS()" method on the Tweak base class. This will automatically load the corresponding js file from the tweak. See docs here: https://github.com/baumrock/RockAdminTweaks/tree/main/docs/assets Personally I'd prefer to have all the JS in dedicated JS files. It's a lot easier to write, a lot easier to read (no escaping, working color highlighting etc) and it's also easier to develop and debug (as you can set breakpoints, for example). I think the same concept makes sense for CSS files as well, what do you think? I'm just not sure from a performance perspective. Does it matter if we load multiple scripts with just a few lines of code? Would it be better to inline them into the HTML? But I don't like this ugly script and style injections via str_replace... So I've just added loadCSS() method as well! Regarding the AdminOnSteroids folder: I think it's nice to mention tpr's module, but I'd like to group tweaks based on what they do or where they add magic. For example I've added a "PageList" folder for tweaks that relate to the pagelist/pagetree and a "Forms" folder that relates to all kinds of forms or inputfields (page edit etc). If you have suggestions for other folders please let me know. The folder "AdminOnSteroids" makes no sense in my opinion.

Hi I'm currently developing a website for a photographer and the most of the editing needs I#m using FrontEndEditLightbox. https://github.com/rolandtoth/FrontEndEditLightbox So far so good. Now I also want to show the PageList sliding in from the side, like when clicking on the little tree in the admin area. How can I achieve this? I've already seen the xhr - request that is done when clicking and have implemented a javascript doing the same request and parsing that json. But i'm wondering if that is the right way to go? Thanks. robig

Hey @adrian I'm using ProcessPageList() to render a pagelist in my custom process module. I wondered why I only get bd() calls in the debug bar for ajax requests when collapsing a tree item, but not for the very first one. This is my code: <div id='pageviews'></div> <script> $('#pageviews').ProcessPageList({ rootPageID: 1, showRootPage: true, ajaxParams: {'rockcounter': true}, }); </script> I then tried wrapping that code in setTimeout() with a delay of 1000ms and then I got the bd() calls also for the very first request. Is there any recommended way of dealing with this? I tried to wait for dom ready, but that seems to be too early and tracy didn't catch the first request. On my laptop it works with a delay of 100ms, but in other setups it might be different, so I'm wondering if there is a solid way of waiting for tracy to capture the ajax call?

I'd need some advice how to search for specific pages that have use a certain value in a page reference field. The task is quite simple: find all pages with a certain template that also use a page reference field with a specific title. $pageList = $pages->find("template=myTemplate, {PRField->title}={$input->urlSegment1}"); I also tried to split it but to no avail: $pageList = $pages->find("template=myTemplate, {PRField->title}={$input->urlSegment1}"); $finalpageList = $pages->find("{$pageList->PRField->title}={$input->urlSegment1}"); I'm absolutely positive that I'm missing a crucial point here.

Hi I don't know if it's me. I have searched the forum and have found some related issues but no valuable answers. I just want to sort the page tree in admin in a natural order, like natsort does. I have experimented with RecursiveIteratorIterator and array_walk_recursive and a usort with strnatcmp. Nothing works as expected. Do you guys have a solution? I just want to sort my pages by page name in a natural way. There has to be a switch for that! Thanks for your help. jones

Hi! I need to restrict page tree to two branches of pages under homepage. And I don't want to show not editable pages for a user in page tree. What is the right way to do that?

Make sure: in myTemplate settings>URLs you Allow URL Segments then // decomposed example $title = $input->urlSegment1; // single $ref = $pages->get("template=myTemplate, title=$title"); // get retrieve a single result $pageList = $pages->find("template=myTemplate, prfield=$ref"); // or if many is needed $refs = $pages->find("template=myTemplate, title=$title|Foo|Bar"); // find retrieve a page array $pageList = $pages->find("template=myTemplate, prfield=$refs");

Another way you could do it... In my example the parent template is "countries" and the child template is "country", and there are 195 child country pages. Using the PageEditPerUser module the user is only allowed to edit country pages "Zambia" and "Zimbabwe": Page List before: The problem being that lots of uneditable pages are included, with the two editable pages being at the end of the 4th pagination. I'm not using Admin Restrict Branch here so (presumably) that's why all the non-editable pages are listed, but that doesn't matter for the purposes of this example. A solution is to add the following hook to /site/ready.php: // Only for a particular role if($user->hasRole('editor')) { $wire->addHookBefore('ProcessPageList::find', function(HookEvent $event) { $selector = $event->arguments(0); /* @var Page $page */ $page = $event->arguments(1); $user = $event->wire()->user; // If the parent template is "countries", restrict the children list to only the pages that the user may edit if($page->template == 'countries') { $selector .= ", id=$user->editable_pages"; $event->arguments(0, $selector); } }); } That fixes it so that only the editable child pages are shown, but the incorrect child count and unnecessary pagination controls are still visible: So the simplest thing is just to hide those things with some custom admin CSS only for the relevant role (if you're not sure how to do that something like this should work, with a check first for the user role). /* Adjust the parent template name to suit */ .PageListTemplate_countries > .PageListNumChildren { display:none; } .PageListTemplate_countries + .PageList > .uk-pagination { display:none; } .PageListTemplate_countries + .PageList > .PageListActions { display:none; } End result:

Hey, is there a way to render the PageList manually in the backend? Something like: $modules->get('PageList')->render(); / Nico

What if we make the animation able to configure so you could set a time or turn it off with 0. I'm sick of the animation taking long time when it needs to open a branch on 3-4 level. something like in the module settings of ProcessPageList or through $config? $config->pageListAnimationDuration = 100; $config->js(array('pagelist' => array('pagelistAnimationDuration'=> 0)));

Since yesterday, i suddenly get a 404 in the admin backend, trying to access ( /page/list/?id=1&render=RSS&start=0&open=undefined ). Everything else on the page works fine (as far as it possible to navigate) I enabled the debug-mode, but there are no clues given. RewriteBase is set correctly, all other pages (frontent as well as backend /setup/templates, etc) are shown - but not the page-list.. I have no clue whats wrong...?