Skip to content

fix: order posts by their modification columns - #404

Merged
chubes4 merged 1 commit into
mainfrom
fix/posts-order-by-post-modified
Sep 11, 2026
Merged

chubes4 merged 1 commit into
mainfrom
fix/posts-order-by-post-modified

Conversation

@chubes4

@chubes4 chubes4 commented Sep 11, 2026

Copy link
Copy Markdown
Collaborator

What

post_modified and post_modified_gmt are missing from the posts order allowlist, so any query ordered by them fails closed in the native executor with unsupported_order.

WP_Query emits ORDER BY wp_posts.post_modified for orderby=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 list reported No wiki articles. The rows were present the whole time, and the same query ordered by post_date returned them immediately:

post_date        -> 3 posts
post_modified    -> 0 posts  ERR: mdi-native cannot apply the requested ordering collation.
post_title       -> 3 posts
menu_order       -> 3 posts

Change

Add post_modified and post_modified_gmt to order_columns in the posts schema. Both are datetimes in the generated core catalog and sort through the same comparator already used for post_date and post_date_gmt, so this widens the allowlist without introducing a new ordering path.

Tests

Extends tests/smoke-native-core-schema-catalog.php to pin every core datetime column WP_Query orders by. Verified it discriminates:

  • With the source change reverted and the test kept: FAIL: posts order by every core datetime column WP_Query emits
  • With the fix: PASS, 9/9 checks in that file

Known gap, not addressed here

post_name is also absent from the allowlist, so orderby=name has 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 exiting 0, so homeboy.json's php "$test_file" || exit 1 runner reports green on a failing test. 17 files currently fail this way on main. 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.

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant