#34647 closed defect (bug) (fixed)
Don't return route URL in WP_REST_Request:get_params()
| Reported by: |
|
Owned by: |
|
|---|---|---|---|
| Milestone: | 4.4 | Priority: | normal |
| Severity: | normal | Version: | 4.4 |
| Component: | REST API | Keywords: | has-patch |
| Focuses: | Cc: |
Description (last modified by )
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
Attachments (1)
Change History (9)
#3
follow-up:
↓ 4
@
10 years ago
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?
#4
in reply to:
↑ 3
@
10 years ago
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.
#5
@
10 years ago
- Keywords has-patch added; needs-patch removed
34647.1.diff unsets $args[0] generated by preg_match() when $args[0]===$path. Includes tests.
#6
@
10 years ago
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]". :)
I think this is an artifact of the
preg_match_allcall?