[wp-trac] [WordPress Trac] #48885: REST API: Support reading public settings, implement context handling

[WordPress Trac]

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

Comment (by joemcgill):

 Following up here after some discussion with @TimothyBlynJacobs to
 specifically address the questions raised by @youknowriad in [comment:39
 this comment]:

 > The immediate need for us is a solution for this PR
 https://github.com/WordPress/gutenberg/pull/66459
 > We want to move defaultTemplates and defaultTemplateParts settings to an
 endpoint.
 >
 > Note that these two are a bit specific compared to the settings
 mentioned above:
 >
 >  - They are not editable
 >  - They are filterable in php
 >  - They are not `wp_options` settings.
 >  - They are also not editor specific.
 >  - They are also not sensitive data.
 >
 > So what we need is a clear path forward:
 >
 >  - Should we continue adding this kind of settings to the `/` endpoint?
 >  - Should we work on allowing "readonly" settings in the settings
 endpoint, even if they are no wp_options settings?
 >  - Should this be a completely new endpoint: why? and what makes a
 setting belong to one endpoint but not the other.


 Currently, it seems that information like `defaultTemplates()` and
 `defaultTemplateParts()` are not appropriate for the `/settings` endpoint.
 At present, that endpoint is designed to be a CRUD endpoint specifically
 used for interacting with the Options API. Given that templates and
 template parts are not stored as options, they would better fit somewhere
 else.

 For other use cases, like being able to provide read-only access to
 "public" settings, [comment:35 as described by @spacedmonkey] it seems
 that [comment:30 the next steps proposed by @TimothyBlynJacobs] still
 apply.

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