[wp-trac] [WordPress Trac] #48885: REST API: Add a route to read and update separate site settings

[WordPress Trac]

#48885: REST API: Add a route to read and update separate site settings
--------------------------------------------------+---------------------
 Reporter:  scruffian                             |       Owner:  (none)
     Type:  enhancement                           |      Status:  new
 Priority:  normal                                |   Milestone:  5.4
Component:  REST API                              |     Version:
 Severity:  normal                                |  Resolution:
 Keywords:  has-patch has-unit-tests 2nd-opinion  |     Focuses:
PR Number:                                        |
--------------------------------------------------+---------------------

Comment (by pento):

 Replying to [comment:5 TimothyBlynJacobs]:
 > So if you want to do any modification, you'd have to do it in
 `rest_request_after_callbacks`.

 Adding new data to this response seems like an unsupported edge case: if
 you want to add data, add a setting. An appropriate dev-note should be
 published, of course, to let people know it's happening.

 > 1. Introduce a `view` and `edit` context. Make `edit` the default
 context. When the resource is requested in a `view` context, change the
 value to the rendered version. This would work for public access, but
 doesn't solve the editing requirement. Gutenberg would need to maintain
 both a `view` and `edit` version of the response in the data store.

 For Gutenberg to show an accurately rendered preview, and then to be able
 to edit the data, it probably needs to know how it looks in both the
 `view` and `edit` contexts. So, we need to send that data somehow.

 > 2. Effectively "version" the endpoint based on a request parameter of
 some sort. If that request parameter is present, returns an object for the
 site title that includes the raw and rendered version. When returning the
 public version of the response, only return the rendered property.

 I'm fine with versioning. We haven't done that in Core yet, so there will
 probably need to be a bit of work to come up with a pattern, but it's not
 a super complex thing to do. Eg, a simple model would look something like
 this:

 {{{#!php
 class WP_REST_Settings_v2_1_Controller extends WP_REST_Settings_Controller
 {
         public function __construct() {
                 parent::__onstruct();
                 $this->namespace = 'wp/v2.1';
         }

         public function register_routes() {
                 // Register the same routes, with new namespace and read
 permisions.

         }

         protected function get_registered_options() {
                 // Updated logic for getting registered options based on
 current user permissions.
         }
 }
 }}}


 > 3. Introduce the single option endpoints and use the desired response
 format there. This would lead to inconsistencies between the collection
 and single item responses.

 This option feels like overkill, and I agree that the inconsistencies
 would be undesirable.

 > I'm not wild about any of these options. They all would introduce
 complexity into the security sensitive settings controller. To me, it
 doesn't seem like any more of a desirable solution than handling it in the
 client. It feels strange to expose settings to the public in a manner like
 this.

 The problem is that we have a bunch of obviously public options (eg,
 `blogname`, `blogdescription`, `siteurl`, `timezone_string`) mixed in with
 a few obviously private options (eg, `admin_email`).

 I don't think it's necessary to create an entirely new way of registering
 public options, just adding the `public` flag to the `register_setting()`
 call is much the same as when the `show_in_rest` flag was added.

 Replying to [comment:6 scruffian]:
 > I dont think they would be exposed to the public, only to those who had
 `edit_posts`.

 I'd be inclined to expose these options publicly, rather than restricting
 to those with `edit_posts`. Otherwise, the `public` flag doesn't really
 make sense as it's named. Also, `edit_posts` is highly specific to the
 circumstances under which this REST API change is coming into being: it's
 reasonable to assume that an option marked as "public" should be readable
 by anyone.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/48885#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform