artfulrobot

I know a reasonable amount about the output formatting basics. But I keep finding it behaving unreliably so I'm looking to enhance my understanding, or find fixes. Example: A template ('basic page') contains a Page Table Next (ptn) field. One of the templates in use in the ptn field has a repeater field. I'm rendering with Latte and I wish vars holding Page[Array] objects exposed to my templates to have of(TRUE) Let's say $thePage holds the basic page in question. There's 2 overarching contexts, front and back end. On admin screens pages default to of(FALSE) on front end, of(TRUE) This is already a bit of a problem that need workaround, since Page Table Next renders the front end output in the back end. But the question is, after $thePage->of($bool) what is the output formatting state of: $thePage->ptn->first ? $thePage->ptn->first->repeaterField->... ? It's not reliably $bool. I've sometimes tried to bolster the reliability by also calling $wire->pages->of($bool). But I still find it's not always as expected. In the case of linked pages, as above, how does an instantiated page object know whether its output formatting should be on or off? Where is it inherited from? None of the following appear reliably correct (I could be wrong, there's a lot of combos) It could be from $thePage Page object. It could be from $pages. It could be from the back/front end context. (worst case, since then you have to explicitly call of() on every page you reference which makes a real mess of templating, requiring a temporary variable to store the page so you can make the call before using a property) It could be to do with one of the first two options at the time the referenced page is loaded, which would account for the unreliability in the case that rendering involves a process where of() is called in turn with FALSE and TRUE... Can anyone help? I guess ideally what I'm after is $thePage->setOutputFormattingOnSelfAndAllReferencedPages($bool). (Aside: yes, I'm aware of using $thePage->getFormatted() and getUnformatted() but if you have to rely on these you can't use more convenient formats like ->each() or ->get() etc.)

Cross linking And also, this v useful module: https://github.com/BitPoet/SaveUserUnpublished

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

Thanks for taking the time to write this up and share, interesting read! I've been using some htmx on a processwire site recently, too, but you've gone much deeper into HTML integration than I did. To be honest I'm still not won over by htmx's "pretty much everything requires a server request" norm as it seems like excessive load and traffic in many use cases. And I did struggle a bit with multi-stage forms where pages may be used in different orders (I basically implemented a state machine flow). I'd be interested to see more of your implementation for interest/learning 🙂 as I'm into the idea of minimal no-build-step JS libs these days. It's also nice to revisit the idea that a site works without javascript, though I can't say I'm achieving this yet. So if you do have public access to view your code, please do drop a link here.

@BitPoet Wow thank you, that worked! I note that: you used ready not init. This makes sense; ready fires after all the installed modules have initialised, and we need ProcessWire to know that the InputfieldSelector module exists before adding a hook, presumably. (Note that your code worked for me using init() instead which I tested to see. I guess this is at risk of a race condition though; if my module loaded before InputfieldSelector did, it might not work). You hooked InputfieldSelector not the parent Inputfield yours worked, mine didn't, so I guess we're not allowed to hook on parent classes? This is a great example of how flexible ProcessWire is. And how much I've yet to learn! Very grateful for your time responding to this and sorry I didn't see it sooner (note to self: check my notification settings!).

I have a selector field and I need it to be able to select User templates, but User is hidden because it's a system template. I thought I could make this change with a hook, but I have not been successful. To try, I made a new module (single, auto load) and in its init() method I added code like this: class MyCustomModule extends Process implements Module { ... public function init() { $this->wire->addHookBefore('Inputfield::getConfigInputfields', function (HookEvent $event) { $this->wire->log('getConfigInputfields Fired', ['name' => 'testHooks']); }); $this->wire->addHookBefore('InputfieldSelector::init', function (HookEvent $event) { $this->wire->log('InputfieldSelector::init', ['name' => 'testHooks']); }); } ... } I thought that if I hooked into when an InputfieldSelector got instantiated, I could check whether it was the field I wanted to target and if so, make the setting change. But none of these hooks fired when I edited the page. Currently, I have achieved this through changing InputfieldSelector.module's __construct() method, but I wanted to do it with a hook so it has more of a chance of not getting removed on upgrade! Any help appreciated ?

Nb. the same works for Roles. e.g. I added a text field to the Role template, called it "purpose" and then added that to the Roles admin list so it's clearer what role does what. Thanks for the tips.

One question I have is: is output formatting on or off in this situation? $pwUser = $this->wire->pages->newPage([ 'template' => 'someTemplate', 'name' => 'someName', 'someField' => 'someValue', ]); A reflection about setting a value when output formatting is ON: The blog says that when it's ON, the formatters will run to check it can be formatted and it will set it to status:corrupted if they can't run. This sounds like good validation to me, which makes me think it might be better advice to do $page->of(true) before setting values, unless you're in a situation where you can really trust your raw data to be valid. Caveat: I note that the example edits are self referential ($page->someField = $page->someField + 'altered') in which case it's clear that output formatting ON is going to cause problems.

The problem goes deeper. As well as the hooks above (published/unpublished) i needed to add one on Pages::saved(1:published) because my paths are based on the published date. I believe there's a bug in core that prevents us being able to implement path() in a page class successfully: https://github.com/processwire/processwire-issues/issues/1906

I started with those, but they're not always the right way. There's also url segments and path() method overrides. The challenge is: 1. you want pages to be served at your desired url. 2. You want the admin ui to show correct URLs. 3. You want the link adding UI to find the correct URL. 4. You want $pages->get(url) to work. 5. You want the qa checker to work. 6. You want PagePath module to keep up with changes. If interested, here's a rambling post of my journey, I got there in end (except 2, but, meh!).