XML-RPC method wp.getPosts should be able to search

[markoheijnen]

At this moment you can't search for posts. It would be a nice addition to the existing code if there would be a possibility to do a search.

[maxcutler]

wp.getPosts should be refactored to use WP_Query instead of wp_get_recent_posts, and at the same time it can be expanded to support the (undocumented?) s query arg for searching.

Beyond generic text search, wp.getPosts should really support other types of "searching" like by-category/tag/term, by-custom-field, etc.

[ericmann]

Basic addition to include a "search" filter for wp.getPosts

[ericmann]

@maxcutler I agree that we should look into a more significant rewrite, but at a very minimum the attached patch does extend a search parameter to the filter collection.

It's low-hanging fruit and, if we can't get a full rewrite of wp.getPosts done for 3.5, it will still enable rudimentary searching for now. It also establishes the search parameter for the time being, and we can retain backwards-compat in the future.

[markoheijnen]

I don't agree that this is a low-hanging fruit. I think it is a feature that people aspect.
I also disagree for using WP_Query since wp_get_recent_posts also use get_posts but with another default set of arguments. So it isn't something we need to implement to gain more functionality.

I think we can simplify the checking and use $filter as our default $query and transform number to numberposts if numberposts isn't set.

[ericmann]

Replying to markoheijnen:

I don't agree that this is a low-hanging fruit. I think it is a feature that people expect.

I agree this is a feature people expect. I referred to it as "low-hanging fruit" in comparison with a complete refactoring of the method to use WP_Query. Merely adding the search functionality, as evidenced by a very simple patch, is very straight-forward and doesn't require much overhead at all.

It merely maps the search element of the $filter array to the s element of the $query array. I expanded "s" to "search" to make the method a bit more self-documenting.

I also disagree for using WP_Query since wp_get_recent_posts also use get_posts but with another default set of arguments. So it isn't something we need to implement to gain more functionality.

Again, I agree. But since this isn't yet a "blessed task," I leave that open to discussion among the rest of the core team. If we want to refactor, I'm not above doing that. But what do we gain?

I think we can simplify the checking and use $filter as our default $query and transform number to numberposts if numberposts isn't set.

Without the search functionality, I would agree. But "s" is a very ambiguous parameter, particularly for 3-rd party client developers. Being able to use different, more explanatory parameter names for xmlrpc parameters makes the API easier to program against. Mapping those parameters to what $query expects isn't too big of a task.

[markoheijnen]

Yes, I can understand why you want "search" instead of "s". Can't we just map "search" to "s" then? and only do that when "s" isn't set.

[ericmann]

Replying to markoheijnen:

Yes, I can understand why you want "search" instead of "s". Can't we just map "search" to "s" then? and only do that when "s" isn't set.

We could ... but I strongly believe in "decisions, not options" so what's the value in supporting both "search" and "s"? What happens if both are set by the client? Personally, I think using both of them would just create confusion.

[nacin]

I'm not sure how complicated a move from wp_get_recent_posts() to WP_Query would be, but I think it would be great if we could make the switch. We should make sure we have unit tests for all parameters that wp.getPosts accepts.

I think I would rather we introduce just 's' rather than 'search'. The single 's' is universal in WordPress, and with proper documentation (which we have in the Codex), an app developer will know exactly what to use.

Aside from that, I also think that moving to WP_Query is a bit too low-level. We'll need to use wp() so only public query variables are exposed.

[ericmann]

Replying to nacin:

Works for me, and definitely something I can take care of. What are the chances this can be in 3.5 if a patch is ready this week? (Trying to prioritize ... and this is still Awaiting Review.)

[ericmann]

Refresh patch to use s parameter for search.

[westi]

The simple patch to just introduce 's' for now seems fine to me.

Added some simple tests in ​[UT1033]

[westi]

In [21936]:

XMLRPC: Support searching via wp.getPosts() fixes #21623 props ericmann.