WordPress.org
Get WordPress

Make WordPress Core

Changes between Version 56 and Version 57 of Ticket #30937


Ignore:
Timestamp:
10/02/2016 07:48:31 AM (8 years ago)
Author:
westonruter
Comment:

I have a patch for testing! There are still several things I want to polish, but please give this PR a try: ​https://github.com/xwp/wordpress-develop/pull/161

Remember, the patch can be applied via grunt patch:https://github.com/xwp/wordpress-develop/pull/161

For collaboration on the patch, please do not amend the patch and upload new diffs to this ticket. Open PRs to the trac-30937 branch on GitHub or ask me and I'll set you up with direct push access.

Note that I've renamed “transactions” to “changesets” which I think makes more sense.

Here's a companion plugin which enables revisions for Changesets and provides access to the custom post type's admin screens: ​https://gist.github.com/westonruter/b2c9edb9a2ee83236dd9b2b4f177ae76

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #30937

    • Property Summary changed from Add Customizer transactions to Add Customizer changesets (state persistance)
    • Property Keywords has-patch added; needs-patch removed

  • Ticket #30937 – Description

    v56 v57  
    44
    55Another downside is that whenever the preview needs to load a new URL it has to re-send all the modified settings so that the Customizer preview will have them available to add to the filters, since the Customized data is not persisted in WordPress in any way. There's also a performance hit to continually send all data with each request, which was partially improved with #28580.
     6I
     7So I propose that we introduce persisted Customizer settings, in other words '''Customizer ~~transactions~~ changesets'''.
    68
    7 So I propose that we introduce persisted Customizer settings, in other words '''Customizer transactions'''.
     9When opening the Customizer for the first time, a changeset UUID can be generated. Whenever a setting changes, an Ajax request sends the updated setting to WordPress to be persisted in a `customize_changeset` post which has a post_name corresponding to that UUID (or a post is created dynamically if not existing already). Any changes made in the Customizer then get amended to the same `customize_changeset` post, which has a key/value JSON blob as its `post_content`.
    810
    9 When opening the Customizer for the first time, a transaction UUID can be generated. Whenever a setting changes, an Ajax request sends the updated setting to WordPress to be persisted in a `wp_transaction` post which has a post_name corresponding to that UUID (or a post is created dynamically if not existing already). Any changes made in the Customizer then get amended to the same `wp_transaction` post, which has a key/value JSON blob as its `post_content`.
     11Instead of POSTing all of the customized settings to the preview, we then only have to reference the changeset UUID when loading URLs into the Customizer preview. Indeed, the patch I've worked on does this in a way that resolves #30028 (Load Customizer preview iframe with natural URL) and #23225 by injecting the changeset UUID as a query parameter for the URL being previewed and then amended to any site URL generated in the preview, so that navigating around the site in the preview (even following standard links with `GET` requests) will ensure that the changeset will continue to be referenced and loaded. In this way, when a changeset is updated the Customizer preview only has to do `location.reload()` instead of the current approach of doing an Ajax POST request followed by `document.write()` in the iframe window. (Nevertheless, the existing “seamless refresh” logic can remaij in which a loading `PreviewIframe` instance can replace the previously loaded one after it has finished loaded.)
    1012
    11 Instead of POSTing all of the customized settings to the preview, we then only have to reference the transaction UUID when loading URLs into the Customizer preview. Indeed, the patch I've worked on does this in a way that resolves #30028 (Load Customizer preview iframe with natural URL) and #23225 by injecting the transaction UUID as a query parameter for the URL being previewed and then amended to any site URL generated in the preview, so that navigating around the site in the preview (even following standard links with `GET` requests) will ensure that the transaction will continue to be referenced and loaded. In this way, when a transaction is updated the Customizer preview only has to do `location.reload()` instead of the current approach of doing an Ajax POST request followed by `document.write()` in the iframe window.
     13As noted in #20714, my patch also injects the changeset UUID in form submissions (GET and POST), as well as in jQuery Ajax requests. This allows you to preview setting changes for full web applications in the Customizer.
    1214
    13 As noted in #20714, my patch also injects the transaction UUID in form submissions (GET and POST), as well as in jQuery Ajax requests. This allows you to preview setting changes for full web applications in the Customizer.
    14 
    15 Other side-benefits that Customizer transactions will bring us:
     15Other side-benefits that Customizer changesets will bring us:
    1616
    1717 * Settings can be drafted and then returned to later.
    1818 * Settings can be collaborated on by multiple users (though not concurrently, without some Heartbeat system in place)
    19  * The capability to publish a `wp_transaction` post can be limited by role, allowing 'Customizer contributors' to submit settings as pending review.
    20  * Settings can be scheduled for going live at a later date by saving the transaction post simply with `post_status=future` (see #28721)
    21  * With each save in the Customizer resulting in a new transaction post being created, then there is Customizer revision history (see #31088, #31089)
    22  * Accessing the Customizer preview for a transaction needs no special capabilities since the transaction is updated by an authorized user via single Ajax request. This means that Customizer previews (frontend URLs with the transaction UUID amended) can be shared for anonymous users to review.
    23  * Customizer Theme Switch (#31303) could preview another theme and refresh the Customizer without losing settings, and thus no AYS dialog would be needed.
     19 * The capability to publish a `customize_changeset` post can be limited by role, allowing 'Customizer contributors' to submit settings as pending review.
     20 * Settings can be scheduled for going live at a later date by saving the changeset post simply with `post_status=future` (see #28721)
     21 * With each save in the Customizer resulting in a new changeset post being created, then there is Customizer revision history (see #31088, #31089)
     22 * Accessing the Customizer preview for a changeset needs no special capabilities since the changeset is updated by an authorized user via single Ajax request. This means that Customizer previews (frontend URLs with the changeset UUID amended) can be shared for anonymous users to review.
     23 * Customizer Theme Switch (#31303) could preview another theme and refresh the Customizer without losing settings, and thus no AYS dialog would be needed. (See #36485.)
    2424
    25 Something else that motivated my investigation into Customizer transactions is thinking about how the Customizer will relate to the '''JSON REST API'''. How can the REST API be improved with the Customizer? If the REST API provides a `transactions` endpoint for doing CRUD operations on Customizer settings, and if the REST API also has global recognition for a `customize_transaction_uuid` query parameter in all requests, then it becomes possible for the Customizer to be used to preview changes in applications that merely interact with the JSON REST API, as long as they include the transaction UUID in the requests.
     25Something else that motivated my investigation into Customizer changesets is thinking about how the Customizer will relate to the '''JSON REST API'''. How can the REST API be improved with the Customizer? If the REST API provides a `changesets` endpoint for doing CRUD operations on Customizer settings, and if the REST API also has global recognition for a `customize_changeset_uuid` query parameter in all requests, then it becomes possible for the Customizer to be used to preview changes in applications that merely interact with the JSON REST API, as long as they include the changeset UUID in the requests.
    2626
    27 There's a lot of exciting possibilities introduced with Customizer transactions.
     27There's a lot of exciting possibilities introduced with Customizer changesets.
    2828
    29 Initial alpha Core patch for Customizer transactions can be seen at: https://github.com/xwp/wordpress-develop/pull/61
     29Initial alpha Core patch for Customizer changesets can be seen at: https://github.com/xwp/wordpress-develop/pull/61
    3030
    3131See Make Core blog post: https://make.wordpress.org/core/2015/01/26/customizer-transactions-proposal/