[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
Comment:
> 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