Feature parity for the use of selectors in WireArray vs PageFinder

[Toutouwai]

It would be nice if selectors worked the same across both WireArray/PageArray and PageFinder.

For a $pages->find() selector we can use relative time strings and friendly names for page statuses (locked, hidden, etc) but not for a PageArray selector. It would be great not to have to keep these differences in mind and just use selectors consistently across the whole API wherever possible.

[ryancramerdesign]

WireArray is applicable to all object types in ProcessWire, whereas PageFinder is exclusive to finding pages from a database. While they might seem similar in usage on the surface, they are fundamentally different. For instance, PageFinder has access to all pages in the site, whereas a WireArray (or PageArray) has only access to a limited set present in the object. PageFinder can make use of joins and various other database features, whereas a WireArray just has a flat group of items. So it won't ever be possible to say that selector usage can be identical between PageFinder and a WireArray because the context is so different. However, it may be feasible to support the two specific examples you mentioned in PageArray (time strings and page status names). Though as a matter of efficiency, this kind of filtering should really be done at at the PageFinder (database) level. When it comes to PageArray objects, having to use in-memory find/filter is often a sign that something was loaded that didn't need to be, and a place where the find should probably be modified to use PageFinder.

[LostKobrakai]

When it comes to PageArray objects, having to use in-memory find/filter is often a sign that something was loaded that didn't need to be, and a place where the find should probably be modified to use PageFinder.

That's basically every page field until the fieldtype does support pagination. These simply come preloaded without a chance to optimize the resultset beforehand.

[Toutouwai]

Yes, it's Page fields I'm thinking of mostly.

There was an topic in the forum recently where someone was using a Page field to store items for a navigation menu, but didn't want pages with 'hidden' status to appear. Not being able to use "status!=hidden" in a selector and having to deal with bitwise values to filter the Page field is not so user-friendly.

[ivangretsky]

Robin's post opened my eyes after a few hours of not understanding, why today is not a thing in filter(). Implementing this for consistency would be pretty good. But at least some more clear docs could help.

[teppokoivula]

why today is not a thing in filter()

Stumbled into this one just yesterday, and it actually took a while to see why my query wasn't working. Even though I should be quite aware of these differences by now, it just doesn't feel intuitive, and I keep making the same mistake.

Still not a major issue as long as you're aware of it, but it's not exactly great either that one has to know/remember such quirks. +1 for implementing support for keywords such as "today" and the status names for both database and in-memory selectors :)

[Notanotherdotcom]

+1 for "today" - ran into this myself last night for the first time