Description
Several branches of build_meta_query_where() (src/Pods/Theme/WP_Query_Integration.php) bail by returning an empty string:
case 'BETWEEN':
case 'NOT BETWEEN':
if ( ! is_array( $prepared ) || count( $prepared ) < 2 ) {
return '';
}...and the switch itself ends with a bare return ''; for any compare it does not handle.
Impact
By the time this runs, the clause has already been removed from the meta_query that WP_Meta_Query would have processed. So returning '' does not mean "fall back to core" — it means the condition is applied nowhere, and the query returns more rows than requested.
The failure is silent: no notice, no error, and the query still succeeds. A listing that relies on the filter to restrict visible items will quietly show items it should not.
BETWEEN with fewer than two values (#7609 covers the IN variant) is the concrete case, but the bare return ''; at the end of the switch means any future compare that reaches this code inherits the same behaviour.
Suggested fix
Make the integration fail closed rather than open. Where a clause cannot be faithfully translated, leave it on postmeta so WP_Meta_Query handles it, instead of stripping it and emitting nothing. That turns every one of these cases into "slower but correct".
A useful invariant: the integration should only remove a clause from the meta_query once it has committed to producing SQL for it.
Related
Disclosure: this issue was researched and drafted with AI assistance and reviewed by me before filing.
Description
Several branches of
build_meta_query_where()(src/Pods/Theme/WP_Query_Integration.php) bail by returning an empty string:...and the
switchitself ends with a barereturn '';for any compare it does not handle.Impact
By the time this runs, the clause has already been removed from the
meta_querythatWP_Meta_Querywould have processed. So returning''does not mean "fall back to core" — it means the condition is applied nowhere, and the query returns more rows than requested.The failure is silent: no notice, no error, and the query still succeeds. A listing that relies on the filter to restrict visible items will quietly show items it should not.
BETWEENwith fewer than two values (#7609 covers theINvariant) is the concrete case, but the barereturn '';at the end of the switch means any future compare that reaches this code inherits the same behaviour.Suggested fix
Make the integration fail closed rather than open. Where a clause cannot be faithfully translated, leave it on postmeta so
WP_Meta_Queryhandles it, instead of stripping it and emitting nothing. That turns every one of these cases into "slower but correct".A useful invariant: the integration should only remove a clause from the
meta_queryonce it has committed to producing SQL for it.Related
INwith a scalar value drops the filter and returns MORE rows #7609 —INwith a scalar, same root cause.Disclosure: this issue was researched and drafted with AI assistance and reviewed by me before filing.