Customize Snapshots

Description

Customize Snapshots is the feature plugin which prototyped Customizer changesets; this feature was merged as part of WordPress 4.7. The term “snapshots” was chosen because the Customizer feature revolved around saving the state (taking a snapshot) of the Customizer at a given time so that the changes could be saved as a draft and scheduled for future publishing.

While the plugin's technical infrastructure for changesets was merged in WordPress 4.7, the user interface still remains largely in the Customize Snapshots plugin, in which we will continue to iterate and prototype features to merge into core.

For a rundown of all the features, see the screenshots below as well as the 0.6 release video:

This plugin works particularly well with Customizer Browser History, which ensures that URL in the browser corresponds to the current panel/section/control that is expanded, as well as the current URL and device being previewed.

Requires PHP 5.3+. Development of this plugin is done on GitHub. Pull requests welcome. Please see issues reported there before going to the plugin forum.

Screenshots

The “Save & Publish” button becomes a combo-button that allows you to select the status for the changeset when saving. In addition to publishing, a changeset can be saved as a permanent draft (as opposed to just an auto-draft), pending review, scheduled for future publishing. A revision is made each time you press the button.

For non-administrator users (who lack the new customize_publish capability) the “Publish” button is replaced with a “Submit” button. This takes the changeset and puts it into a pending status.

When selecting to schedule a changeset, the future publish date can be supplied. Changesets can be supplied a name which serves like a commit message.

When selecting Publish, a confirmation appears. Additionally, a link is shown which allows you to browse the frontend with the changeset applied. This preview URL can be shared with authenticated and non-authenticated users alike.

The admin bar shows information about the current changeset when previewing the changeset on the frontend.

The Customize link is promoted to the top in the admin menu; a link to list all changesets is also added.

The Customize link in the admin bar likewise gets a submenu item to link to the changesets post list.

The Changesets admin screen lists all of the changeset posts that have been saved or published. Row actions provide shortcuts to preview changeset on frontend, open changeset in Customizer for editing, or inspect the changeset's contents on the edit post screen.

When excerpts are shown in the post list table, the list of settings that are contained in each changeset are displayed.

Opening a changeset's edit post screen shows which settings are contained in the changeset and what their values are. Settings may be removed from a changeset here. A changeset can also be scheduled or published from here just as one would do for any post, and the settings will be saved once the changeset is published. Buttons are also present to preview the changeset on the frontend and to open the changeset in the Customizer for further revisions.

Each time a user saves changes to an existing changeset, a new revision will be stored (if revisions are enabled in WordPress). Users' contributions to a given changeset can be inspected here and even reverted prior to publishing.

Multiple changesets can be merged into a single changeset, allowing multiple users' work to be combined for previewing together and publishing all at once.

Reviews

This is a great plugin. It would be useful to expose the snapshots custom post type in the admin so that users can view the different snapshots, delete the ones they don't need, etc. Is this on the roadmap?

0.5.0 – 2016-08-11

Added:

Allow snapshot posts to be published from the admin, and thus also scheduled for publication. Customizer settings get saved when a snapshot post transitions to the publish status. If any of the settings are unrecognized or invalid, none of the settings are saved and the status gets kicked back to pending with error messages explaining the problem(s). Published snapshots are considered “locked” and the UI for updating them is hidden, aside from trash. (#15, #62, #59)

Add UI for scheduling for scheduling a snapshot when inside the Customizer. When a future date is selected, the “Save” button becomes “Schedule”. (#68)

Ensure that setting validations are handled in snapshot requests. If any settings are invalid, the snapshot save will be rejected, invoking the same behavior as when attempting to publish invalid settings. (#59, #54, #31)

Add link in Customizer to view the snapshot applied to the frontend, adding the customize_snapshot_uuid query param to the current URL being previewed and optioning a new window. (#57)

Add link in Customizer to access the snapshot's edit post admin screen, allowing the snapshot's state to be inspected. (#48, #51)

Inject the customize_snapshot_uuid param into all links when viewing a snapshot on the frontend. This allows the frontend to be browsed as normally with the snapshot context retained. In this mode, the admin bar shows links for returning to the Customizer, for inspecting the snapshot in the admin, and for existing the snapshot preview. If a user happened to navigate to a URL without the snapshot UUID param, then the admin bar will prompt for restoring the snapshot session. (#47, #70)

Inject the current Customizer state into Ajax requests. When viewing a snapshot on the frontend this is done by inserting the customize_snapshot_uuid param into the request via jQuery.ajaxPrefilter. When in the Customizer preview, the Ajax requests are also intercepted by jQuery.ajaxPrefilter: if they are GET they get converted to POST with X-HTTP-Method-Override header added, and the customized data is amended to the request. Requests to the WP REST API, Admin Ajax, and custom endpoints should all have the Customizer state reflected in the responses. (#65, #70)

Also, inject the current Customizer state into form submissions. When viewing a snapshot on the frontend this is done by inserting a customize_snapshot_uuid hidden form input. When in the Customizer preview, forms with a GET method get intercepted and the form data gets serialized and added to the action and then navigated to like a normal link. Forms with POST will continue to no-op when submitted in the Customizer (and their submit buttons will have not-allowed cursor). This fixes a long-standing Trac ticket #20714 “Theme customizer: Impossible to preview a search results page”. (#72)

Fixed:

Changes to nav menus, nav menu items, and nav menu locations can now be saved to snapshots, previewed on the frontend, and published like other settings in a snapshot. (#2, #55, #56)

Clear up distinction between previewing vs saving values in a snapshot. Remove the can_preview method: only users who have the setting's capability can write to the snapshot, so everyone should be able to freely preview what has been stored there. (#26, #59)

Snapshot UUID is dynamically added to the Customizer URL when a snapshot is first saved and it is stripped from the URL once the settings are published (and the snapshot is published), at which point the snapshot is “frozen”. (Issue #37, PR #40).

Update button can now be shift-clicked to open the snapshot on the frontend in a new window.

Eliminate the storage of non-dirty settings in a Snapshot, which deprecates the scope feature (Issue #42)

Support listing snapshots in the admin and inspecting their contents WP Admin UI, with shortcuts to open snapshot in Customizer, viewing the list of settings contained in a snapshot from the excerpt in post list view (Issue #45, PRs #38, #46).

Introduce pending snapshots for users who are not administrators (who lack the customize_publish capability) to be able to make snapshots and save them, and then submit them for review once ready (PR #38).

Added revisions for snapshots so that changes to a snapshot made before the time it is published can be tracked.