Leaderboard

Thank you for your response, @jploch. I really appreciate when a conversation is held at this level. Regarding data on user preferences: We have such data because we regularly collect it during design processes for user interfaces through test series. These tests have shown us a clear pattern so far: decision-makers—i.e., those who pay for the project—are generally drawn to sleek, modern, and shiny interfaces; those who actually work with them (daily) prefer a bit more color in the interfaces because it allows them to orient themselves more quickly. Of course, I agree that one can fine-tune the use of colors in the “Classic” style of the admin theme, but our clients – or rather, those who actually worked with it 😉 – have always been happy with the look and feel. By the way: in our view, a CMS is not meant to reflect corporate design any more than MS Word, InDesign, or any other software solution is. Since you want concrete feedback and suggestions, we are currently developing a small test tool with the most common UI elements that we use in the backends we manage to identify any potential issues. We usually provide our clients with 2–3 different admin themes that they can choose freely. (That is also where our data comes from.) Here is a first example (more to come) showing why we would like the option for a second color – on the left, the AdminTheme UIKit “classic” style; on the right, the new “default” style: By the way, we really like the decision to have the open/close arrow point in the correct directions! In closing, we would like to thank you again for the openness of the discussion and your willingness to engage! As a design agency, we unreservedly support your stance on “design by committee.” At the same time, we also understand developers like @bernhard, who have invested a lot of time in creating their modules and make their living from it, and who would have welcomed a discussion beforehand. At frameless, we have been convinced by ProcessWire for many years and use it for every web related project we develop ourselves. We currently see an opportunity with this redesign to position the platform as effectively as possible in the changing market for the coming years. So, thank you for your thoughts and implementations!

Very well said. Although if you start inviting module developers into a conversation where does/should it stop. I agree with the way this was approached, and the dev branch has always been available for this sort of thing. Some of the criticism has come across as negative but I don't think it was meant to, it seems everybody wants the best from this especially KONKAT.

Which approach to take depends on where you want the added markup to appear, relative to things like description and notes. Demo: $wire->addHookBefore('InputfieldText::render', function(HookEvent $event) { /** @var InputfieldText $inputfield */ $inputfield = $event->object; if($inputfield->name !== 'text_1') return; $inputfield->prependMarkup('<div>prependMarkup</div>'); $inputfield->appendMarkup('<div>appendMarkup</div>'); }); $wire->addHookAfter('InputfieldText::render', function(HookEvent $event) { /** @var InputfieldText $inputfield */ $inputfield = $event->object; if($inputfield->name !== 'text_1') return; $event->return = '<div>before render</div>' . $event->return . '<div>after render</div>'; }); Related request: https://github.com/processwire/processwire-requests/issues/536

I honestly quite like much of how the new theme looks and appreciate lots of the decisions and work that has been put into it. It's the problems with tweaking it that are proving the killer for me - css vars should make it easier, but they way they currently are is making it harder. Please try to change the top menu to a darker background with white text you'll quickly notice that many side-effects aren't easy to fix. The problem is that if it doesn't work for some modules but the project developer really wants to use it (or their client does) but then later they discover a new module they want to use doesn't work well with it, then what to do?

