[wp-trac] [WordPress Trac] #38900: Customize: Add REST API endpoints for changesets

[WordPress Trac]

#38900: Customize: Add REST API endpoints for changesets
-----------------------------+---------------------------
 Reporter:  westonruter      |       Owner:  valendesigns
     Type:  feature request  |      Status:  assigned
 Priority:  normal           |   Milestone:  4.8
Component:  Customize        |     Version:
 Severity:  normal           |  Resolution:
 Keywords:  needs-patch      |     Focuses:  rest-api
-----------------------------+---------------------------

Comment (by westonruter):

 A `customize-changeset` REST resource would model the
 `customize_changeset` post type. Instead of a `content` field, it would
 instead have a `settings` field that is an object whose keys are the
 settings IDs and whose values are the setting params for the given
 settings in the changeset. Essentially, the `settings` would be the
 deserialized JSON contained within the changeset's `post_content`.

 Also importantly a `customize-changeset` resource would include `status`,
 `author`, `title`, `date`, `date_gmt`.

 The `date` and `date_gmt` would be `readonly`, unless the `status` is
 `future`.

 I think that the `/customize/changesets` endpoint could potentially look
 like this.

 * `GET /customize/changesets`: List all changesets that the current user
 can read.
 * `POST /customize/changesets`: Create a new changeset, with a request
 body containing a valid changeset `item` resource.
 * `PUT /customize/changesets/:uuid`: Create or update a changeset with a
 given UUID, with a request body containing a valid changeset `item`
 resource. To publish a changeset, a `status` should be provided in the
 request. If a changeset is pre-existing and it already has a `publish`
 status, then the request should be rejected since published changesets are
 immutable (essentially revisions).
 * `PATCH /customize/changesets/:uuid`: Update a changeset with a given
 UUID, patching the provided settings with the values. This may not be
 needed, as we could also allow a `PUT` request that simply has `null`
 provided for the settings that are to be removed from the changeset.
 * `DELETE /customize/changesets/:uuid`: Deleting a changeset.

 Note that as part of this, fine-grained capabilities should be introduced
 for the `customize_changeset` post `caps`, instead of mapping all to
 `customize`.

 Essentially, the task here is to take the existing admin-ajax handler in
 `WP_Customize_Manager::save()` and convert it for REST. Once this is done,
 then the `wp.customize.previewer.save()` method and
 `wp.customize.requestChangesetUpdate()` functions in JS can be refactored
 to make use of the new endpoint.

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