[wp-trac] [WordPress Trac] #42061: Add new utility function for checking if the current request is a REST API request.
WordPress Trac
noreply at wordpress.org
Sun Jan 24 20:02:49 UTC 2021
#42061: Add new utility function for checking if the current request is a REST API
request.
------------------------------------+------------------------------------
Reporter: lots.0.logs | Owner: TimothyBlynJacobs
Type: enhancement | Status: assigned
Priority: normal | Milestone: 5.7
Component: Bootstrap/Load | Version: 4.9
Severity: normal | Resolution:
Keywords: has-patch dev-feedback | Focuses: rest-api, performance
------------------------------------+------------------------------------
Changes (by TimothyBlynJacobs):
* owner: flixos90 => TimothyBlynJacobs
Comment:
As @flixos90 mentioned, checking if this is a REST API request "properly"
requires parsing rewrite rules. As such, if we want to support checking
this early, we essentially need to duplicate some of the logic in
`WP::parse_request`. I've attached a PR that does this and works in my
testing so far with the built-in dev environment for.
- `http://localhost:8889/wp-json`
- `http://localhost:8889/index.php/wp-json`
- `http://localhost:8889/index.php?rest_route=/`
- `http://localhost:8889/?rest_route=/`
Just because we are replicating the logic doesn't mean this guarantees
correctness since the query could be modified with a number of hooks that
would change behavior and the rewrite rules could be setup to be something
completely different from `rest_api_register_rewrites`. I think there may
also be issues if `WP_Rewrite::$index` is overwritten and the function is
called before `WP_Rewrite` is setup.
There is also the handling for when the REST API is accessed without
pretty permalink. An issue here is that essentially we are trying to
detect if `wp` will be called, but there is no way to guarantee `wp` will
or will not be called before it is called. I implemented this by checking
for the `WP_USE_THEMES` constant which works for vanilla core AFAICT, but
again customized setups might have issues.,
However, I think we should be able to make it work for all "out of the
box" server setups, ie where those advanced customizations haven't been
made. If a site is making those adjustments, they could use the filter to
provide more accurate detection.
If we want to continue with this, it'd need to be manually tested in a
number of different server environments. And we'd have to be careful about
usage. I'd think Core should probably only use the function post
`parse_request`. I think it is still useful to allow for it to be called
prior to that for usage in plugins.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/42061#comment:20>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list