Customize: Add REST API endpoints for panels, sections, controls, settings, and partials

[westonruter]

In order to make the customizer a REST API-backed application, the objects that it uses need to have REST API endpoints. In addition to having an endpoint for changesets (#38900), there should be endpoints for getting a list of the panels, sections, controls, settings, and partials. One immediate benefit for these endpoints will be to allow for the objects to be lazy-loaded when needed (#28580) to improve performance. Having schemas attached to WP_Customize_Setting would also allow controls to be generated automatically with the appropriate validation constraints (#38845). This will also facilitate bootstrapping the customizer onto the frontend so that customization can be done without going to customize.php.

Feature plugin repo: ​https://github.com/WP-API/wp-api-customize-endpoints

[celloexpressions]

+1. This could be useful internally for the core customize app and also externally, and extend the current API by respecting the to_json() stuff that objects are already doing. I'd see a goal here be to generate the customize object json via the API instead of directly; however, there needs to be some demonstration of why using the API is better.

[westonruter]

Using the REST API as the interface for obtaining the configurations may not be better for customize.php's exporting to _wpCustomizeSettings, especially in the case of serializing out a LOT of data in one big chunk which had major performance problems as shown in #33898. In that regard, we may actually want to consider proposing a REST API improvement to \WP_REST_Server::serve_request()). We'd need to ensure that we still serialize out each JS object separately for the sake of memory. But also I hope that with a REST interface for obtaining settings and controls, we'd be able to lazy-load these via #28580 as needed (e.g. when the panel expands) rather than load all of this data up front which can incur a heavy server load to generate the initial customize.php response. We could do internal REST API calls to /customize/settings and /customize/controls etc instead of looping over these manually directly with PHP.

[jbpaul17]

Moving to 4.8.1 while development continues on the GitHub repo.

[stubgo]

Note: starting working on the ticket.

[westonruter]

As noted in #38900, work on this will continue in feature plugin and be tested during the development of a planned Customizer v2 feature plugin. No need to get this merged into core before feature plugin fully utilizes it in core.

[westonruter]

New feature development is being directed toward the Site Editor, so I'm closing this.