Opened 9 years ago
Last modified 6 years ago
#34211 new enhancement
Ability to specify fields WP_Query can search
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 4.4 |
Component: | Query | Keywords: | needs-patch |
Focuses: | Cc: |
Description
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)
#2
@
9 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.
9 years ago
#4
@
9 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.
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.