Customize Snapshots
XWP By XWP

November 16, 2017

Customize Snapshots Plugin

Provide a UI for managing Customizer changesets; save changesets as named drafts, schedule for publishing; inspect in admin and preview on frontend.

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

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

    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.

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

    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.

  3. 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 to schedule a changeset, the future publish date can be supplied. Changesets can be supplied a name which serves like a commit message.

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

    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.

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

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

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

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

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

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

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

    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.

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

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

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

    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.

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

    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.

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

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

Changelog

0.7.0 – 2017-11-15

  • Added: Add compatibility with 4.9, re-using features of the plugin that have been merged into core in this release. Increase minimum required version of WordPress to 4.7. See #162.
  • Added: Remove hiding of Add New links for changesets in favor of just redirecting post-new.php to Customizer. See #156.
  • Added: Allow publishing from preview via link in admin bar. See #115, #103.
  • Updated: Change link text for post list table action from “Edit” to “Inspect”. See #155, #153.
  • Fixed: Prevent changeset session remembrance when browsing in preview iframe. See #154.
  • Added: Include required PHP version (5.3) in readme. See #160, #159.
  • Updated: Dev dependencies.

Props: Sayed Taqui (@sayedwp), Weston Ruter (@westonruter), Miina Sikk (@miina), Derek Herman (@valendesigns), Ryan Kienstra (@kienstra), Anne Louise Currie (@alcurrie).

See issues and PRs in milestone and 0.6.2...0.7.0 commit log.

0.6.2 – 2017-07-26

  • Added: Just like the admin menu has Changesets link under Customize, add Changesets link in admin bar submenu item under Customize. See #143.
  • Fixed: Restore frontend changeset preview session resuming, to restore the previously previewed changeset in case of accidentally navigating away from frontend changeset preview. See #145.
  • Fixed: Remove markup from changeset post list table excerpts since now escaped. See #146.
  • Fixed: Include missing minified scripts in js/compat directory (only applies to WP<4.7). See #144.
  • Fixed: Hide Remove Setting link when viewing a published changeset. See #141.

See full commit log: 0.6.1...0.6.2

See issues and PRs in milestone.

0.6.1 – 2017-07-17

  • Fix exception thrown when attempting to activate plugin on Windows environment, or when plugin is in non-standard location. See #105, #139.
  • Fix issue with saving option settings when publishing a changeset outside of the Customizer, such as from the edit post admin screen. See #137, #138.

See full commit log: 0.6.0...0.6.1

See issues and PRs in milestone.

0.6.0 – 2017-07-06

  • Added: Extend, integrate with and defer to changesets in WP 4.7. See #99, #102, #119, #120, #122, #124, #123, #111, #108, #112, #127, #131, #132.
  • Added: Allow snapshots to be named. See #19, #76.
  • Added: Allow multiple snapshots to be merged into a single snapshot. See #67, #92.
  • Added: Add hooks to support customize-concurrency plugin. See #87.
  • Added: Enable deleting settings in snapshot wp-admin/post page. See #17, #84.
  • Added: Remember the preview URL and expanded panel/section when saving a changeset; remember preview url query params. See #107, #129.
  • Fixed: Cleanup nav menu created posts if its reference doesn’t exists. See #135, #133.
  • Fixed: Ensure that revisions get created when changesets are updated via explicit saves.
  • Fixed: Add customize as top menu for all user. See #110, #114.
  • Fixed: Disable quick edit. See #89, #100.
  • Fixed: Timezone issue on compare date. See #97.
  • Fixed: Admin footer script hook to support WP 4.5. See #94.
  • Fixed: Snapshot publish issue after settings save. See #89.
  • Fided: Use non-minified scripts and styles if plugin installed via git (submodule). See #91.
  • Fixed: Date handling compatibility with Safari. See #134.

See full commit log: 0.5.2...0.6.0

See issues and PRs in milestone.

Props: Sayed Taqui (@sayedwp), Utkarsh Patel (@PatelUtkarsh), Weston Ruter (@westonruter), Ryan Kienstra (@kienstra), Luke Gedeon (@lgedeon), Derek Herman (@valendesigns).

