Don't return route URL in WP_REST_Request:get_params()

[danielbachhuber]

Not sure if this was intended, but it's annoying me. In my callback, where $request is WP_REST_Request object and I do this:

$params = $request->get_params();
$zero = $request->get_param( 0 );

I get a 0 index in $params and $zero has the route URL. I don't see why it should be a param, it's not registered on the endpoint, and its redundant to what I can get with the get_url_params() method.

Originally reported in ​https://github.com/WP-API/WP-API/issues/1621

[rmccue]

I think this is an artifact of the preg_match_all call?

[rmccue]

Yup, this is from the preg_match inside WP_REST_Server::dispatch. There's no way to have preg_match return only the named groups from here; apart from being useless, is there any issue with having this?

[danielbachhuber]

Replying to rmccue:

apart from being useless, is there any issue with having this?

It's incorrect?

If you were to iterate over $params, you'd get an unexpected result.

[danielbachhuber]

34647.1.diff unsets $args[0] generated by preg_match() when $args[0]===$path. Includes tests.

[rmccue]

I'm OK with unsetting $args[0]; we can do that unconditionally though, as it's always $path.

My only concern is that it may potentially break expectations if you have a route like /tests/(\d+); this sets $args[1] to the number as you'd expect, but doesn't set $args[0] as you may expect if you know preg_match. This is super edge case though, to which the answer is "don't use $args[0]". :)

[rmccue]

In 35659:

REST API: Remove redundant "0" parameter.

This is just an artifact of how we parse the URL, and is already available
via $request->get_route()

Props danielbachhuber.
Fixes #34647.