Opened 8 years ago
Closed 4 years ago
#38731 closed enhancement (duplicate)
Allow publicly readable settings within WP_REST_Settings_Controller
Reported by: | davecpage | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 4.7 |
Component: | REST API | Keywords: | needs-patch needs-unit-tests |
Focuses: | Cc: |
Description
With register_setting()
developers can expose a setting to appear within REST queries on /wp/v2/settings
. Very useful I thought for API only based frontends. However though I agree that editing these settings is limited to those authenticated users who have 'manage_options' it appears that the reading of these settings is limited to the same.
Would it therefore be useful to allow exposing some/all of these settings to unauthenticated users. Maybe with a 'public' => true
flag on each setting so that this can be opt-in from a security point of view?
The alternative appears to be for developers to effectively duplicate the WP_REST_Settings_Controller under a different namespace/endpoint exposing those fields they wish to be viewable.
Change History (7)
#2
@
8 years ago
Another option would be to recognize that there are lots of reasons to need access to site settings data specifically, and go ahead and implement finer-grained read permissions on the settings endpoint anyway.
See also: ticket:38342#comment:48
#3
@
8 years ago
@jnylen0 totally agree with the two options here. I think we should lead towards the first "Create a new ticket to enhance the /wp-json". I wonder if we could provide an easy way for developers to be able to do that. Right now, I'm not sure how simple this is to do.
This ticket was mentioned in Slack in #core-editor by aduth. View the logs.
7 years ago
#6
@
4 years ago
- Keywords needs-patch needs-unit-tests added
I think we should make the settings endpoint public and have a auth_callback
callback on the setting schema.
register_setting(
'general',
'blogname',
array(
'show_in_rest' => array(
'name' => 'title',
'auth_callback' => 'manage_options',
),
'type' => 'string',
'description' => __( 'Site title.' ),
)
);
This callback would be called all registered settings, to see if should be displayed or not. To make a setting public, all that would be required would be.
'auth_callback' => '__return_true',
By default, we would have to make 'auth_callback' => 'manage_options',
to stop existing options going public.
I know this ticket would be especially useful to the gutenberg team to get data out of WordPress.
There was some more discussion on "readonly settings" starting here: https://core.trac.wordpress.org/ticket/38490#comment:10
To summarize, a "readonly setting" is a misnomer because it's not really a "setting" as defined by the endpoint that lets you view and edit site settings. This is really "site info". As such, if it's going to live somewhere, it should probably be on the root
/wp-json
endpoint which already has some of these properties (sitename
,description
,url
, andhome
).Here's what I think we should do about this (cc @joehoyle @rachelbaker for your opinions).
/wp-json
endpoint with any extra site properties (the current settings endpoint and the list here are both good starting points). We may also need a mechanism for versioning the response of this endpoint and having its response vary based on the user's capabilities. Addressing all of this can wait until a future release.