[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):

 Historically speaking, the reason for these settings being exposed in `/`
 (as opposed to allowing non-admins read access to `/wp/v2/settings`) is
 that there wasn't an immediate need for unifying the way these settings
 were read, so the discussion we're having on this ticket now was punted.
 🙂

 I agree with @TimothyBlynJacobs's assessment that the primary question is
 whether the context switching should happen on the client side (read
 values from `/`, write values to `/wp/v2/settings`), or on the server side
 (alter `/wp/v2/settings` so all users can read public settings). I find
 the idea of reading and writing values to two different locations weird,
 though. As @scruffian mentioned in #48812, this is part of the first step
 towards full site editing in Gutenberg, which means now is a good time to
 make the API for that a bit more consistent than it currently is.

 The question of how to get the `rendered` vs `raw` values is interesting.
 I don't think returning an object with `rendered` and `raw` properties is
 necessary, since non-admins probably shouldn't have access to the `raw`
 value in the first place, regardless of whether the settings is considered
 public or not. There are plenty of reasons why setting value might be
 filtered for non-admins before it's shown to them, let's not circumvent
 that.

 In which case, we need to add `view` and `edit` context support to the
 endpoint. Non-admins can only `GET` the endpoint with `view` context.
 Admins will need to `GET` with `view` context for previewing the block,
 and with `edit` context for editing the block, and then can `POST` to
 update the setting value.

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