Hi @benjamin - I wanted to elaborate on the above post, because there are some topics I’ve had difficulty explaining. Maybe they deserve a separate documentation page, blog post, tutorial (?), with examples demonstrating how they work.
One topic is about the difference between:
- Using loop query to get matching posts
- Filtering posts with
Loop query is performed by the database engine (MySQL/MariaDB), and It’s much more efficient/faster to get posts that match a set of query parameters - compared to getting a larger number of posts (all posts, or all posts in a category, etc.), then to loop each item and filter them using
And, as this current issue shows, filtering with
If does not work with pagination, because the items are already paginated before they get filtered out by the
Another topic is about the difference between:
The Post loop type’s query parameter
custom_field is for querying raw field values. Here, “raw” means the field values as they are stored in the database, before they get processed by WordPress core or plugins. This distinction means such queries are limited to simple value types like text, number, and dates (if they’re in the right format).
In contrast, the
field attribute of the
Loop tag is not a query parameter.
It’s currently documented in the page Loop query - but actually, that page should be titled, Loop filters. These features are supported by all loop types, because it’s implemented in the “base loop class” that serves as a common base.
Loop filters are less efficient than queries because they happen after the query is made, same as filtering with
If tag. (Notably,
sort_field is a loop filter, in contrast to
orderby which is a query parameter of the loop types Post, Taxonomy, User, and maybe others.)
In general, it’s always better to use custom field query where possible.
The reason why loop filters exist is for extensibility beyond querying raw field values. For example, some custom fields are not stored as simple text or number values, and need to be processed by a plugin (such ACF, Pods, WooCommerce, LearnDash) before they can be “queried”, or rather, filtered. Loop filters could be useful in such cases.
In hindsight, I probably should have named the attribute
filter_field to clarify its behavior as a filter and not a query parameter. Then I could have renamed
field, so that the better, more efficient solution is easier to express.
That’s why the date field query is done using
custom_date_field, instead of just
date_field. The latter I suppose could be a filter that supports a wider range of date formats and more complex conditions.
It’s not simple to use, requiring two or more long parameters to express. I think it needs its own documentation page with common usage examples. Same with taxonomy term query, especially involving multiple terms.
Anyway, just for your information, in case you encounter these topics/questions in the future.