Leaderboard

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 🏆

We will look into adding these. Okay, can look into this too. This is supposed to be low contrast because it is non-essential information. It's the sort of text that we don't want to have your focus unless you are specifically looking for it. Admittedly I like the contrast, but I also like anything easy on the eyes, so will definitely give it a try. I'm not seeing it currently, but have definitely seen it before, and before the new admin design. I think it is related to the Inputfields JS for 'showIf' dependencies rather than the CSS of the admin. Look closer, there are definitely functionality upgrades here. Just to name a few, the masthead is now sticky and always available, the navigation dropdowns are quite a bit better as they scroll within rather the whole page, the top search now acts more like a command palette (with its own hotkey), and much of the admin appearance can now be easily styled with CSS variables.a I think forcing is a strong word for giving people the option to decide whether they want to use the Original look or the new Default look. In your case it sounds like you'd want to continue using the Original style for AdminThemeUikit. As mentioned a couple of times already, it will always be there, it's not leaving. That's correct. It'll be the default on new installations. The Original option will be there for new installations too, even if it's not initially selected. Users on existing installations will have the option of switching to the new default look if they want to, but it won't be the default on existing installations except on the dev branch while our beta testing proceeds. Do you mean the headers of repeater items, or literally the inputs? I like using the main-color as the background color for AsmSelect items, PageAutocomplete items, and repeater headers, so that's part of my custom CSS. @cst989 Sorry, I'm not trying to call you out. Having a cake to decorate was meant to make you laugh. We have a diverse community with lots of different opinions on design, and all are valid, I didn't mean to suggest otherwise. I've been trying to be clear that I'm no authority on design, and so that's why I'm trusting full time trained designers that know PW really well. They have a lot of success stories in their portfolio, and I'm confident PW will be one of them. But design is always tough because it's so subjective. For your preferences, it sounds like the new design isn't a good fit, and that's fine. But if you like the Original design, then know that it'll always be there too. ProcessWire is slow to get new users in large part because our admin and website often look dated to people that aren't already familiar with ProcessWire. I'm pretty sure that group of people will be more likely to explore ProcessWire with the new design. I think once you see the new website, the overall branding picture will be a lot more clear as well. I don't expect anything designed to appeal to everyone, but I'm confident this will help PW to grow.

@AndZyk Yes, my preferences mostly align with yours on this, so this is the sort of thing I've been experimenting with in my custom styles (repeater headers, asmSelect items, etc.). Though for me it does kind of depend on quantity of items... sometimes I like the lighter touch, other times I prefer the darker (main color), so I'm still kind of hashing out where to settle. For Repeater items, since they open and then represent the toolbar for an entire item, I do think they might potentially benefit from having headers with a darker background, at least when open. What quantity of repeater items do you typically deal with? What do you think about the idea I mentioned above where closed repeater items are light, and open ones (or maybe even hovered ones) have a darker header that uses the main-color (and light text)?

@diogoDo you have anything planned for these bigger changes already? I have a vision in my head how the ProcessWire backend could look more modern and at the same time be faster to use and cover more use cases, especially when ProcessWire is used for applications rather than websites. If you're planning on working on more profound changes I'd love to discuss some ideas.

Funny how it is completely the opposite for me / my collogues. I thought the more "bulky" design of the native repeaters was too much. More like: "You can't see the forest for the trees" (German: "Vor lauter Bäume den Wald nicht sehen"). The reason why I prefer more the way of Berhards RockPageBuilder. Where the content elements not jumping in your face. So the new design is here more align with our prefer in the agency i working.

Hello @ryan, I meant the headers of repeater items. For my taste they are to subtle in the new admin theme and should be styled more likes button, as they were before. They contain most of the time the most content in my case and therefore should be styled more important. Regards, Andreas

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

I've installed the new admin theme right after it has been release and was really please to see all the changes that have been made. ProcessWire is my CMS of choice since fourteen years and i must say that seing changes in the admin is quite refreshing and I want to thank @ryan @diogo and @jploch for their work. Many concerns and feedback have been raised since the release and I'm confident that they will be addressed/fixed for the final release. @MSP01 As stated by Ryan the original UIKit will still be available (though not as default). Regarding the color palette setting one that is pleasing to your eyes is as easy as tweaking some CSS variables in the admin.css file.

@ryan I didn’t fully test the new admin yet but I have these few quick questions: Are the "reno" and "rock" styles going to be converted into themes to normalize things? This way it would clarify how to create a new theme if one takes a look at the AdminThemeUikit code. Expect for inputfields.js, is the "templates-admin" folder (or its content) still needed?

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.

Well, I was trying to be polite, but since you decided to call me out like this... by attractive I meant a nice UX, easy to use, clear to see how and where things are interactable, clean, well spaced out, nice inputs that look interactive and are reactive etc etc etc. I have been in this industry for 20+ years, so you don't have to tell me what's important in a UI. A system people have to use every day has to be enjoyable to use, but it should inspire a feeling of using a professional, high end product. Again to reiterate I was not trying to be dismissive of the hard work here and I will continue to use the product and pay for the excellent pro features etc, maybe a few of us devs will get together and just maintain the UIKit theme if it will not be used for new features in the future by default. But I didn't really appreciate the suggestion that I missed the point, while admittedly that was on me and my own poor choice of words.

