Add Customizer state persistence in changesets (formerly “transactions”)
|Reported by:||westonruter||Owned by:||westonruter|
|Component:||Customize||Keywords:||has-patch needs-testing needs-unit-tests|
Description (last modified by westonruter)
A downside to this current approach is that if the user navigates away from the Customizer, they lose their settings. To get around this, we added an AYS dialog in #25439, but this still doesn't account for browser crashes or system failures.
Another 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.
So I propose that we introduce persisted Customizer settings, in other words Customizer
When 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.
Instead 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.)
As 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.
Other side-benefits that Customizer changesets will bring us:
- Settings can be drafted and then returned to later.
- Settings can be collaborated on by multiple users (though not concurrently, without some Heartbeat system in place)
- The capability to publish a customize_changeset post can be limited by role, allowing 'Customizer contributors' to submit settings as pending review.
- Settings can be scheduled for going live at a later date by saving the changeset post simply with post_status=future (see #28721)
- With each save in the Customizer resulting in a new changeset post being created, then there is Customizer revision history (see #31088, #31089)
- 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.
- 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.)
Something 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.
There's a lot of exciting possibilities introduced with Customizer changesets.
Initial alpha Core patch for Customizer changesets can be seen at: https://github.com/xwp/wordpress-develop/pull/61
See Make Core blog post: https://make.wordpress.org/core/2015/01/26/customizer-transactions-proposal/
- #30028: Load Customizer preview iframe with natural URL
- #30936: Dynamically create WP_Customize_Settings for settings created on JS client
- #27355: Customizer: Add framework for partial preview refreshes
- #20714: Theme customizer: Impossible to preview a search results page
- #23225: Customizer is Incompatible with jQuery UI Tabs.
- #28721: Scheduled changes for the customizer
- #31088/#31089: Customizer revisions
- #31517: Customizer: show a notice after attempting to navigate to external links in live previews
- #34893: Improve Customizer setting validation model
- #34142: Links with preventDefault() don't have action prevented in Customizer
- #28227: Customizer: Error message instead of blank screen
- #31641: Theme Preview using "Customize.php" error
- #22037: Customizer: Live preview fetches page but does not display
- #36485: Lost pending customizer settings after theme change
Change History (97)
2 years ago
- Milestone changed from 4.2 to Future Release
- Type changed from task (blessed) to feature request
8 months ago
8 months ago
8 months ago
7 months ago
7 months ago
7 months ago
- Description modified (diff)
- Keywords has-patch added; needs-patch removed
- Summary changed from Add Customizer transactions to Add Customizer changesets (state persistance)
7 months ago
- Summary changed from Add Customizer changesets (state persistance) to Add Customizer state persistence in changesets (formerly “transactions”)