They don’t have to be. It’s for my own reference and documentation, since I maintain the module PHP. I could delete the lines defining those settings and it would make no difference. If a 3rd party adds another theme in the same way, any of its custom settings defined in its config.php file will get stored alongside those of AdminThemeUikit in the same way. That’s why they are namespaced with the theme name, i.e. the prefix “default”. I agree. The main/master branch will keep existing installations on the Original theme. But on the dev branch, I think we have more room and I didn’t think most would know about it unless they were in our small regular group of people that visit here. We want to encourage those on the dev branch to use and help test it. If the original theme is selected, none of the other theme settings (like dark mode) appear. The feedback I’m referring to is “this theme is fundamentally wrong”. That’s a broad overarching negative statement referring to the entire theme and by extension those of us working on it, and I’m not sure how to read that as anything other than dismissive. To be taken seriously, I’d suggest wording like: “My opinion is that [some aspect] of the theme might work better if [it did something you suggest]”. That way you narrow down to specific things, and not the overall project and people. Anyway, I think you’ve already been following up with more specifics and GitHub reports, and that is useful feedback. Whether helpful or not, it is the true reason why some things may not be appearing the way you expect at this stage. When it comes to Uikit features that we have not used in ProcessWire, we would not have known to style them, and would not have provided custom styles for those. So if you don’t report them, we won’t know about them. I think it may have appeared that we accounted for them before because there was no dark theme to make them obvious, and the fallback Uikit styles weren’t too objectionable. I think it’s good the dark theme is pointing out the things that we hadn’t thought to give design consideration to before, because now we can. Can you be more specific? I don’t think it’s too late for anything. But if your definition of “anything” is “everything” (i.e. “throw everything out and start over”) then that is not something I’d consider. Personally I love the new theme, it’s exactly what I think was needed, for new users at least. When it comes to the design and CSS behind it, I consider this more outside my expertise, so I aim to learn from it. I’m interested in the quality and usability of the result and not as concerned about how it achieves that result. Though I do like the technical aspect of the CSS variables, where I can customize so much without having to compile anything. I’m running my own custom version of the theme (with a custom CSS file) where I’ve been able to tweak things exactly as I like them with very little effort. That’s good, and if we were starting from scratch and building a new admin theme from the ground up, I think we might take a similar approach. But we are talking about a new skin of the existing admin theme with a focus on attracting new users. This is not about reinventing the wheel, it’s about making design improvements to what’s already there. This project is not about implementing everyone’s feature requests (though that is an ongoing and long-term goal). There is no budget and nobody is getting paid. It’s funded entirely on the generosity of KONKAT. They are donating their skills and time to benefit all of us, and the entire project, and to help ProcessWire grow, and I’m very thankful for that. They are a business, not a charity, so they have to work within their bandwidth and means. So it’s up to them to decide how best to work with the time they have. I don’t follow. Either you are confused, I am, or we both are. Dark mode is experimental because it is something new we’ve not had to account for before. So there are likely more situations to uncover and fix in dark mode than light mode. But I also think it is here to stay. If there are people that don’t want it or have situations where it’s best not to have it, it’s completely optional and can be disabled site-wide or just for specific cases or modules.

Thank so much @bernhard, very grateful for your time and efforts. Holding thumbs for results.

Thank you. Thank you.

There is a lot of talk about “design by committee,” which I also think is wrong. But nobody asked for this, not even @bernhard. I have followed his posts very closely and all I can see is that he had hoped that the community would be consulted before the design phase. And I absolutely agree with him on this point, because if wishes and ideas had been solicited beforehand, I am quite sure that this thread would have been much less emotional. Now to my “problems” I currently manage nearly 50 active ProcessWire projects, and the advance announcements of a more modern admin theme naturally raised expectations that have now turned to disappointment for me, as many of my installations run on UIKit-based custom modules that are sure to cause problems with the CSS overrides. For me, this means that all development systems will soon need to be updated to the DEV version in order to identify and address any problems. I hope to find the time soon to contribute constructively to improving the theme.

@bernhard We value your input very much and I think you are a blessing to the PW project. But currently I am focusing on covering the general design concerns. Since Diogo is out of office I would like you to give us some time for a proper response. But let me quickly address one of your main concerns. I agree that we should make an effort to keep the CSS layers as low as possible, at the same time I see a lot of benefits of CSS vars (also for module development, e.g. for PAGEGRID in my case, we can get into that later). Initially Diogo had the idea to base the new theme/skin on the stripped down version (without the reno-less files) you are using. I'm not sure what impact that had at the time or why we didn't do it. And maybe there's something I'm not considering at the moment, but to me it makes perfect sense to remove all Reno styling from our theme and use the base UIKIT as a foundation.

