fix: order posts by their modification columns - #404
Merged
Merged
Conversation
WP_Query emits ORDER BY wp_posts.post_modified for orderby=modified, which is what every recently-updated listing asks for, including the admin post list and the Intelligence wiki list command. post_modified and post_modified_gmt were missing from the posts order allowlist, so the native executor failed those queries with unsupported_order. get_posts() turns that failure into an empty array, so the caller sees no posts rather than an error. On a site with 663 wiki articles, wiki list reported none. The rows were present the whole time and a query ordered by post_date returned them. Both columns are datetimes in the generated core catalog, ordered by the same comparator already used for post_date and post_date_gmt. The regression pins every core datetime column WP_Query orders by, and fails on the prior allowlist.
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.
What
post_modifiedandpost_modified_gmtare missing from the posts order allowlist, so any query ordered by them fails closed in the native executor withunsupported_order.WP_QueryemitsORDER BY wp_posts.post_modifiedfororderby=modified— the default for recently-updated listings, including the WordPress admin post list.Why it is worth a fix rather than a workaround
get_posts()turns a backend query failure into an empty array. The caller cannot tell "no matching posts" from "this backend refused the query."Found on a site with 663 wiki articles where
wp intelligence wiki listreportedNo wiki articles.The rows were present the whole time, and the same query ordered bypost_datereturned them immediately:Change
Add
post_modifiedandpost_modified_gmttoorder_columnsin the posts schema. Both are datetimes in the generated core catalog and sort through the same comparator already used forpost_dateandpost_date_gmt, so this widens the allowlist without introducing a new ordering path.Tests
Extends
tests/smoke-native-core-schema-catalog.phpto pin every core datetime columnWP_Queryorders by. Verified it discriminates:FAIL: posts order by every core datetime column WP_Query emitsPASS, 9/9 checks in that fileKnown gap, not addressed here
post_nameis also absent from the allowlist, soorderby=namehas the same silent-empty behavior. Left out of this PR because slug ordering has an ASCII-collation question the datetime columns do not.Separately: the smoke suite prints
FAIL:lines while exiting0, sohomeboy.json'sphp "$test_file" || exit 1runner reports green on a failing test. 17 files currently fail this way onmain. Worth its own issue.AI assistance: GPT-6 Astra via OpenCode, under Chris Huber direction, traced the empty wiki listing to the order allowlist, made the change, and wrote the regression. Chris Huber remains responsible for review.