[wp-trac] [WordPress Trac] #39854: REST API: Add gmt_offset to base /wp-json response
WordPress Trac
noreply at wordpress.org
Thu Feb 23 18:13:00 UTC 2017
#39854: REST API: Add gmt_offset to base /wp-json response
-------------------------------------------------+-------------------------
Reporter: jnylen0 | Owner: jnylen0
Type: enhancement | Status: accepted
Priority: normal | Milestone: 4.8
Component: REST API | Version: 4.7
Severity: normal | Resolution:
Keywords: has-patch needs-unit-tests needs- | Focuses: rest-api
refresh dev-feedback |
-------------------------------------------------+-------------------------
Changes (by jnylen0):
* keywords: => has-patch needs-unit-tests needs-refresh dev-feedback
* owner: => jnylen0
* status: new => accepted
Comment:
@sagarkbhatt thanks for working on this, though I think it is going to
take a couple more iterations to get it finished.
Currently, I can visit e.g. https://nylen.io/wp-dev/wp-json?context=edit
without authentication. Your latest patch would change that request to
return an error, which I don't think is a good idea.
One way to work around this would be to just add the additional arguments
if the request is correctly authenticated. This is backwards-compatible;
however, it isn't very discoverable. Marking as `dev-feedback` to get
other contributors' opinions here.
`current_user_can( 'edit_posts' )` looks like a reasonable authentication
check here, though I think simply `is_user_logged_in()` would also work.
I don't think `wp_parse_args` is the right function to use here, and we
want to make sure the code reads well even after other values are added.
Maybe something like this would work:
{{{#!php
if ( 'edit' === $request['context'] ) {
if ( is_user_logged_in() ) {
$available['gmt_offset'] = get_option( 'gmt_offset' );
}
}
}}}
Finally, as noted before, we need unit tests for this change. I can think
of several cases to test:
- Unauthenticated request: `gmt_offset` does not appear in the response.
- Request with insufficient authentication: `gmt_offset` does not appear
in the response.
- Authenticated request: `gmt_offset` does appear in the response.
- `gmt_offset` should always be a number, regardless of whether it is set
or the `timezone_string` is set instead. (I don't recall exactly how this
works, maybe we don't have to do anything special here.)
--
Ticket URL: <https://core.trac.wordpress.org/ticket/39854#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list