After using it for a week, I must say I'm not happy about the end result of this update. Processwires backend has never been especially sleek or modern looking. But it is usable and clear for the most part. Ryan said he's not been a designer in a long time, and while that maybe true his version of the UIKIT admin is far better than what this update provides. This new look basically just makes everything look more gray and drab and at least to my eyes, even more old fashioned. I'm not seeing any new functionality anywhere either, which to me would have been a far bigger upgrade than having a new skin, that seemingly isn't even optional but will be forced on everyone! I think overall it's a step down and at best it's a sidegrade. I really hope the current admin version stays on as a version you can choose to use!

The latest additions/improvements of the module [v0.5.0]: Template file structure Stubs are now namespaced into subfolders per DataTable (column_templates/<table>/<slug>.column.php) instead of a flat directory. TemplateGenerator::getTemplateFilePath() and createTemplateFile() updated to build and create these subdirectories automatically. Legacy-stub upgrade loadColumnTemplates() now checks each stub for a return function(...) signature. If missing, it archives the old stub (prefixing its filename with _) before regenerating a new closure-based stub. Page-property handling Unified list of core properties driven by getStandardPropertyLabels() (including status). All Page-property stubs now use return …; inside closures and map bitmask flags (status) to human-readable labels. Lets look a little closer at the switch to closures for the column templates and an export/import feature. We planned this from the beginning and now switched over to a slightly different approach for the tiny template files used to display the data in your columns. The mechanism of those templates remains the same, but the performance gain is huge. Especially when dealing with lots of columns and rows: OLD: echo htmlspecialchars((string)$value); NEW: return function($value, $config = []) { return htmlspecialchars($value); }; Anyone who tried to create a DataTable gets column templates automatically created. They support the most common field types in ProcessWire and format the output initially in a simple but (hopefully) useful way. If you then tailor the output exactly to your needs, sometimes it would be handy to just save those micro templates for further use. Well, we are just developing export/import features for that purpose: Just export your global and dataTable settings as JSON and your column templates as ZIP and reuse it, manipulate them, share them 😉 and then use for migrating or easy duplication of tables. Here are some screenshots showing its (yet rather ugly) interface in action. We assume you want to port existing dataTables to another processWire site using the same data structure. Well start with a fresh install of the module We upload our exported JSON file, that contains data like this: { "moduleConfig": { "checkboxYesLabel": "Yes", "checkboxNoLabel": "No", ... }, "dataTables": [ { "name": "orders", "title": "Orders", "data_template": "rockcommerce_order", "data_selector": "", "columns": [ "rockcommerce_paymentid", "status=rockcommerce_paymentstatus", "rockcommerce_paymentdate", "order=meta", "rockcommerce_net", "total=rockcommerce_net" ... After importing we immiatly see the result of the import displayed as DataTable with, at the moment, default fieldtype templates as column templates: But at the bottom of each DataTable there is more: SO in the next step we import our prior fine-tuned column templates and immediately get a much better result: Under the hood the "old" default column templates that were created after importing the JSON config are not deleted, the get prefixed with an underscore in case you already made some adjustments before importing other column templates. Of course one can also manually copy column template files from one install to another but we found it more practical to let the module handle this. Especially when building new sites or testing, be aware that an uninstall of the module always wipes out the entire column_templates directory. So you better export before uninstalling! We are still working on the interface because it hurts my designer sensibilities to look at the UI of the import/export section. 😉 What do you think? What could be further improvements? Cheers to all of you and have a productive week!

There are quite a few threads here where users report ProcessWire repeatedly logging them out (see below). I, too, have had this problem intermittently over the two years I’ve been using PW. I was able to reduce the problem somewhat about a year ago by turning fingerprinting completely off — but the problem has never completely gone away. I’m now at my wits’ end: I was unexpectedly logged out a half-dozen times again earlier today, though I could never see a pattern. As of an hour ago, though, every single time I try to update a field definition, the change is discarded and I’m logged out. Using a different browser helped for a few minutes, but then it began having precisely the same predictable problem. Fingerprinting is off altogether ($config->sessionFingerprint = false;). CSRF protection is off ($config->protectCSRF = false;). I have installed the Session Handler Database, so my /assets/sessions/ folder is empty. This is my PW development environment, running on my MacBook Pro (M1 Max, current MacOS) via DDEV and Colima; restarting the environment has no effect. I do use Cloudflare WARP/1.1.1.1 on my Mac, though that shouldn’t be relevant; turning it off has no effect. session.gc_maxlifetime is the default 1440 session.gc_divisor is the default 10001 I would like to fix this problem for good and never see it again, so that I can get back to far more important work. Does anyone have any ideas? --- Chronological (probably not comprehensive) list of relevant threads that I’ve read thoroughly: