artfulrobot

@Jan Romero wow thanks for your work and for sharing it! Interesting to see what is needed to accommodate something like this. Re yet more on the selector DSL- yes. It fascinates me that it's possible to do so much with simple text strings and not trip up. I would love to see unit tests in PW covering these cases - this would mean the format could be developed with more confidence that the new work hadn't broken the existing logic.

Ah, thank you, but I cannot load all the pages into memory - there's thousands, so this would be inefficient in this instance.

@bernhard many thanks, really appreciated. I'll have a play!

I have a template which has a when timestamp field that is optional. I'd like to fetch pages sorted with ORDER BY COALESCE(when, published) DESC meaning that if there's a value for when then use that, otherwise use published Is this possible with a selector? At first I thought it might be something like sort=-(when|published) but that doesn't work. It doesn't error, but it doesn't return the correct results. Neither does sort=-when|-published (i tried quite a few other combinations too).

Or do it in a standards-compiant way? https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/accesskey

Laws and business cases aside, my points were more along the lines of: hey, with a smidgen of awareness we can make nice things that more people can enjoy using. Sure, at the extreme end it can be an enormous task that requires awareness, commitment, funding, expertise, focus groups etc. etc., but let's not make perfection the enemy of progress. On colour contrasts, I have good eyes (fading as I'm middle-aged, but 20:20 vision with glasses) and am not colourblind. I'm part of the 80% majority in the UK who does not have a long term disability. I can afford and have chosen to spend cash on high quality screens. I love photography and art and attention to subtleties in colour. I still struggle with small, low contrast texts but at a squint I can read them, it's just not pleasant. I make websites for a living, so sometimes I just hit F12 and change the CSS, and for some sites I use a browser plugin to always add my own CSS. So even with all my privilege, this isn't a great experience. Many people don't have great eyes or expensive monitors or tech skills to edit CSS and will literally not be able to read such texts and there's just no need for this. The WCAG standards provide guidance on colour contrasts and this is a big easy win. Meeting the AA standard on colour is such a low level requirement that most browsers have dev tool support for this built in and have had for years. Screenshot of Firefox's dev tools showing a node from this site; I've clicked on the CSS "color" rule and it shows a colour picker that includes a contrast ratio calculation: 4.02 with a red exclamation mark and a tooltip reading: "Does not meet WCAG standards for accessible text." Chromium-based browser screenshot of devtools: again, the CSS panel is shown and I clicked a colour and the colour picker has the contrast ratio calculated, 4.01, and text: AA: 4.5 with a red symbol meaning No-pass (this is telling you that 4.01 < 4.5), and AAA: 7.0, not passing. Lines on the chart show the colours that would be accessible against the two standards. Re: keyboard accessibility: For a while I developed RSI which meant I could not use a mouse without significant pain. This was obviously very frightening for me given how I make my living. At this time I really learnt the value of keyboard accessible interfaces - they literally made it much less painful for me to operate a site (admin or front end). And disability aside, being a [neo]Vim user too means I know that it's often just a lot more efficient to use the keyboard instead of having to reach for a mouse, so these are my reasons for suggesting this. Thanks for being open and interested in these accessibility suggestions @ryan I think upping contrast to 4.5 (AA) would be a great first step to making ProcessWire something a lot more people could enjoy using and as others have pointed out, making an admin system that also supports 3rd party modules to make it more accessible, e.g. through use of CSS variables, also makes ProcessWire a good framework for people wanting or needing[1] to make sites more widely accessible. [1]: 86% of people implementing accessibility standards do it because they feel it's the right thing to do. 8% do it for compliance reasons, 4.5% do it for business advantage, 1.1% do it for legal reasons: https://webaim.org/projects/practitionersurvey3/

💯 this For me there's three things that come to mind immediately here: All text should pass at least WCAG-AA standard, and ideally should pass AAA. e.g. .description uses #8d939e which only has a contrast ratio of 3.09 making it inaccessible for a lot of users. It would only take darkening it to #717680 for AA standard or #525968 for AAA standard. Keyboard navigation: e.g. Escape key should cancel a modal - e.g. add a field or such. Javascript should not break forms' keyboard nav: e.g. hitting Enter after typing filter text on the Pages list should submit the form but instead it reloads the page without your filter text(!) But I'm looking forward to seeing the new theme, perhaps some of these have already been considered if so 🥳

I have a selector like this: "template=job, job_id!=1|2|3|..." The purpose is to find all job pages except for those given in the OR list. I'd expect SQL like this: SELECT pages.id,pages.templates_id FROM `pages` LEFT JOIN field_job_id ON pages_id=pages.id WHERE (pages.templates_id=123) AND field_job_id NOT IN (1,2,3,4,...); However the PW query builder seems to generate something far more complex, including adding a JOIN for every id!=1|2|3|... value - this tips over Mysql's joins limit (61 in MariaDB at least) and causes a crash. I've had to work around this by instead of using selectors, loop every job page in PHP and test it's job_id field against the set I want to exclude, which is really inefficient. Is there a way to make the selector → SQL more efficient/not crashy?

@ryan I don't think it breaks the ability to type, it's just you'd have to type the emoji/unicode character, then a space, then what you're searching for - which is something that very few people would be able to do. Thanks for taking on board the optgroups ... option! Interesting re iOS/Safari not noticing DOM changes in <select> elements! Happy 2025 🙂

@benbyfAppreciate this, thank you! When I have to look at the logs page, my brain is usually in a panic, so this helps surface the thing I want without further thinking about "and now click to sort", or worse, trying to mentally scan and parse the textual description column like x hours/minutes ago!

Wow, well that's a Christmas present! So glad this is coming (slowly), Thanks forfor sharing it!

This looks really useful, by the way! Accessibility: I was going to submit this as an issue but perhaps you'd prefer discussion here as a precursor? Browser-native selects have a cool feature: you can type the label to find an item. If you're able to use a mouse like I am then this is just an efficiency, but if you can only use keyboard navigation then this is really very valuable to usability (on a long list) and to efficiency (on a short list). e.g. consider a list of countries. ("Where have you been on holiday?"). having to scroll and click is going to be awkward and slow; being able to type Uni and jump to United Arab Emirates (and below it United Kingdom) makes it a breeze. This important accessibility function gets broken by the way the icons representing selected/not are inserted as text before the labels. Sadly, CSS cannot rescue this - if CSS were supported better for <selects> then we could do various things to improve UX for visual users without it being at the expense of less able users. What about instead of using visual characters for selected/not, using <optgroup label="Selected"> and <optgroup label="Unselected"> and grouping the selected items first?

@zoeck Being physically able to do something is not the same as legally/ethically being able to do something. I haven't found the license that pro modules are provided under, but Ryan makes it clear they are not open source, so your rights are unknown. Common sense says that I'm quite sure he doesn't mind anyone making changes to their local copy but that I'm quite sure he would mind if someone started sharing the code/modified versions of it, or even selling it! My interest in open source code is primarily sustainability - code that is openly shared/forked, has good leadership as part of an active team of developers, welcomes contributions. A closed product only exists as long as it is in the interests of its owner. If Ryan, God forbid, were to have a change of fortunes/interests, and shut shop, the open source code could be picked up by an interested community of developers and all our websites and services based on PW stand a chance of a future. The closed source products could not - legally - be continued. My biggest reservation in using ProcessWire is the business risks posed by its BDFL model / single point of failure in general and moreso with the pro modules. My interest in this forum post, however, was just how to give Ryan a modest donation to help fund his excellent continued work! I'll try reaching out directly/via contact-form on website as @Krlos suggested.

I really appreciate ProcessWire as an open source CMF/CMS. I have used it for 3 websites now. I understand that the Pro modules are a way to support the project, however I do not want to use any proprietary code because it feels like a backwards step; I like being able to use, bend, fix, study, share the software I use, and I actively contribute to dozens of such projects. Is there a way I can make a donation to the work of the project without buying a Pro module?