REST API fails if subtype CPT doesnt exist in Search Endpoint

[SirLouen]

If we issue this query to the REST API search endpoint:

http://example.com/?rest_route=/wp/v2/search&search=hello&per_page=20&type=post&subtype=post,other-type

And other-type doesn't exist as a CPT

It's going to fail with:

{
  "code": "rest_invalid_param",
  "message": "Invalid parameter(s): subtype",
  "data": {
    "status": 400,
    "params": {
      "subtype": "subtype[1] is not one of post, page, category, post_tag, and any."
    },
    "details": {
      "subtype": {
        "code": "rest_not_in_enum",
        "message": "subtype[1] is not one of post, page, category, post_tag, and any.",
        "data": null
      }
    }
  }
}

The expectation was that it should issue the query, simply disregarding the non-existent subtypes.
Still, I would like to hear more opinions on this topic.

This was originally reported here: ​https://github.com/WordPress/gutenberg/issues/55810
This is why I'm still not 100% confident if this is the expected behaviour. It feels an edge case and without an use-case I can't figure out the utility

[mindctrl]

This appears to be intentional. The other-type is not a valid enum option if it's not a valid post type. See WP_REST_Post_Search_Handler::__construct() where it calls get_post_types() to define the subtypes.

Reference: ​https://github.com/WordPress/wordpress-develop/blob/965ee6152caa8a3e2bea2bf18e405220e45c53df/src/wp-includes/rest-api/search/class-wp-rest-post-search-handler.php#L28-L39

[SirLouen]

Replying to mindctrl:

This appears to be intentional. The other-type is not a valid enum option if it's not a valid post type. See WP_REST_Post_Search_Handler::__construct() where it calls get_post_types() to define the subtypes.

Reference: ​https://github.com/WordPress/wordpress-develop/blob/965ee6152caa8a3e2bea2bf18e405220e45c53df/src/wp-includes/rest-api/search/class-wp-rest-post-search-handler.php#L28-L39

Yes, this is why I tagged this as an enhancement and not a bug. Given that this is a search, and the possibility that there could be a programmatic search, not hindering the search with the fact that the CPT may not exist. And I was also assuming the possibility of a use-case existence. Personally, I would rather wait for the reporter to comment more on a use-case, but I feel this unlikely. I would have closed the GB all around, but just opened this issue as a reported upstream version and see for a couple of months if the reporter is still interested in providing additional information on what she was pretending to achieve.

[marincarroll]

@SirLouen In my case, the various custom post types I was querying were registered by plugins. If one of the plugins isn't active, you don't get any results. It would have been preferable for me if it returned results for whichever CPTs are registered rather than no results, so that various combinations of plugins can be activated/deactivated while the search still works, but I can see an argument where I should have been responsible for checking which were registered beforehand.

[SirLouen]

Replying to marincarroll:

@SirLouen In my case, the various custom post types I was querying were registered by plugins. If one of the plugins isn't active, you don't get any results. It would have been preferable for me if it returned results for whichever CPTs are registered rather than no results, so that various combinations of plugins can be activated/deactivated while the search still works, but I can see an argument where I should have been responsible for checking which were registered beforehand.

I was thinking that this could be the issue. It's a pretty edge case and as you say, there is an argument for not doing a correct use. On the other hand, since it's an open search query, it should not be that restrictive for pretty much anything (like a fuzzy search). I cannot really decide which option of the two fits better. Personally, I always prefer the least strictness on search queries possible, but I can also see the argument of being strict to ensure more consistency. This is why I added the 2nd-opinion.

[TimothyBlynJacobs]

Thanks for the ticket @SirLouen.

As @mindctrl mentions, this is intentional. It's a design decision for the REST API to reject invalid values instead of silently ignoring them.

and the possibility that there could be a programmatic search,

The args definition for the route can be used to determine what types and subtypes are supported programatically.