Repository navigation
Conversation
… and network query facades
…for a minor release
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Lets the framework run with
pollora/query2.0 (released today), which covers every WordPress query class, while still accepting 1.x.composer.json:pollora/query^1.0 || ^2.0, up from^1.0, the wayattributes,discovery,wp-cliandwp-restare required.tests/Unit/Support/QueryFacadesTest.php: the four query bindings ofQueryServiceProviderand thePostQuery,TaxQueryandMetaQueryfacades. They hold with both versions; nothing tested the provider before.CHANGELOG.md: a Changed entry.The five query facades for the new classes (terms, users, comments, sites, networks) are not part of this PR any more: they need 2.0, so they are better in a minor release that requires it. The commit that had them is still in the history of this branch, with their tests.
What the constraint does, and does not do
^1.0 || ^2.0makes both versions installable and tested. It does not keep a project on 1.x:composer updatetakes the highest version, 2.0.0, as it does for the packages above. A project that wants 1.x requirespollora/query^1.0itself. If a patch release must not move anyone to a major version, the way to do it is to leave^1.0as it is and require 2.0 in the next minor, together with the facades.What 2.0 changes for an application that updates
A few fixes change the result of a query that used to run:
where()thenorWhere()groups the earlier clauses ((a AND b) OR c),DateQuery::inclusive()now takes effect, dates use a 24-hour clock, and an invalidfields(),userPermission()ororderBy()direction throws aQueryException. The publicinitQuery(),query()andgenericQuery()methods are gone. The upgrading guide lists everything. Nothing in the framework or in the sibling packages uses what was removed, and the framework only buildsPostQuery,TaxQuery,MetaQueryandDateQuerywith no argument, which works the same.Checked
pollora/query2.0.0 and with 1.0.3 forced.pcov,pdo_sqliteandpcntl, freshcomposer install): 1652 passed on PHP 8.3 and 8.4 with 2.0.0, against 1635 on the release without any change. The 1.0.3 side is the release as it is.Noticed, not changed
wp.query.post,wp.query.taxonomy,wp.query.metaandwp.query.dateare registered as singletons of mutable builders, so a call such asTaxQuery::where(...)through its facade accumulates across calls. It predates this PR. There is noDateQueryfacade although its binding exists.