Make WordPress Core

Opened 4 years ago

Last modified 5 months ago

#34211 new enhancement

Ability to specify fields WP_Query can search

Reported by: paulwilde Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.4
Component: Query Keywords: needs-patch
Focuses: Cc:
PR Number:


Currently the s parameter in WP_Query is hardcoded to only search in the post_title and post_content fields. A decent enhancement would be if you could also specify which postmeta fields it can search into as well.

Also allowing more fine-grained control so that it can search only postmeta fields and ignore post_title and post_content as well.

Something along the lines of:

's'             => 'foo',
's_fields'      =>'title',
's_meta_fields' => array( 'custom_field_1', 'custom_field_2' ),

s_fields can a string/array of either post_title and/or post_content. Setting it to false would disable searching these fields and assume you have set custom meta fields to search for instead. By default it would be array( 'title', 'content' ).
s_meta_fields can accept a string/array of postmeta field names to search for. By default it would be false.

A decent use case would be the Search by SKU for Woocommerce plugin which resorts to writing a custom query.

I assume the only real concern would be performance.

Change History (6)

#1 @helen
4 years ago

We would indeed be making it easy to shoot yourself in the foot performance-wise, but we do run across needs like this from time to time, like with media: #22744.

#2 @akibjorklund
4 years ago

This is a common requirement for sites that are more complex than blogs. Typically this issue is solved with a plugin that creates their own database tables or by integrating WordPress with external search providers. I think the ability to search the content is a basic feature of a CMS. This is why I think it is something WordPress too should definitely be able to do somehow – in a way that would serve common use cases.

A simplest possible solution to the problem I can think of – that still could be scalable – is to add a parameter to WP_Query that would allow you do define a single meta key that would be included in the search. If one would want multiple meta values to be searched, one would have to programmatically concatenate all those values into a single meta value every time a post is saved. One can already do LIKE in meta_compare, but ordering is not affected and searching terms across columns will not work (searching foo bar whenfoo is in content and bar in meta field will not find anything).

The downside of this approach compared to the one proposed above would be to not be able to define fields to query dynamically per query. And also there would be migration issues, when the definition of included fields (or terms!) would change. Some kind of indexing precess should exist. That could be left to plugin authors I guess. With this approach one could still have multiple indexes with different set of fields though, which could be helpful.

I'm not sure though that this approach would fly, because it would feel unintuitive to developers to be limited to a single meta field. To make it not so unintuitive, a lot more code would have to be written to make the indexing of content automatic.

The API could look something like this: register_search_index( $name, $meta_fields, $taxonomies = array() );. Plus WP_Query would have a new field search_index.

I'm willing to write some code if this is a direction that more people feel worth exploring.

This ticket was mentioned in Slack in #core by boone. View the logs.

3 years ago

#4 @boonebgorges
3 years ago

  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to Future Release

Search in WordPress, especially when we start talking about postmeta, is always going to be limited by our underlying technologies. For this reason, it feels inappropriate to design a significant developer-facing API for this kind of search - if we design it, devs will use it, but they'll ultimately be unsatisfied with performance. If you need true faceted search, you should use a standalone search appliance.

Maybe we could approach the problem in a more modest way. There are places in core where we suffer from the limitations described here. Media is a good example - because certain aspects of uploads are stored in postmeta, Media search doesn't work properly. So we should address this internally, even if we don't build something that we actively encourage developers to use. Something closer to what @paulwilde originally suggested seems more appropriate to me, though the implementation is going to be tricky, especially with regard to orderby.

We'll need the sketch of a patch to move forward.

#5 @lukecavanagh
3 years ago

So a search meta API then that you can define a meta key or keys in WP_Query?

Search plugins that create an index on the site DB, get around those limits by including the postmeta needed in the index.

For example _SKU custom field in WooCommerce.

Last edited 3 years ago by lukecavanagh (previous) (diff)

#6 @lukecavanagh
3 years ago

The issue on default WP search is when you are dealing with a lot of posts on a site.

Note: See TracTickets for help on using tickets.