Allow exact search in REST API

[jimmyh61]

Wordpress only allows full text search when using the REST API but doesn't allow exact search. Yet, the exact search is possible using a search query like:

http://website.com/?s=keyword&exact=1

When you have tens of thousands of posts, being forced to do a full text search can take several seconds and impacts the performance of the website.

It would be an improvement to allow exact search in the WP_REST_Posts_Controller in order to allow REST API requests like:

http://website.com/wp-json/wp/v2/posts?s=keyword&exact=1

[TimothyBlynJacobs]

Welcome to Trac @jimmyh61!

This seems sensible to me. Instead of just exact, I think we'd want to be a bit more specific, either exact_search or search_exact.

Do you want to work on a patch for thisr issue?

[jimmyh61]

Add exact search to REST API

[jimmyh61]

Hi @TimothyBlynJacobs,

I created a patch and used the term exact_search like you suggested.

[TimothyBlynJacobs]

This looks good @jimmyh61! Are you interested in working on unit tests for this issue?

[jimmyh61]

@TimothyBlynJacobs,

I'm not familiar with unit tests. Can somebody else work on that?

[johnregan3]

Same patch with Tests added.

[johnregan3]

@ironprogrammer Tests Added.

[johnregan3]

Improved testing.

[ironprogrammer]

Great collaboration, @jimmyh61 and @johnregan3!

@johnregan3, would you be able to add "optional" $message params to the assertions in 56350.tests.improved.diff?

Why? Because the test contains multiple assertions, ​it's ideal for error messages to indicate why a particular assertion failed.

I'm not certain the third assertion is required, since that seems more like a test that $request didn't reset, which isn't the class under test in this context.

[ironprogrammer]

Test Report

This ​combined test report includes testing instructions and enhancement patch test results.

Patch tested: https://core.trac.wordpress.org/attachment/ticket/56350/56350.diff

LGTM 👍🏻 When it lands, it will need needs-user-docs.

Steps to Test

(Exact post content is at tester's discretion; samples provided are from the unit test. Just ensure that each post's title is unique and that there is a shared keyword between the content.)

1. Create and publish a new post with title "Rye", and content "This is a post about Rye Bread".
2. Create and publish a second post with title "Types of Bread", and content "Types of bread are White and Rye Bread". Note that the keyword "rye" is shared between the two posts.
3. Regression Test: In a browser load the following URL: <your site>/wp-json/wp/v2/posts?search=rye

(The REST API search parameter corresponds to the WP_Query s parameter.)

4. ✅ The JSON results should contain at least two (2) results, more if you have other posts containing "rye" (a JSON viewer extension may be helpful to view the results here).
5. Enhancement Test: In a browser load the following URL: <your site>/wp-json/wp/v2/posts?search=rye&exact_search=true

(The patch's exact_search REST API parameter corresponds to the WP_Query exact parameter.)

6. ✅ The exact search JSON results should contain just one (1) result: the "Rye" post.

Expected Results

• ✅ Querying the API without the new API parameter should return all posts containing the search keyword.
• ✅ Querying the API with exact_search should only return the post name matching the search keyword.

Environment

• OS: macOS 12.5
• Browser: Safari 15.6
• Browser: Google Chrome 104.0.5112.79
• Server: nginx/1.23.1
• PHP: 7.4.30
• WordPress: 6.1-alpha-53344-src

Actual Results

After applying patch...

• ✅ Querying the API without the new API parameter returned all posts containing the search keyword.
• ✅ Querying the API with exact_search only returned the post name matching the search keyword.

[jimmyh61]

Great collaboration!
I reproduced the steps to test and got the same results. Everything seems to work as expected.

[mehulkaklotar]

I have replicated the steps and got the correct results every time. Looks good on my end too. There were tests errors in the commit though.

I have pushed fixed changes in the PR now to test it with different versions of PHP.

Trac ticket: https://core.trac.wordpress.org/ticket/56350

[mehulkaklotar]

contains fixes for the tests failing

@ironprogrammer @TimothyBJacobs What is your thoughts on ​https://github.com/WordPress/wordpress-develop/pull/3677#discussion_r1032178888?

[mehulkaklotar]

latest changes

[flixos90]

The PR looks good to me, and we already have test coverage as well as did testing. I just refreshed the patch on GitHub, and there's a test failure, but it looks like something we should be able to quickly fix.

Once that's done, I'd say this can be committed.

Hm, though looking at this, if we do want to add sentence support, we probably want to change this to be something like search_semantics as an enum of either exact or sentence? So you could do search_semantics=exact,sentence?

@TimothyBJacobs At this point, we'd probably only support the exact value though, right (as for this PR)? I'm okay choosing a future compatible path here, that said we could also go with the current pragmatic approach and if we want to support more later change it (e.g. deprecate the current one). What do you think?

Yeah, I don't think this is _bad_ as is. A search_semantics style parameter is more forward compatible. I don't think we've officially deprecated any actual query parameters yet. But I don't think a search_exact and search_sentence is the worst thing.

@TimothyBJacobs Updated to use search_semantics enum parameter in ​https://github.com/WordPress/wordpress-develop/pull/3677/commits/15ee6825f31f62c61fe4b148e85c81b1988ff4a7.

[flixos90]

In 59034:

REST API: Support exact search in the REST API posts endpoint.

This changeset adds support for a new search_semantics enum query parameter that can be passed alongside the search string parameter. At this point, it only supports "exact" as possible value, but an enum is used for forward compatibility with potential enhancements like "sentence" search support. If search_semantics=exact is passed, it will look for an exact match rather than do a full text search, which for some use-cases is more appropriate and more performant.

Props mehulkaklotar, timothyblynjacobs, jimmyh61, ironprogrammer, johnregan3, mukesh27, costdev.
Fixes #56350.

Committed in https://core.trac.wordpress.org/changeset/59034