Serious question: If it's not too late for anything, then why is feedback like this not considered to be helpful? What I tried to point out is that when using UIkit like explained in their docs, then we would not have these issues at all. To change the primary color all you'd have to do is this: @global-primary-background: red; Then all primary buttons will use that color. All progressbars will use that color. All UIkit components will use that color. And any component that they might add in the future will use that color as well. Which means that any developer in the world can not only use what the core uses but anything UIkit has to offer. Framing that as "features that ProcessWire traditionally did not offer" is what I consider as not being helpful. We, on the other hand, are using thousands of overrides at the moment. Anything that Diogo didn't think of will possibly cause issues. Cause frustration or ugly fixes on our side and cause Github issues on your side and I think your time can be spent better. Seeing reno green shine through tells me that the new theme must be extending (if you don't want to call it overriding) the reno theme and not the base theme, that I carefully split apart from the reno theme in 2021 to make exactly that possible: Properly extending the base theme without applying layer by layer of overrides. Exactly like you mentioned with PHP classes. What I see in the new theme does not match what I read in your announcements and explanations, sorry. I consider that to be a very valuable feedback for anyone that is open to hearing it. Unfortunately for many reasons I got the impression that it's too late for such input. And I understand that this is a difficult situation. That's why I apologised. It does indeed not help if anybody complains about fundamental issues if it's not possible to change them. I get that and as I said I'll try to be more constructive with that situation. But please don't pretend that it's not too late for anything and that we are at an early stage in the process. This feels dishonest to me on my cost. Obviously I also do not think that micro-managing a professional designer would be helpful and that's not what I have been suggesting. I just don't see anything wrong in asking the community for input upfront. At least that's what I did with my calendar module and I think it was a very helpful and pleasant process: What features should a PW calendar module have? The community was just as great as it has always been. It does of course not mean to ask the community to decide every button's color. But it might help to reduce the risk of having blind spots. It might make the process even more creative, not less. It might help in making the community feel heard, accepted and valued. And it might even help in saving development time by cutting on features that sounded/looked cool at first but raised serious concerns in the community. And one more thing about the term "secret": You have some good evidence here. It was not my point though, and it might have been more constructive to ask me what made me feel like that than proving me wrong. I know I'm not the only one feeling like this. English is not my first language, but that sounds ironic to me and I'm not sure if it is the best time for being ironic after I apologised. I'm not sure how a user will feel when using dark mode for everything and some pages suddenly appear in light mode, but at least this means that it's no longer a go/no-go decision when somebody wants to use one of my modules, so thank you for that. Do i interpret this correctly as that darkmode is not any more considered to be experimental and is here to stay? --- @ryan please be reminded that I still very much admire what you have built and achieved. I'm sorry that you have expected a different feedback. But I hope it's ok to not only cheer if we like what we see but also raise our voice if we don't. Thx and all the best

Thanks for the feedback. We have a color for Delete/Error/Danger, that should be used in this case. I would consider it a bug if that is not the case. Adding the class "uk-button-danger" should do it, but that doesn't seem to work. We will fix it, I think we need to carefully go through the UIKIT docs and cover all the color based classes they are using. It should look like this: on a side note: To me the contrast of the secondary button of the original theme is way to low, I know that it is supposed to be muted, but it is barely readable. And the blue field title on light blue background is also to low in contrast.

Thanks for asking. Yes I think it would be helpful to have specific feedback that expresses functional concerns like this. But I think your feedback was in line with that. About the concern that less contrast is easier on the eyes for text: I agree that harsh contrasts (eg. Black on White on screens) can be a strain on the eyes when reading long paragraphs of text, at least for me. But we usually don’t have a lot of text that is black on white. E.g. the field descriptions and notes are muted and text inside inputs, textareas (also tinyMCE) are on light grey. It’s also important that the contrast between the dark and the muted text is big enough to establish hierarchy, so I would not go to light with it. We also have dark mode now, which is supposed to be easier on the eyes, so if a editor writes/reads a lot of text they could switch. I would also be interested if there are any studies that show that this is actually a thing. I feel like mostly on the web we have the opposite problem that text contrast is too low for reading. E.g. on the original theme the contrast with the muted blue text was too low and was not in line with Web Content Accessibility Guidelines.

Would you say @jploch that what you want are expressions of functional concerns (e.g. "I'm having a hard time knowing this is expandable", "The text is hard to read", etc.) instead of design preferences (e.g. "Make the buttons bigger", "Make all the text brown")? I suggested at one point that less contrast was easier on my eyes when reading a lot of text, but maybe that was too design-by-committee-like. What would helpful feedback look like?

The term @ryan is referring to is called "Design by committee". Here is what Gemini says about it: "Design by committee" is a pejorative term used to describe a project, product, or design that has been created or approved by a large group of people (a committee), where all input is treated equally and decisions are made by consensus or compromise. The common saying, "A camel is a horse designed by committee," perfectly encapsulates the idea: the final product often lacks a clear, cohesive vision and can be over-complicated, ineffective, or even nonsensical, as it tries to incorporate every individual's idea and preference.

It's somewhat experimental (never got to use it much), but for SearchEngine there is also an add-on for indexing file contents (plain text, PDF, and most "office formats"): https://github.com/teppokoivula/SearchEngineFileIndexer. Honestly not sure how well it works at the moment 🙂

