Make WordPress Core

Opened 8 years ago

Closed 4 years ago

#38731 closed enhancement (duplicate)

Allow publicly readable settings within WP_REST_Settings_Controller

Reported by: davecpage's profile davecpage Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.7
Component: REST API Keywords: needs-patch needs-unit-tests
Focuses: Cc:


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)

#1 @jnylen0
8 years ago

There was some more discussion on "readonly settings" starting here:

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 (site name, description, url, and home).

Here's what I think we should do about this (cc @joehoyle @rachelbaker for your opinions).

  • Create a new ticket to enhance the /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.
  • Once we have a plan for adding more site info, close this ticket.

#2 @jnylen0
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 @joehoyle
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

#5 @spacedmonkey
4 years ago

#48812 was marked as a duplicate.

#6 @spacedmonkey
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.

                        '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.

#7 @TimothyBlynJacobs
4 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to duplicate
  • Status changed from new to closed

Closing as a duplicate of the newer #48885 since it has more context.

Note: See TracTickets for help on using tickets.