Allow modification of query clauses in get_posts; search multiple kewords; adjust query filter clauses

[aryanduntley]

For more advanced querying, modification of the $post_query object should be allowed in get_posts on after line 165. Currently, I have to

function wpr_defWhere($ret){
  add_filter('posts_where', 'wpr_search_keyword_multiple' );
  return $ret;
}
add_filter('json_query_vars', 'wpr_defWhere');

function wpr_search_keyword_multiple($where){
  if(!isset($_GET["filter"]["s"])){return $where;}
   ...
}

If this is not going to be changed, at least those that might search for this in the future will know at least one way of getting around the issue without extending the class.

[danielbachhuber]

Can you share more detail on what you're trying to do?

[aryanduntley]

For now, just trying to get multiple search terms. I can filter just fine the way I explained, to adjust and modify the query where parameters. However it becomes more complicated than if there were filters before and after the query in order to allow adjustment of the query. Also, there are no hooks to allow modification of the results in get_posts. This becomes problematic when trying to paginate. Because I cannot supply an amount of result or max num pages, pagination is a guess on the caller's part. Consider a mobile app attempting to request search parameters or finely tuned filters and not knowing how many pages to allow. They would paginate up until they get an empty result set, sure, but that allows only for a next and last page in the UI instead of actual pagination (to end, to beginning, page numbers). Modification of the query and the results should always be available for extendability. It makes less work on the developer's part because they can hook where needed and they do not have to do round-about hooks checking for GET params and POST params, and it help prevent the need for completely extending the class (which would be mostly a copy paste, and a slight modification/addition to what is already there, it's always a bummer when everything is perfect except for one little thing). Providing hooks there will prevent all the round-about action.

[aryanduntley]

access should be allowed the the $query variable before it is queried.
access should be allowed to the $post_query object after it has queried and populated with the result set.
In so doing, you allow query filters to also be placed before and after the query (add and remove where clauses, etc...) as well as direct access to the $query params (there is the individual $query param hook in the loop, but it requires a lot of manipulation for more detailed needs) .

The hook providing access to the $post_query object should be placed before the response is sent out so that things like pagination parameters (total num posts, max pages) can be added to the result set.

There is the prepare_post hook that allows modification of the output of each individual post, but that does not have the $post_query object data and is of little use in the regards of which I'm speaking.

[danielbachhuber]

We'll handle this in #924 and #1167