@bernhard I like your thinking 🤝 @Tiberium I'm glad you chimed in as well. Good to know that there are many people that will benefit from a new feature. Here's the UI I'm working towards: Going to create a new header action for translation related features. This will keep the UI tidy, clear all will be enabled by default, and doesn't need an option to enable/disable it on the module config page. @bernhard The icon to show the translator will be moved from the icon next to the translation button to the menu for consistency, since it's hover there won't be extra clicks. It will of course politely ask you if you are sure you want to nuke all of the content... I like this implementation because it will provide a good location for possible future features as well without crowding UI for fields. It will take a little bit to implement, I'm trying to keep up with work and I think I caught a bug with the custom header actions in PW core. I'll tag you both when it's on the dev branch so you can take it out for a test drive.

Hey everyone! Fluency v2.1.0 has been released with new features and bugfixes. Translation cache now caches translations permanently until cleared on the module config page when translation caching is enabled. Some Fluency methods are now hookable. Refer to README for documentation and use case. Credit to @Hari KT for inspiring this feature. Globally excluded strings can now be entered either one per line or all on one line separated by a || (double pipe). Credit to @bernhard for the feature suggestion Translating static strings using the ProcessWire translator now offers the ability to specify the language code to be used for the source language Fix issue where strings configured to be excluded from translations on the module config page were being translated. Credit to @bernhard for finding and reporting Correct issue where custom language code field that may optionally be added to ProcessWire language pages was inconsistent and incorrectly documented. Fix missing localization strings for some errors Various small improvements, some bugs that had not yet affected regular usage Various housekeeping and code cleanup that only matters if you like reading the source 🤷‍♂️ Thanks all, and please report any issues!

I'm looking to add an icon next to the page title in the page tree, similar to how pages in draft state (with ProDrafts) can be identified by the little paperclip icon. What is the best way to go about this? I tried diving through the source code of a few modules and I suspect I need to hook into 'ProcessPageListActions::getExtraActions'?

You can use custom page classes and add a getPageListLabel() method: It can be a problem though that this markup also ends up in the main navigation and also in page select fields. You can hide those elements via CSS though: // site/classes/YourPageClassPage.php public function getPageListLabel() { return "<span class=foo>foo</span> " . $this->title; } /* /site/templates/admin.less */ .PageListPage.label .foo { border: 2px solid red; } Another option is to use RockMigrations + MagicPages, then you can simply add "pageListLabel()" instead of "getPageListLabel()" and you'll get the modified label in the pagetree but not in the menu. This is the hook I'm using: https://github.com/baumrock/RockMigrations/blob/85c28fb97411f2af1ab3c77d3911b777d3f77ccf/MagicPages.module.php#L268-L290

Hi, I using the Processwire 3.0.231 and PHP 8.3 and I am seeing some PHP Deprecated warnings on the Tracy Debugger related to the AdminOnSteroids module. This is also happening on the PHP 8.2. These are the are the PHP Deprecated: - The lines might be a little bit off because some of the warnings only showed after fixing the first ones. #1: PHP Deprecated: str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in .../site/modules/AdminOnSteroids/AdminOnSteroids.module:1572 #2: PHP Deprecated: Function utf8_encode() is deprecated in .../site/modules/AdminOnSteroids/AdminOnSteroids.module:1779 #3: PHP Deprecated: Function utf8_decode() is deprecated in .../site/modules/AdminOnSteroids/AdminOnSteroids.module:1797 And these are the fixes that I have patched/fixed on the AdminOnSteroids.module: For the #1: - Original code: $inputfieldClass = str_replace('Inputfield', '', $f->inputfieldClass); - FIX: $inputfieldClass = ((property_exists($f, 'inputfieldClass'))? str_replace('Inputfield', '', $f->inputfieldClass) : ''); For the #2: - Original code: $pageLabelField = utf8_encode($pageLabelField); - FIX: $pageLabelField = mb_convert_encoding($pageLabelField, "UTF-8", mb_detect_encoding($pageLabelField)); For the #3: - Original code: $page->template->pageLabelField = utf8_decode($pageLabelField); - FIX: $page->template->pageLabelField = mb_convert_encoding($pageLabelField, "UTF-8", mb_detect_encoding($pageLabelField)); It is possible for you to update the module so it will be fixed on the future installations? Thank you for your time

I catch the login throttle messages and pass them to a session variable which is displayed on the login page: // login user try { $u = $session->login($username, $pass); } catch(Exception $e) { $session->logout(); // without this line the user will be logged in although the exception is thrown $session->login_error = $e->getMessage(); $session->redirect($pages->get('/login/')->url); } Strange thing is that without the $session->logout(), my login page will show the error message that is thrown by the login throttle but still login the user. Is this intended behaviour?