Leaderboard
Popular Content
Showing content with the highest reputation on 06/11/2025 in all areas
-
Fresh on the dev branch: Some improvements for the toolbar (added a toggle):3 points
-
@Ana To add that type of user-facing functionality would best be achieved using AJAX. I think that this is a perfect use case for htmx which works very well with ProcessWire and is probably the fastest and easiest method to get the type of behavior you're looking for. Here's a working example of what this would look like. It takes about 5 minutes and you don't even have to leave your template file. <!DOCTYPE html> <html lang="en"> <head> <title><?=$page->title?></title> </head> <body> <!-- ...the rest of your template markup --> <!-- Your button to load more pages --> <div> <button hx-get="<?=$page->url?>?content=remaining-pages" hx-target="#remaining-pages-container" hx-select="#remaining-pages"> View More </button> <div id="remaining-pages-container"> <!-- Your additional page markup will be loaded here --> </div> </div> <!-- This page list will only render if the URL has ?content=remaining-pages appended --> <?php if ($input->get->content === 'remaining-pages'): ?> <ul id="remaining-pages"> <li>Remaining Pages</li> <?php foreach ($pages->find('your=selector,goes=here') as $remainingPage): ?> <li> <h2><?=$remainingPage->title?></h2> <a href="<?=$remainingPage->url?>">View Page</a> </li> <?php endforeach ?> </ul> <?php endif ?> <script src="https://unpkg.com/htmx.org@2.0.4" integrity="sha384-HGfztofotfshcF7+8n44JQL2oJmowVChPTg48S+jvZoztPfvwD79OC/LTtG6dMp+" crossorigin="anonymous"></script> </body> </html> Explanation. Having added the htmx script tag to your document, the htmx library is available. Here's what happens: Clicking the "View More" button makes an AJAX request to the server The URL for the hx-get attribute has been appended with "?content=remaining-pages", this can be anything you prefer The conditional block for additional pages will only render if the ProcessWire $input->get->content matches the GET variable we appended to the hx-get attribute URL When the page is rendered and response sent back for the AJAX request, htmx finds the element with the id 'remaining-pages' If an element with the id of 'remaining-pages' is found, then the contents of that element are inserted into an element with the id of 'remaining-pages-container' which is specified in the hx-target attribute of the <button> element There are some other ways that you could organize your code and return the markup, that's entirely up to you and how you would like to organize that in your ProcessWire site. This works, but we can make this more efficient. In the example above, the entire page is rendered just to get the remaining pages. This may not be an issue for all websites, but if a page has a lot of fields or other features that make database calls, then there is a lot of work being done on the server to render content that won't be shown because htmx is only selecting the content inside the element with the id of 'remaining-pages'. Here's an improvement: <!-- This page list will only render if the URL has ?content=remaining-pages appended --> <?php if ($input->get->content === 'remaining-pages'): ?> <ul id="remaining-pages"> <li>Remaining Pages</li> <?php foreach ($pages->find('your=selector,goes=here') as $remainingPage): ?> <li> <h2><?=$remainingPage->title?></h2> <a href="<?=$remainingPage->url?>">View Page</a> </li> <?php endforeach ?> </ul> <?php return; ?> <?php endif ?> <!DOCTYPE html> <html lang="en"> <head> <title><?=$page->title?></title> </head> <body> <!-- ...the rest of your template markup --> <!-- Your button to load more pages --> <div> <button hx-get="<?=$page->url?>?content=remaining-pages" hx-target="#remaining-pages-container" hx-select="#remaining-pages"> View More </button> <div id="remaining-pages-container"> <!-- Your additional page markup will be loaded here --> </div> </div> <script src="https://unpkg.com/htmx.org@2.0.4" integrity="sha384-HGfztofotfshcF7+8n44JQL2oJmowVChPTg48S+jvZoztPfvwD79OC/LTtG6dMp+" crossorigin="anonymous"></script> </body> </html> This is the exact same code as above, but here's what we did differently this time. The markup for the additional pages that only renders if 'content=additional-pages' is present has been moved above all of the other markup in the template After the closing <ul> tag and within the <?php endif ?> statement, we've added a return statement that prevents ProcessWire from rendering the rest of the page Depending on how "heavy" your template is, this could make the results appear to the user faster and very little work was needed on our part to do that. There are things that you can explore to make use of other ProcessWire features and improve the readability and/or reusability of your code Rather than using a GET variable, you could choose to use URL segments in ProcessWire to create and respond to a more natural URL You could use the render feature of FileTools in ProcessWire to store your remaining pages markup in a separate file You could use a GET variable such as "count=6" to set the number of pages to return rather than hard coding it Those are entirely optional, the example above is all you need to implement the feature you are looking for. Some notes on htmx If you use a build tool and npm, you can add htmx to your project as a package rather than the <script> tag htmx offers an easy way to create a 'loading' animation to let your users know that the button is retrieving the remaining pages while the AJAX request is being processed Hope this is useful for your project! The code example really did take only 5 minutes (maybe less!), without one line of JavaScript. If you prefer using a JavaScript oriented approach with JSON and markup such as the <template> tag as @TomPich mentioned, the same thing could be achieved using Alpine.js which is an easy way to add enhancements to your templates without the need for a full front end framework (just another personal favorite).3 points
-
It seems you are getting used to toggles... 😁1 point
-
Thank you, @elabx. I changed my image urls from `$img->url` to `$img->URL`, and they now work as expected.1 point
-
Thanks for the link.1 point
-
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.1 point
-
You can do this with the $buster API1 point
-
I use the RepeaterMatrix in most of my installations to build page content. To make elements visually easier to grasp, I use the option to adjust the colors in the item headers. Unfortunately, this no longer works with the new theme. Original: New Default: New default with @ryan's admin-tweak.css @adrian I agree with that. In my opinion this is not a good user experience. The "old" style was a lot better/faster to scan.
1 point -
Hey folks, sorry for not responding earlier; I was swamped with work and then got sick afterward. Thanks for all the feedback so far! And thanks again, @ryan, for asking and trusting us to help with the redesign. The discussion seems a bit heated, but that only shows how passionate the community is about PW. I will leave it to @diogo (he is on vacation for a week) and @ryan to answer some of the technical concerns, as they are the ones doing the implementation. Just know that we are reading and discussing them and take them seriously. I want to add a bit of context to our general design approach and goals with the redesign of the theme and PW website. You might not agree with everything I am saying here, and that's fine. I don't claim to be right in all of it; this is just our current approach. We started out by asking questions to Ryan, reading the forum, and identifying problems with PW's current marketing and brand strategy. As well as doing research and comparing other CMS offerings to PW. here is what we found out: PW user numbers seem to be stagnating (not a lot of new users on the forum). PW's marketing mostly seems to speak to developers (= making clients, agencies, content creators, marketers, editors, and designers look for other options). Lately, more and more of our own clients had been choosing other CMS options over PW because they said it looks too "technical" or "dated" (they looked at the PW website). The design of the PW homepage is too "crowded" to identify the most compelling features of PW (= clients couldn't understand at a glance how PW can solve their problems). The PW website lacks recognition (basic UIKIT look) and doesn't look very approachable/friendly for newcomers. The way the admin backend is shown on the website is not very attractive, and the theme itself looks dated compared to other CMS solutions. The look of the website doesn't reflect most of PW's brand values (Flexible, Powerful, Simple, Easy, Friendly, Open, Secure, Stable, Free). And here are some of our goals with the new website and theme design: Attract new users to PW (developers are still the main target audience, but we want to target a more diverse group of users, see above). Make PW more approachable for new users. Keep existing users happy. Make the PW brand more recognizable. Better highlight PW's strengths and key features. Communicate PW's brand values through the design. Improve the docs. Make it easier to find modules. We realized that it would not be enough to just redesign the website, as the admin theme is the "main product." If people check out the new website and we can make them interested in PW, the second thing they do is install the CMS. So it's important to have good-looking defaults for the new theme that are coherent with the new website, as new users won't do a lot of customization. The reason we decided to include a dark mode in the admin theme is also mainly to appeal to new users. I personally don't care much about a dark mode, but for some it's a selling point. This trend can also be seen in other CMSs that now support it. I hope once the website is launched, it will be a bit more clear where we are going with this. Also be aware that we are not getting paid to do this, we did it because Ryan asked us and we love PW. But our time is limited and we have to make the most out of it. We will probably not achive all of these goals immediately, but we hope to set a good direction for things to come.1 point
-
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...1 point
-
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 🏆1 point
