WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 6 years ago

#21623 closed enhancement (fixed)

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

Reported by: markoheijnen Owned by: westi
Milestone: 3.5 Priority: normal
Severity: normal Version: 3.4
Component: XML-RPC Keywords: mobile has-patch
Focuses: Cc:

Description

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.

Attachments (2)

21623.diff (465 bytes) - added by ericmann 6 years ago.
Basic addition to include a "search" filter for wp.getPosts
21623-2.diff (470 bytes) - added by ericmann 6 years ago.
Refresh patch to use s parameter for search.

Download all attachments as: .zip

Change History (15)

#1 @koke
6 years ago

  • Cc jbernal@… added
  • Keywords mobile added

#2 @maxcutler
6 years ago

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.

#3 @maxcutler
6 years ago

  • Cc maxcutler added

@ericmann
6 years ago

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

#4 @ericmann
6 years ago

  • Keywords has-patch added; needs-patch removed

@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.

#5 follow-up: @markoheijnen
6 years ago

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.

#6 in reply to: ↑ 5 @ericmann
6 years ago

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.

#7 follow-up: @markoheijnen
6 years ago

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.

#8 in reply to: ↑ 7 @ericmann
6 years ago

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.

#9 follow-up: @nacin
6 years ago

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.

#10 in reply to: ↑ 9 @ericmann
6 years ago

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
6 years ago

Refresh patch to use s parameter for search.

#11 @westi
6 years ago

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

Added some simple tests in [UT1033]

#12 @westi
6 years ago

  • Milestone changed from Awaiting Review to 3.5

#13 @westi
6 years ago

  • Owner set to westi
  • Resolution set to fixed
  • Status changed from new to closed

In [21936]:

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

Note: See TracTickets for help on using tickets.