0.5.2 – 2016-08-17

  • Fixed: Prevent enqueueing frontend JS in the customizer preview. This was erroneously causing the customize_snapshot_uuid param to get injected into links in the preview. See #80.
  • Fixed: Ensure that Update button gets disabled and reset to Save once changes have been published. See #83.

See full commit log: 0.5.1...0.5.2

Issues in milestone: milestone:0.5.2

Props: Weston Ruter (@westonruter), Utkarsh Patel (@PatelUtkarsh)

0.5.1 – 2016-08-23

  • Added: Pass Customize_Snapshot instance as second param to customize_snapshot_save filter. See #77.
  • Fixed: Restrict user from publishing or scheduling a snapshot unless they can customize_publish. See #74.
  • Fixed: Fix logic for when to show the snapshot publish error admin notice and show underlying error codes when there are validity errors. See #79.

See full commit log: 0.5.0...0.5.1

Issues in milestone: milestone:0.5.1

Props: Utkarsh Patel (@PatelUtkarsh), Luke Gedeon (@lgedeon), Weston Ruter (@westonruter)

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)
  • Add link in Customizer to access edit post screen. (#59)
  • Add initial read-only REST API endpoints for snapshots. (#63, #59)
  • 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 snapshot edit post screen to view snapshot applied to the frontend. (#49, #52)
  • 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)
  • Refactor codebase, including new Post_Type class. (#59)
  • Use customize_refresh_nonces filter to export snapshot nonce. (#59)
  • Eliminate generate_snapshot_uuid request by returning new UUID in saving response. (#59)
  • 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)
  • Ensuring that snapshots UI isn’t loaded if a theme switch is happening; prevent Save & Activate button from going missing. (#28, #59)
  • Ensure that get_permalink() returns the frontend URL for the site with the customize_snapshot_uuid param added.

Removed:

  • The scope parameter has been removed, as has storing non-dirty settings in a snapshot. (#59)

See full commit log: 0.4.0...0.5.0

Issues in milestone: milestone:0.5.0

Props: Weston Ruter (@westonruter), Utkarsh Patel (@PatelUtkarsh), Derek Herman (@valendesigns), Miina Sikk (@miina), Sayed Taqui (@sayedwp)

0.4.0 – 2016-06-11

Added:

  • Improved UX by removing save/update dialogs, changing the Snapshot button text to “Save” & “Update” for a more streamlined experience by removing the “full” snapshot option. (Issues #13, #42, PR #30)
  • 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.
  • New banner image and icon (Issue #24, PR #27).
  • Bumped minimum WordPress version to 4.5.

Fixed:

  • Store content in post_content instead of post_content_filtered (Issue #25, PRs #36, #43). This breaks backwards compatibility with existing snapshots.
  • Replace customize-snapshots JS dependency from customize-widgets to customize-controls (PR #14).
  • Ensure that widget actions and filters are added when previewing snapshots from the front-end (Issue #34, PR #33).
  • Use wp_slash() instead of add_magic_quotes() when loading the snapshot post vars (PR #23).
  • Update dev-lib.

See full commit log: 0.3.1...0.4.0
Issues/PRs in release: milestone:0.4.0
Props: Weston Ruter (@westonruter), Derek Herman (@valendesigns), Luke Carbis (@lukecarbis)

0.3.1

  • Fix additional WordPress VIP issues.
  • Update dev-lib.
  • Update Coveralls.

0.3.0

  • Initialize Snapshots before Widget Posts so that $wp_customize will be set on the front-end.
  • Fix WordPress VIP PHPCS issues.
  • Update dev-lib.
  • Remove unused button markup in dialog.

0.2.1

  • Fix AYS confirmation if the snapshot state is saved.
  • Register dynamic settings to ensure that snapshot settings are recognized in the post values.
  • Slash input for wp_insert_post() to prevent loss of slashes.

0.2

  • Added the customize_publish capability.
  • Separate “Save” & “Publish” buttons.

0.1.1

  • Fix widget preview.

0.1

  • Initial release.

Details

  • Version: 0.7.0
  • Active installations: 400
  • WordPress Version: 4.7
  • Tested up to: 4.9.26
  • PHP Version: 5.3

Ratings


5 Stars
4 Stars
3 Stars
2 Stars
1 Stars