Search: migrate/add search rest API

[kangzj]

Changes proposed in this Pull Request:

Add all necessary APIs for standalone and Jetpack the plugin except for the search_auto_config API and probably the API to deactivate expired search.

1. Returns search plan: GET jetpack/v4/search/plan

{
  "search_subscriptions": [
    {
      "ID": "xxx",
      "user_id": "xxx",
      "blog_id": "xxx",
      "product_id": "2104",
      "expiry": "2025-05-17",
      "subscribed_date": "2021-05-17 05:34:09",
      "renew": "0",
      "auto_renew": "1",
      "ownership_id": "xxx",
      "most_recent_renew_date": "",
      "subscription_status": "active",
      "is_instant_search": true,
      "tier": "up_to_100_records",
      "product_name": "Jetpack Search"
    }
  ],
  "supports_instant_search": true,
  "supports_only_classic_search": false,
  "supports_search": true
}

2. Returns search module settings: GET jetpack/v4/search/settings

{
  "module_active": true,
  "instant_search_enabled": false
}

3. Update search module settings: POST jetpack/v4/search/settings

Request:

{
  "instant_search_enabled": false,
  "module_active": true
}

Response:

{
  "module_active": true,
  "instant_search_enabled": false
}

4. Search endpoint for private sites (private Atomic sites atm): GET jetpack/v4/search

The format is exactly the same with public search API v1.3. Something like the following,

aggregations: []
corrected_query: false
page_handle: false
results: [{_score: 2,…}, {_score: 1.1753112,…}, {_score: 1.1753112,…}, {_score: 1.1753112,…},…]
suggestions: []
total: 6

Jetpack product discussion

n/a

Does this pull request change what data or activity we track or use?

no

Testing instructions:

• Make sure tests pass ( cd projects/packages/search && composer phpunit )
• Go to a site with search subscription
• Set blog_public to -1 in the database
• Ensure instant search calls http://yousite/wp-json/jetpack/v4/search for results and results / filters show correctly.
• Test the APIs separately, I used Rest Client in VSCode. Requests are like the following. You'll need to replace the nonce and cookie which could be get from Chrome dev tools. If you have better ways to test, please let me know 😄

GET https://jasper.au.ngrok.io/wp-json/jetpack/v4/search/plan HTTP/1.1
x-wp-nonce: xxx
cookie: yyy

GET https://jasper.au.ngrok.io/wp-json/jetpack/v4/search/settings HTTP/1.1
x-wp-nonce: xxx
cookie: yyy

POST https://jasper.au.ngrok.io/wp-json/jetpack/v4/search/settings HTTP/1.1
Content-Type: application/json
x-wp-nonce: xxx
cookie: yyy

{
  "instant_search_enabled": false,
  "module_active": true
}

GET https://jasper.au.ngrok.io/wp-json/jetpack/v4/search HTTP/1.1
x-wp-nonce: xxx
cookie: yyy

[github-actions]

Thank you for your PR!

When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:

• ✅ Include a description of your PR changes.
  
• ⚠️ All commits were linted before commit.
  
• ✅ Add a "[Status]" label (In Progress, Needs Team Review, ...).
  
• ✅ Add testing instructions.
  
• ✅ Specify whether this PR includes any changes to data or privacy.
  
• ✅ Add changelog entries to affected projects
  

This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖

---

The e2e test report can be found here. Please note that it can take a few minutes after the e2e tests checks are complete for the report to be available.

---

Once your PR is ready for review, check one last time that all required checks (other than "Required review") appearing at the bottom of this PR are passing or skipped.
Then, add the "[Status] Needs Team review" label and ask someone from your team review the code.
Once you’ve done so, switch to the "[Status] Needs Review" label; someone from Jetpack Crew will then review this PR and merge it to be included in the next Jetpack release.

---

Jetpack plugin:

• Next scheduled release: December 7, 2021.
• Scheduled code freeze: November 30, 2021.

[matticbot]

Caution: This PR has changes that must be merged to WordPress.com
Hello kangzj! These changes need to be synced to WordPress.com - If you 're an a11n, please commandeer and confirm D69399-code works as expected before merging this PR. Once this PR is merged, please commit the changes to WP.com. Thank you!
This revision will be updated with each commit to this PR

[jsnmoon]

Excellent work. All the functionality described in the PR works as expected and the code changes look good, especially with the addition of unit tests.

(I'd still recommend smoke testing the changes for private atomic sites before rolling them out to WPCOM.)

[kangzj]

  // TODO check Plan supports search.   @jsnmoon 

Hi @jsnmoon Thanks for catching this. Now a Plan class is introduced to solve it - and added more tests 😄 Would love another review if possible, thanks.

[jsnmoon]

This looks good to go 👍. I left some revision recommendations inline below.

IMPORTANT: I'll revert changes for Jetpack the plugin and only merge changes for search the package in the PR.

Is there a need for this with these changes? The only translated string ('You are not allowed to perform this action.') is shown only during 4xx API errors.

[kangzj]

Is there a need for this with these changes? The only translated string ('You are not allowed to perform this action.') is shown only during 4xx API errors.

TBH I'm not 100% sure this is the best approach. But I just don't want the PR to touch any files synced with WPCOM - because we don't really want to sync these changes now, as 1. the package is not released to WPCOM yet 2. they might become irrelevant pretty soon - when we finish the package and everything will be in the package and barely nothing to sync from Jetpack the plugin to WPCOM (I guess we could abandon fusion, couldn't we?).

A lot of stacked changes on Jetpack the plugin and don't sync them, seems rather problematic to me. For example, if we have something urgent to fix, it would be pretty hard.

Also by doing so we would be able to consider it with WPCOM Search together, so that we might be able to figure out a better solution, like I mentioned above, getting rid of fusion, etc..

Last but not the least, we'd have more chances to test and discover issues, and less chances to break things.

-----EDIT-------

Will merge all changes as usual.

[kangzj]

Hi @jeherve @anomiex @sdixon194, can I please get a review on this PR please? thanks.

[kangzj]

@Automattic/jetpack-crew Hi team, anyone have a look at this please? Thanks.

[jeherve]

This looks good to me. Let's merge this! 🚢

[github-actions]

Great news! One last step: head over to your WordPress.com diff, D69399-code, and commit it.
Once you've done so, come back to this PR and add a comment with your changeset ID.

Thank you!

[kangzj]

These changes will be synced to WPCOM once the classic/instant search migration is complete.

[kangzj]

D69399-code is abandoned, because class-wpcom-rest-api-v2-endpoint-search.php is not in use on WPCOM.