You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Query Loop as it exists today has kind of been built as a block-based interpretation of WP_Query. While powerful, it has inevitably resulted in an overwhelming UX. For example the confusing and unpredictable "Inherit query from template" option exists because it's possible to place Query Loop in templates and posts. Not to mention that blocks like Query Pagination simply do not work in posts at all, with no explanation offered by the interface.
Before this gets too far out of hand, it might be good to explore contextually optimised implementations, based on the various jobs users employ Query blocks to perform.
By prohibiting the placement of the base Query block in Post Content it immediately becomes singular in purpose – display posts as defined by the template. Consequently it needn't entertain so many options and the overall experience can be streamlined.
Naturally we still need to provide ways to display post lists in pages and so on, but these use cases can be handled by simple variations of the base Query Loop as discussed in:
It goes without saying that we cannot implement this change until those variations exist. We'd also need to consider how to handle pre-existing Query Loops as well.
The text was updated successfully, but these errors were encountered:
Query Loop as it exists today has kind of been built as a block-based interpretation of
WP_Query
. While powerful, it has inevitably resulted in an overwhelming UX. For example the confusing and unpredictable "Inherit query from template" option exists because it's possible to place Query Loop in templates and posts. Not to mention that blocks like Query Pagination simply do not work in posts at all, with no explanation offered by the interface.Before this gets too far out of hand, it might be good to explore contextually optimised implementations, based on the various jobs users employ Query blocks to perform.
By prohibiting the placement of the base Query block in Post Content it immediately becomes singular in purpose – display posts as defined by the template. Consequently it needn't entertain so many options and the overall experience can be streamlined.
Naturally we still need to provide ways to display post lists in pages and so on, but these use cases can be handled by simple variations of the base Query Loop as discussed in:
It goes without saying that we cannot implement this change until those variations exist. We'd also need to consider how to handle pre-existing Query Loops as well.
The text was updated successfully, but these errors were encountered: