Make WordPress Core

Opened 7 years ago

Closed 22 months ago

#39634 closed enhancement (wontfix)

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

Reported by: westonruter's profile westonruter Owned by: stubgo's profile stubgo
Milestone: Priority: normal
Severity: normal Version: 4.7
Component: Customize Keywords: has-patch
Focuses: rest-api Cc:

Description (last modified by 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:

Change History (13)

#1 @westonruter
7 years ago

  • Description modified (diff)

#2 @celloexpressions
7 years ago

  • Keywords needs-patch added
  • Version set to 4.7

+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.

#3 @westonruter
7 years ago

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.

#4 @westonruter
7 years ago

  • Description modified (diff)

This ticket was mentioned in Slack in #core by westonruter. View the logs.

7 years ago

#6 @jbpaul17
7 years ago

  • Milestone changed from 4.8 to 4.8.1

Moving to 4.8.1 while development continues on the GitHub repo.

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.

7 years ago

#8 @stubgo
7 years ago

Note: starting working on the ticket.

#9 @westonruter
7 years ago

  • Owner set to stubgo
  • Status changed from new to assigned

#10 @westonruter
7 years ago

  • Milestone changed from 4.8.1 to 4.9

This ticket was mentioned in Slack in #core-customize by jeffpaul. View the logs.

7 years ago

#12 @westonruter
7 years ago

  • Keywords has-patch added; needs-patch removed
  • Milestone changed from 4.9 to Future Release

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.

#13 @westonruter
22 months ago

  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from assigned to closed

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

Note: See TracTickets for help on using tickets.