[wp-trac] [WordPress Trac] #36687: Feature to override WP_Query to provide results from other source

WordPress Trac noreply at wordpress.org
Sat May 14 14:08:28 UTC 2016

#36687: Feature to override WP_Query to provide results from other source
 Reporter:  jpdavoutian            |       Owner:
     Type:  feature request        |      Status:  new
 Priority:  normal                 |   Milestone:  4.6
Component:  Query                  |     Version:
 Severity:  normal                 |  Resolution:
 Keywords:  has-patch 2nd-opinion  |     Focuses:
Changes (by boonebgorges):

 * milestone:  Future Release => 4.6


 > The only thing that would make this more useful is not requiring
 WP_Query to return WP_Posts. Right now all objects returned from
 posts_pre_query are wrapped in WP_Post.

 This isn't quite right. The way [attachment:36687.diff] is written, the
 `fields` parameter is still respected, and your `posts_pre_query` callback
 should be cognizant of `fields`. In other words, if `fields=ids`, your
 `posts_pre_query` callback can return an array of IDs, and it'll work as
 you'd expect; if you want it to return full post objects, you can either
 build pseudo-post objects in your callback, or return IDs and let WP fetch
 the full posts from the database (`array_map( 'get_post', $this->posts

 > As for the query parameter. It is not about disabling WP_Query's
 database query but to avoid making the external call. For example when
 indexing posts for the solr server we need to explicitly use the database.
 Otherwise we cannot read the posts. That's why I think that we should have
 the option there. The default should be that we want make the external
 call since the cases that we require explicit database use are less.

 When I said that it's about "disabling the database query", I don't mean
 disabling the database altogether. Obviously, your external appliance has
 to get the data from somewhere. I just mean that what the flag really does
 is prevents this specific instance of `WP_Query` from connecting to the
 database to get post IDs. I'm still not convinced that an option will add
 anything of value - even if there is something like an `external` or
 `dont_query_database` flag, you'll still have to provide the `posts` data
 somehow; and since that "somehow" will likely be with a filter callback,
 it makes sense to use *only* a filter callback instead of having a two-
 part solution.

 > Besides from settings the $query->found_posts I cannot figure out any
 other way.

 It'd be possible to add either a `query_var` that lets you set an explicit
 `found_posts` value,
 or a specific filter that bypasses the `found_posts` query (much like
 `posts_pre_query` - `posts_pre_set_found_posts` or something like that).
 But they would fundamentally do the same thing as [attachment:36687.diff],
 so all things being equal, I'd go with the more minimal solution.

Ticket URL: <https://core.trac.wordpress.org/ticket/36687#comment:11>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

More information about the wp-trac mailing list