Leaderboard

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.

For anyone who saw the forum post about our ProcessDataTables module: you can absolutely reproduce the same output and functionality (even more complex one if you need to) using that module. UserDataTables, however, gives you everything entirely within the backend—no need to touch or customize any PHP templates. If you need DataTables in your backend beyond just user-related data, choose ProcessDataTables—it’s designed for exactly that. We’re aiming to release a stable version by next week.

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 🏆

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

The Uikit theme will continue to be our default and primary theme. And AdminThemeUikit was upgraded with the ability to have themes (or sub-themes) within it. The new "Default" theme is such a sub-theme, a layer on top of AdminThemeUikit. When that layer is turned off, you are back to the "Original" output, without a theme layer on top of it. So AdminThemeUikit will continue to be developed as it is, with the Original look. And themes like the new "Default" will continue to style that output in a way that varies from the Original. But the Original is still the base/foundation of it. The intention is that others can also develop additional sub-themes on top of AdminThemeUikit, using modules. This theme-ability of AdminThemeUikit is not yet documented, but it will be.

At first you should check the errorlog. To find it go with FTP to site/assets/logs/errors.txt Normaly it is easy to update Processwire with simply upload the new wire-folder, index.php & .htaccess to your server (it depends a bit on your previous PW-Version) Here you find the Upgrade-Guide -> https://processwire.com/docs/start/install/upgrade/

@ryangorley I haven't tested on the new theme but this has happened to me before with fields configured for example to hav a with of 70%, but instead ProcessWire's js compensates if it doesn't have a 30% element next to it (not the exact logic, but I hope I make my point through)

Ever needed a color picker on some kind of settings page? Didn't want to install and setup a full-blown colorpicker module? Here's a quick and dirty hook to change a regular text field into an <input type="color"> type of input: Before: After: <?php public function init(): void { wire()->addHookBefore('Inputfield::render', $this, 'changeFieldType'); } public function changeFieldType(HookEvent $event): void { $f = $event->object; $colorFields = [ Site::field_col_primary, Site::field_col_secondary, Site::field_contrast_primary, Site::field_contrast_secondary, ]; if (!in_array($f->name, $colorFields)) return; $f->attr('type', 'color'); } So right before the text input is rendered we change its "type" property to "color" and the browser will render a default color picker 😎 It once more shows how versatile ProcessWire is. And maybe it helps someone... 🙂 PS: Be advised that with that hack you only modify the optics of the field. The field will under the hood still be a regular text field, which means you'll not get any sanitisation or such from it and you might have to take care of that on your own. In my case it's a superuser-only settings page. So it is no issue at all.