[wp-trac] [WordPress Trac] #48885: REST API: Support reading public settings, implement context handling (was: REST API: Add a route to read and update separate site settings)

[WordPress Trac]

#48885: REST API: Support reading public settings, implement context handling
-------------------------------------------------+-------------------------
 Reporter:  scruffian                            |       Owner:
                                                 |  spacedmonkey
     Type:  enhancement                          |      Status:  assigned
 Priority:  normal                               |   Milestone:  5.6
Component:  REST API                             |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests 2nd-        |     Focuses:
  opinion                                        |
-------------------------------------------------+-------------------------

Comment (by TimothyBlynJacobs):

 Based off @johnjamesjacoby's feedback, I wanted to restate what the direct
 needs are from the Gutenberg team out of this ticket that have gotten lost
 thru the various Slack and GitHub conversations.

 Gutenberg makes use of a number of settings in Full Site Editing such as
 the website's title, posts per page, etc... This data is typically things
 that are or would be exposed via the REST API index at `wp-json`.
 Additionally, some of these values have a different "rendered" form and
 "raw" form like the site title and description.

 Right now as I understand it Gutenberg either reads these values from the
 index, or bootstraps them in the JS settings. When interacting with them
 in an editable fashion, Gutenberg then uses the settings endpoint.

 Architecturally, things would be simpler if Gutenberg could use the same
 API endpoint for both cases. To accomplish this, there are three changes
 we must make.

 1. Allow for marking settings as `public` in some fashion, so that they
 are available in the settings endpoint to unauthorized users.
 2. Add support for `context` to allow for settings with a `raw` and
 `rendered` form ( or similar patterns ).
 3. Introduce a `prepare_callback` to allow for settings to customize their
 output.

 We also need to make sure that the `title` and `description` settings that
 currently are exposed can change to outputting a `raw` and `rendered`
 object while maintaining backward compatibility. This could be done by
 only using that format when the `context` value is explicitly defined, or
 we'll have to bite the bullet and version the endpoint.

 This doesn't mean it has to be done using a `public` flag. Allowing for
 callbacks to implement more specific handling makes sense to me, but it
 isn't mandatory. As stated in my earlier comment, my worry about
 implementing an `edit_permission_callback` is that we need to make sure it
 isn't bypassable via `options.php`. This could be done by checking for the
 callback specifically before the individual `update_option` calls, or we
 could introduce a `manage_option` meta capability perhaps.

 I think if we don't take the permission callback into account at all, it
 will be misleading to developers who think they can use it to safely
 secure an option.

 ----

 Based on the additional work required before Beta 1 in two weeks, I think
 we should move this to 5.7. Full Site Editing isn't shipping in 5.6, so
 we'll have more time to give this the refinement it needs.

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