passing an Args instance to WP_Query without toArray() silently yields subtle bugs

[montchr]

I spent the past few hours trying to figure out why two nearly-identical queries in my project yielded wildly different results. Both used the same tax_query->clauses, but only one of the resulting queries actually respected the clause. It turns out that I had forgotten to call toArray() on the instance of \Args\WP_Query prior to passing it to the \WP_Query constructor. I would have expected that to cause an obvious error.

The query with new WP_Query($args->toArray()) correctly filtered posts by tax_query, while the query with new WP_Query($args) did not respect tax_query but also did not fail entirely.

[johnbillion]

Thanks for the report.

WordPress core is very inconsistent with how it handles these array arguments. I had hoped that with args I could construct an object which could be passed directly to parameters in WordPress which expect an associative array, but this isn't possible because of guard conditions such as is_array() in some functions. The underlying issue is that the arguments must be an array, hence the toArray() method. An object that implements ArrayAccess isn't enough.

A while ago I was thinking about removing the array-like behaviour of the args classes. That should mean that in this situation you get an immediate fatal error rather than a mysterious bug. I'll look into it.

[johnbillion]

I think that was a roundabout way of saying that implementing ArrayAccess, Countable, and IteratorAggregate on the base args class was a mistake.

[montchr]

That makes perfect sense. Thank you!