Leaderboard

What we are doing here is basically reinventing the wheel. We are trying to invent a new design system that makes it easy for developers to be used and to be customised. But we already have this design system. It is called UIkit. It is in the core. It is built on logical and semantical components (base, text, buttons, background, utilities, ...) and it has thoughtfully defined and well documented (!) variables and concepts. Yes, it uses LESS (or SASS), which is not the coolest technology on earth. But this decision has been taken by @ryan in 2017. If the decision was that CSS variables are superior and we proceed with them: More than happy! I'm using CSS variables all over in my projects (on the frontend). But keeping UIkit/LESS as the foundation and then adding a new theme with 3200+ lines of overrides just does not fit with the genius and beautiful image that I have had of ProcessWire. To me it looks like somebody was decorating a cake here. Adding layer over layer to make the cake look good. For me it just doesn't taste 😞 It never really did (ui-button vs. uk-button-primary, etc), but it was ok. It was the reality that I grew up with. Now it's different. Now things got a lot worse and I think this was not necessary. I guess I was hoping that all the effort that was put into a new admin style would bring some fundamental improvements of the overall situation. @ryan, you have pushed so many great updates over all those years and you have solved so many problems in a way that just left me behind with deep respect and amazement. Now we have yet another layer of complexity to deal with when working on backend modules. I'm not happy this time 😞 I appreciate all the effort that you put into making PW attract new users and I understand that it must be frustrating to get such a harsh feedback by some of us. Especially after putting so much work into it. The thing is: It did not have to be like this. Why not ask the community upfront? Before all the work has gone into it? To have an unbiased view? To keep the risk and emotions low (for everybody)? To hear what others might think of such a fundamental change? To get feedback and maybe even good ideas? Or to explain what is considered to be fundamental and what is considered to be experimental? The question is: What now? The decision was obviously taken long time ago, so I guess we have to deal with it (even though I think it would be the best to take it back completely). If you ask me - as a long term member and contributor - what I'd like to see to make things less painful for now and make things better long term, here are my suggestions: make the css variables used in the new theme be aligned with UIkits less variables (--main-color vs. @global-primary-background ...) remove dark mode completely, or, at least, disable it by default and add a warning that it is experimental - I think it will cause 99% of work for very little benefit add docs for the new theme and the concepts it uses rewrite the whole admin theme/framework from ground up with a modern stack (css variables + Alpine JS + darkmode) as soon as possible Thank you and all the best for the future of ProcessWire

Ah, almost forgot about the toggles vs checkboxes. Independently of what is decided concerning the usage of toggles, our css selector is clearly too aggressive and id trying to turn, into toggles, some checkboxes that should be left alone. We’ll need to fix that. Funny, just before submitting, i noticed this 😆

Thx @rastographics cleaning up old todos and just found your message! did you solve your problem? Thx for the hint about the docs, I've added a link to baumrock.com 🙂

@Jonathan Lahijani just pushed this to v3.6.0 🙂

I really agree with @teppo here - setting css vars outside of the root context seems dangerous. I am not expecting an infinite number of css vars, just not reusing of ones that don't seem semantically correct, like my example of --masthead-active-color also being used for all submenu items and --muted-color being used for hidden pages along with page list actions. It honestly feels like --muted-color may as well be called --light-grey in the sense that it's describing a color, rather than a usage which defeats the flexibility of css vars. I'd be happy to compile a starting list of the vars that I think we need (and what they should be used for) and then have other passionate and skilled folks her chime in to help refine. I think with a little brainstorming we can end up with something really powerful and flexible and all defined at the root level.

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 🤷‍♂️

https://www.youtube.com/watch?v=EoEeRWHJ8xs A checkbox is a checkbox and should not be confused with a toggle, I think. A toggle is not a skin for a checkbox. https://infyom.com/blog/user-interface-design-tips-checkbox-vs-toggle-switch/ https://uxdesign.cc/the-good-the-bad-and-the-toggle-2abc0fbbd099 Quotes: A toggle switch requires two steps: selection and execution, whereas a checkbox requires only the selection of an option, and the execution/saving action is normally required later or at a different area. Usage recommendations Do not use toggles in forms. Use checkboxes or radio buttons instead. Do not use toggles in filters or multiple selections of elements. Inhale. Use toggles for settings and changes that have an immediate effect on the UI (same applies for the segmented control). Avoid mixing toggle button groups and segmented controls. Exhale. Avoid using switches with multiple options.

I don't have strong feelings about checkmark style versus toggle style checkbox controls. It sounds like some people do. I'm fine with regular checkmark style being the default rather than the toggle style, but I divert to the designers. I don't understand the strong feelings because they both represent the same selected (1) or not selected (0) states. You posted a screenshot with "light" (left) and "dark" (right) labels, and that is not what we are doing. Those labels make it represent something else. That relates more to our dedicated toggle Inputfield, which has an entirely different appearance. In the physical world, the checkmark style represents something we would do with a pen, and the toggle style represents something we'd do with our hands on a machine. If I think of an airplane cockpit, there won't be any physical check boxes and marks. The same is true with literally any physical tool or machine we interact with. On my Android phone at least, there are no checkmark style inputs in the OS, they are all toggle style. So I'm quite used to them being one and the same as check marks, which is probably why I don't notice one way or the other. But I do prefer checkboxes when they are unlabeled and in the far-most right column of a table, like a delete checkbox, because it uses a little less space, even if a toggle style checkbox might be easier to click/tap vs. an unlabeled checkbox.

@adrian No, it is not a matter of time before the old one is no longer supported. I've said this a few times already, but the Original theme is not leaving. It is "base" theme of ProcessWire, and the one which the new Default theme depends upon. If some new feature is added, it has to be accounted for in the Original theme before the new Default one. If these themes were like PHP classes, then the Original would be like WireArray, and the new Default would be like PageArray... one inherits from and depends on the other. The new Default theme is not a separate theme the way that AdminThemeReno was a separate theme. If the Original style suits your needs better, there is no reason to transition.

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 🙂

Sorry to keep going, but we desperately need more css vars. --blocks-background controls the color of so many things it makes it effectively useless. It impacts the top nav, the actual field blocks, the color of button text (what's with that?), the page list actions hover bar, and probably more. I love css vars (I never jumped on the less/sass bandwagon), but they only work if they are distinct enough to modify everything as needed because if we need to mix and match between css vars and class/id targeted overrides it becomes an awful mess very quickly and things will surely get broken with future PW changes. I really am trying to figure out a way I can turn on the new theme for users because I know that it's only a matter of time before the old one is no longer supported (that's not a slight, it's just reality when there is limited time and resources to maintain things). I really wanted the background of the main nav to be darker color with white text, so went with: :root { --main-background: #FFF; --text-color: light-dark(#444, #efefef); --muted-color: light-dark(#999, #efefef); --masthead-text-color: #FFF; } #pw-masthead { background-color: #c3d152; } but you end up with the placeholder for the search box white as well. I am sure I can override that as well but my point is that it gets messy fast without more specific vars to work with.

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.

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 🏆

So, today I learned that you can use a config-dev.php file which takes precedence over the normal config.php file if it's present. ... unfortunately I discovered this by accidentally uploading a config-dev file to a live site. I'd got two config files for live and staging in my project folder and just renamed them when I wanted to update a setting - I'd coincidently named the file for the staging details as config-dev.php and accidently uploaded it to production. Luckily this just meant that the content from the staging site got displayed which wasn't too out of date so hopefully no one noticed.... Now I look into it, I can see that's it been around for ever and there's been lots of chat about it, but hey, I didn't know about it, so thought I'd stick it in this thread just in case anyone else was a daft as me.

Is this custom login page for front-end users or for users who need to access the PW back-end? If it's for front-end users then I think you don't want them knowing about the core login page at all. You get a bit of extra security if you use a login page name that is not easily guessable (e.g. not "admin" or "processwire") and do not provide links to the core login page from the front-end. Then you only reveal the core login page to users who need to access the back-end. If the login page is for back-end users then I'm not sure why you would not want to use the admin-styled form given that the user is about to be working in the rest of the admin, but you could redirect away from it to your custom login page with a hook in /site/ready.php $wire->addHookBefore('ProcessLogin::execute', function(HookEvent $event) { $this->session->redirect('/your-login-page/'); });