xwp/wp-customize-snapshots

Customize Snapshots WordPress Plugin

Customize Snapshots

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

Contributors: xwp, westonruter, valendesigns, utkarshpatel, sayedwp, newscorpau
Tags: customizer, customize, changesets
Requires at least: 4.7
Tested up to: 4.9
Stable tag: 0.7.0
License: GPLv2 or later
Requires PHP: 5.3

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.

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.

wp-customize-snapshots's Issues

Store snapshot data in post_content instead of post_content_filtered

Follow pattern of Customize Widgets Plus in how data is stored for widget_instance posts.

Preview future scheduled snapshots

With snapshots being scheduled (#15) there could be multiple snapshots that will have been applied by a given time. There needs to be a way to be able to indicate a future time and preview how the site will appear with all of the future-scheduled snapshots merged together, in order, and applied to the Customizer state.

Allow a snapshot to be reverted

Before a snapshot is published (before its settings are saved), we should store the non-previewed values for the settings that are being overridden. These can be stored in the snapshot's meta. With this data available, we would be able to

Allow snapshots to store the previous state overridden for each setting saved. When viewing a snapshot that has been published, this pre-applied setting data could be shown in the diff view (see #18) instead of the current live settings.

When a snapshot has reversion data available, a button should be available from the edit post screen (#18) to revert the snapshot.

Add link in snapshot edit post screen to view frontend with snapshot applied

In addition to the “Edit in Customizer” button there should be a button/link to view the snapshot on the frontend.

See also #47 for ensuring the links on the frontend include the snapshot UUID when browsing around the site.

Usage clarifications

Hello,

I'm trying to figure it out, in what way your plugin can be useful in my case.

We create themes for ThemeForest. As you might know, themes on ThemeForest have demos. Basically a demo is a set of Customizer theme_mods. We currently override them via a filter, depending on a $_GET parameter.

It would be so much easier if we could control demos as snapshots and create public URLs with page slugs like /home-1.

Is there a way I can achieve anything like that with WP Customize Snapshots?

Thanks!

Add edit post screen for viewing a snapshot's settings

With #12 there would be a list of the available snapshots in the WP Admin post list table. When clicking on a snapshot to access its edit post screen, the settings inside of the snapshot can be listed, along with the values for each. We could also show the current saved values along with the setting values from the snapshot to show a kind of diff view.

Also allow settings to be deleted from a snapshot: #17.

The list of settings in a given snapshot can also be listed from the post list table (#12) when the posts are in expanded view.

Disable editing slug from Quick Edit

Currently the slug of a Snapshot is editable from the Quick Edit action link on wp-admin/edit.php?post_type=customize_snapshot page. Since it's the UUID, it shouldn't be editable.

Remember the preview URL and expanded panel/section when saving a changeset

When a changeset is made, often the changes specifically relate to a given URL and with a specific panel, section, and control being expanded. It would be ideal if whenever a changeset is saved, that we pass along the current previewUrl and any expanded panel/section/control so that these params can then be used in the links generated for “Edit in Customizer” and “Preview SnapshotChangeset” as the url and autofocus params respectively.

This closely relates to Customizer Browser History, and this would greatly help with returning to work on a changeset after saving.

Add UI for listing and accessing current snapshots

The custom post type for snapshots should be exposed in the admin so that the existing snapshots can be listed, with links to view them on the frontend or open them in the Customizer. Viewing the edit post screen for a snapshot could show a JSON dump of the settings in the snapshot.

Make attachments atomic until a transaction is published

Current behavior

When you upload attachments via the Customizer they are:

1. Added to the filesystem.
2. Saved to the database as a new post.
3. Immediately visible to all other logged in users in the Media Library.

Desired behavior

Attachments that are uploaded within a Customizer session should not be published, or even visible by other logged in users, until the user decides to publish the transaction.

Possible idea

Until a transaction is published, all attachment posts that have been uploaded inside the Customizer have their post status set to auto-draft rather than inherit. This will make them invisible inside the Media Library from other logged in users.

All attachment posts uploaded while in the Customizer can be stored somehow inside the transaction.

"attachments": {
    "value": [12,13,14]
}

Disclaimer: I'm not at all familiar with the schema, so this is probably wrong, but hopefully the concept makes sense.

If you are in the Customizer session, perhaps pre_get_posts could be used to allow these attachment IDs to be visible in the Media Library just for you?

Publish or Discard

If a transaction is published, then the post status on these attachment IDs can be set to inherit, making them visible inside in the Media Library like normal.

If a transaction is discarded, then the attachment IDs can be force deleted via wp_delete_attachment( $ID, true ) which will not only delete them from the database, but also from the filesystem.

Multisite migration from snapshot to changeset for WP 4.7

#102 covers migration for normal WP site, it does not cover multisite migration.

Save & Activate button is missing

When doing a live preview of a theme switch, the Save & Activate button is hidden entirely.

Allow a snapshot to be scheduled

This would implement https://core.trac.wordpress.org/ticket/28721

A snapshot should be scheduleable from the the Customizer via something like a “Schedule” button along with a timestamp for when it should apply.

If there is also an edit post screen for viewing a snapshot in the admin ( #18), the snapshot should also be able to be scheduled using the traditional post scheduling functionality.

Customize from within Snapshot view fails to load the correct page inside Customizer

Steps to reproduce:

• customize a page
• hit save
• click on "view on frontend"
• from this page click "Customize"

Issue:
Although the customized page options are loaded correctly in the sidebar, the iframe content does not reflect the contents of that page.

http://contribute-wp.kbox.site/wp-admin/customize.php?url=http%3A%2F%2Fcontribute-wp.kbox.site%2F%3Fpreview%3Dtrue&page_id=13&autofocus%5Bsection%5D=post%5Bpage%5D%5B13%5D&customize_snapshot_uuid=09db72ba-2750-4ace-8008-71579beb2f66

I URL decoded the parameter passed to customize.php for easier reading:
http://contribute-wp.kbox.site/?preview=true&page_id=13&autofocus[section]=post[page][13]&customize_snapshot_uuid=09db72ba-2750-4ace-8008-71579beb2f66

Video of the issue: https://shrtm.nu/plho

PHP 5.3 will fail the build

5.3 isn't actually broken, the issue is with PHPCS complaining about a vendor file. Once that's fixed we can move it out of the allow_failures section. I'm going to have to assume that excluding */vendor/* is not doing the job.

No syntax errors detected in vendor/psr/log/Psr/Log/LoggerAwareInterface.php
PHP Parse error:  syntax error, unexpected T_STRING in vendor/psr/log/Psr/Log/LoggerAwareTrait.php on line 8
Parse error: syntax error, unexpected T_STRING in vendor/psr/log/Psr/Log/LoggerAwareTrait.php on line 8
Errors parsing vendor/psr/log/Psr/Log/LoggerAwareTrait.php

Important to note that this is something that only happens when you add Coveralls support.

Ensure that widget actions and filters get added for previewing snapshots for unauthenticated users

The constructor for WP_Customize_Widgets has this bit of code before it does the add_action() and add_filter() calls:

// Skip useless hooks when the user can't manage widgets anyway.
if ( ! current_user_can( 'edit_theme_options' ) ) {
    return;
}

This will cause a problem for previewing widgets on the frontend for unauthenticated users because these filters/actions aren't getting added: https://github.com/xwp/wordpress-develop/blob/885d38edc8de04c3cf7baced5ef0effc8c5a6bd6/src/wp-includes/class-wp-customize-widgets.php#L101-L120

Snapshots should be adding these filters and actions (as required) if ! has_filter() or ! has_action().

Allow multiple snapshots to be merged into a single snapshot

Inverse of #16.

Probably should create a new snapshot post post that contains the merged settings from the other snapshots. We could use bulk actions to implement this.

Allow a snapshot to be copied/forked

New Menus are not being saved to the correct location when you publish a snapshot

The menu is being created when the snapshots is published. However, Menu locations is not getting checked or updated in the dropdown. Not sure if we need to handle this with JS using something like wp.customize.bind( 'saved', function () { ... } ) or there is an issue with the data being passed to customized.

Unauthenticated user unable to view a customize-draft post via REST API

1. Create a new post via Customize Posts, giving it a publish status, but do not Publish
2. Click Save.
3. Make a request to via the REST API for the post, such as at http://vvv.example.com/wp-json/wp/v2/foods/159?customize_snapshot_uuid=ed6cb1bd-00c4-4927-8ae2-c98f257478f7
4. Fail: {"code":"rest_forbidden","message":"You don't have permission to do this.","data":{"status":403}}. It was expected that since the snapshot UUID was present, that the publish status in the snapshot would have allowed the post to be accessed.

The issue is in \WP_REST_Posts_Controller::check_read_permission(), specifically:

       // Can we read the post?
        if ( 'publish' === $post->post_status || current_user_can( $post_type->cap->read_post, $post->ID ) ) {
            return true;
        }

It seems the fix for this is to add user_has_cap filter to explicitly grant read_post capability for a post that is modified in the snapshot to have a status whereby the requesting user would be able to view it.

Handle case where user lacking some setting caps loads a snapshot into the Customizer

If a snapshot is saved that contains modified settings that require edit_theme_options and yet a user opens this snapshot in the Customizer and they lack this capability, the setting will effectively get dropped from the snapshot if they try saving. I see two options here:

• Block a user from being able to load a snapshot when they lack all caps for the settings in it.
• When a user with insufficient caps saves settings that are coming from a snapshot, ensure that all settings from the snapshot get loaded and forcibly saved along with the settings the user actually submitted in the request.

The first option would be easier and would be more expected.

Meta: Add plugin header image and icons

As was done for Customize Posts: xwp/wp-customize-posts#112

Move “View on Frontend” link to customize-footer-actions; make persistent

In the plugin right now, a “View on Frontend” link/button appears in the customize-header-actions whenever the snapshot is saved. With changesets, however, the state is saved at AUTOSAVE_INTERVAL and it is saved whenever focus on the window is removed. In short, the changeset can be considered to be saved at any time and not require a proactive Save. Because of this, the “View on Frontend” link can be persistent and not only show up when the changeset is saved. Also, I think it makes more sense for this link to be on the bottom next to Collapse (Hide Controls) and the device preview buttons, since really this is just another way to preview the changes. Maybe it could be added along with the device preview buttons but with an external dashicon.

Here is the logic for opening the frontend URL in a new window on demand:

var urlParser = document.createElement( 'a' );
urlParser.href = previewFrame.previewUrl();

params = _.extend(
	api.utils.parseQueryString( urlParser.search.substr( 1 ) ),
	{
		customize_changeset_uuid: previewFrame.query.customize_changeset_uuid,
		customize_theme: previewFrame.query.customize_theme
	}
);
urlParser.search = $.param( params );

onceProcessingComplete = function() {
	var request;
	if ( api.state( 'processing' ).get() > 0 ) {
		return;
	}

	api.state( 'processing' ).unbind( onceProcessingComplete );

	request = api.requestChangesetUpdate();
	request.done( function() {
		window.open( urlParser.href ); // <= Open the frontend URL in a new window.
	} );
};

if ( 0 === api.state( 'processing' ).get() ) {
	onceProcessingComplete();
} else {
	api.state( 'processing' ).bind( onceProcessingComplete );
}

Add ability to create & update snapshots via REST API

To build upon #63.

• Allow snapshot posts to be created and updated, ensuring that content is in the proper format as an object mapping setting IDs to setting params.
• Prevent editing of slug, since the UUID should never change.
• Add support for PATCH updates.
• Consider using REST API endpoints in Customizer when saving/updating snapshots.
• (optional) Add endpoints that use UUID instead of post ID. We really don't need regular post IDs since snapshots have UUIDs. Really a random PUT request could be made to create a snapshot if it just supplies a proper UUID.

Extend, integrate with and defer to changesets in WP 4.7

This is an important issue to complete before the 4.7 release in December.

The underlying architecture in snapshots was committed to core in WordPress 4.7-alpha. As such, the redundant code in snapshots should be only run if on 4.6 or less. All of the redundant code should be extracted into one or more back-compat classes.

Also, now that the post type is customize_changeset as opposed to customize_snapshot, there should be a data migration strategy. Also, any filters that apply on customize_snapshot_save should also apply onto customize_changeset_save_data.

Whenever a $_REQUEST['customize_snapshot_uuid'] is present we should during plugins_loaded make sure this gets mapped over to customize_changeset_uuid in $_GET, $_POST, and $_REQUEST.

In the end, the plugin should be reformulated to anticipate that more and more of the features of the plugin will be incorporated into core. So the more that we can facilitate turning off aspects of the code that are already in core, the better.

Add admin bar link to view snapshot edit post screen

In addition to the Customize link opening the snapshot in the Customizer, there should also be an easy way to access the Snapshot edit post screen from the frontend, if browsing the site in a snapshot state (see #47).

Facilitate users concurrently editing a snapshot

If two users edit the same snapshot, there is currently the real possibility that users will override each other's changes. There needs to be concurrency support for snapshots. When this happens, the snapshot save should be rejected as a validation failure, with a prompt to resolve the conflict, by accepting their changes or overriding the changes with their own.

We need to keep track of the settings that have been changed since the last snapshot save and send it along with the snapshot save request. See approach for keeping track of settings changed: https://github.com/xwp/wordpress-develop/blob/a501d6c8be242dce7bcff0e14b145953057ff7ba/src/wp-admin/js/customize-controls.js#L3685-L3688

Whenever a value is updated in a snapshot, beyond storing the setting value we can also store the timestamp for when the setting was updated and also the user ID who actually saved it.

Other general notes on concurrency locking in general:

• Validation is an important way that we can solve concurrency problems.
• Use heartbeat to announce that a setting has changed, and allow the value to be supplied from the other user
• Send locking overrides via separate channel than customized data, since modified date hack won't work for other kinds of settings

Disable AYS dialog if no settings modified after saving snapshot

If I hit “Save” or “Save Draft” and then exit the Customizer, I should not be presented with the AYS dialog:

Inject Customizer state into Ajax requests

This goes hand-in-hand with #47. In order to preview sites that use a lot of JS and Ajax requests, the requests need to be Customzier-aware. We can accomplish this via jQuery Ajax prefilter. If on the frontend, we only need to inject the customzie_snapshot_uuid query param. In the Customizer Preview, we'll need to rewrite the requests to be POST and ensure the Customzier query vars are included: this has been demonstrated to work for the WP REST API, but it will not work in all cases. See implementation from Customize REST Resources which can be lifted: https://github.com/xwp/wp-customize-rest-resources/blob/84405f4312e22e956e86b6d17f0791d64e8de372/js/rest-resources-manager.js#L208-L265

Eliminate storage of non-dirty settings

I think I know why I was having environment problems yesterday. I think it was because I had so many settings loaded into the Customizer (278) and many of the settings were large being post settings with potentially very large post_content. I just looked at a snapshot I made and I calculated its size at 76,170 bytes (via wp post get 305 --field=post_content | wc -c). This is large. The post_content field is a LONGTEXT in MySQL which means it can store a snapshot post_content that is 56,386 times larger. Nevertheless, this is a ton of data to be passing back and forth with each snapshot update, and it could get is into trouble with timeouts and network latency.

I think we should perhaps remove the full scope from being a feature for the sake of scalability. With the UX changes in #30 it's not even an option anymore in the UI, and I think that it has always been a bit dubious in its usefulness. Thoughts?

Publishing changes without first updating a snapshot causes unexpected behavior

Steps to reproduce:

1. Change site title.
2. Save snapshot (to create one).
3. Change title again.
4. Publish changes (without updating snapshot)

Bug: Snapshot Update button is not disabled and is not reverted back to Save.
Bug: Clicking Update causes an error modal to appear: “The snapshot could not be saved.”

Filter snapshot excerpt to be list of (dirty) setting IDs

This would be useful for giving a preview for what is contained in the snapshot from the list table:

See also #42.

Add demo video to readme

Example: https://github.com/xwp/stream/blob/1a32d57837011dfec73df634960c4260fd649143/readme.txt#L14

Show conflicts arising with scheduled snapshots

When making a change in the Customizer or making a new snapshot, if there is currently one or more scheduled snapshots that touch on a setting that is dirty in the current state, there should be a warning to note of a potential conflict.

See also previewing future scheduled snapshots: #15 & #21

Show list of changes (dirty settings) in Customizer

Just as we have a UI for showing the settings inside of a snapshot when in the WP admin, this same kind of interface should be available when you are inside the Customizer. There can be a dialog that shows all of the changes, this UI could also provide a way for you to revert an individual change back to the setting's original value. If we mark it as not _dirty, we may need to take care with #60, as you'd not be able to remove a setting from a snapshot as you might expect in that interface, so there may need to be an additional list of setting IDs passed when saving a snapshot for settings that should be reverted (removed from snapshot), just as for concurrency conflict resolution we may need to pass a list of setting IDs that should override any conflicts.

Add support for translations with load_plugin_textdomain

As well, add the Grunt tasks that connect with Transifex for auto generating language files during the build task. Using this service will allow the community to translate the plugin without creating pull requests.

• Transifex project & Grunt task
• Integrate load_plugin_textdomain

Allow settings to be deleted from a snapshot

Given a UI for listing out the available snapshots in the WP Admin (#12), if opening a snapshot in its edit post screen (see also #16), there could be a listing of the settings in that snapshot along with checkboxes that when checked, a button could be clicked to remove them from the snapshot.

Consider adding Publish button to admin bar when previewing changeset

When previewing a changeset on the frontend and the Admin Bar is present, in addition to there being a Customize link to allow you to enter the customizer to make changes, there could also be a Publish button that would allow you to make the changes live right there. This would tie into a frontend editing experience for the customizer, where a user could start a frontend customizer session by clicking Customize which could then bootstrap customize-preview.js and start a new changeset, with inline editing of elements, floating controls, heavily relying on selective refresh (exclusively) to make changes. A user could then navigate around the site on the frontend as normal, with the changeset state persisting, and then once they are happy with the changes they can go live. Anyway, adding a Publish link/button to the admin bar is one part of this.

Clear up distinction between previewing vs saving values in a snapshot

There seems to be somewhat of a gray area in Customize Snapshots, and in the Customizer in general for previewing vs saving values. In the Customize Snapshots plugin the can_preview method is used for both of these conditions, it seems going for the save check by seeing if is_admin(). I think perhaps they should be separated out a but more to make it more black and white?

diff --git a/php/class-customize-snapshot-manager.php b/php/class-customize-snapshot-manager.php
index dab955d..0c1208d 100644
--- a/php/class-customize-snapshot-manager.php
+++ b/php/class-customize-snapshot-manager.php
@@ -305,7 +305,7 @@ class Customize_Snapshot_Manager {
        }

        foreach ( $this->customize_manager->settings() as $setting ) {
-           if ( $this->can_preview( $setting, $this->unsanitized_snapshot_post_data ) ) {
+           if ( $this->can_preview( $setting, $this->unsanitized_snapshot_post_data ) && $setting->check_capabilities() ) {
                $post_data = $this->unsanitized_snapshot_post_data[ $setting->id ];
                $this->snapshot->set( $setting, $post_data['value'], $post_data['dirty'] );
            }
@@ -518,9 +518,6 @@ class Customize_Snapshot_Manager {
        if ( ! ( $setting instanceof \WP_Customize_Setting ) ) {
            return false;
        }
-       if ( ! $setting->check_capabilities() && is_admin() ) {
-           return false;
-       }
        if ( ! array_key_exists( $setting->id, $values ) ) {
            return false;
        }
@@ -538,7 +535,7 @@ class Customize_Snapshot_Manager {
            $this->customize_manager->add_dynamic_settings( array_keys( $values ) );

            foreach ( $this->snapshot->settings() as $setting ) {
-               if ( $this->can_preview( $setting, $values ) ) {
+               if ( $this->can_preview( $setting, $values ) && $setting->check_capabilities() ) {
                    $this->customize_manager->set_post_value( $setting->id, $values[ $setting->id ] );
                }
            }

I think maybe the can_preview method should be removed entirely?

diff --git a/php/class-customize-snapshot-manager.php b/php/class-customize-snapshot-manager.php
index dab955d..6ef1a7d 100644
--- a/php/class-customize-snapshot-manager.php
+++ b/php/class-customize-snapshot-manager.php
@@ -305,7 +305,7 @@ class Customize_Snapshot_Manager {
        }

        foreach ( $this->customize_manager->settings() as $setting ) {
-           if ( $this->can_preview( $setting, $this->unsanitized_snapshot_post_data ) ) {
+           if ( array_key_exists( $setting->id, $this->unsanitized_snapshot_post_data ) && $setting->check_capabilities() ) {
                $post_data = $this->unsanitized_snapshot_post_data[ $setting->id ];
                $this->snapshot->set( $setting, $post_data['value'], $post_data['dirty'] );
            }
@@ -508,26 +508,6 @@ class Customize_Snapshot_Manager {
    }

    /**
-    * Check if the setting can be previewed.
-    *
-    * @param \WP_Customize_Setting $setting A WP_Customize_Setting derived object.
-    * @param array                 $values  All settings' values in the snapshot.
-    * @return bool
-    */
-   public function can_preview( $setting, $values ) {
-       if ( ! ( $setting instanceof \WP_Customize_Setting ) ) {
-           return false;
-       }
-       if ( ! $setting->check_capabilities() && is_admin() ) {
-           return false;
-       }
-       if ( ! array_key_exists( $setting->id, $values ) ) {
-           return false;
-       }
-       return true;
-   }
-
-   /**
     * Set the snapshot settings post value.
     */
    public function set_post_values() {
@@ -538,7 +518,7 @@ class Customize_Snapshot_Manager {
            $this->customize_manager->add_dynamic_settings( array_keys( $values ) );

            foreach ( $this->snapshot->settings() as $setting ) {
-               if ( $this->can_preview( $setting, $values ) ) {
+               if ( $setting->check_capabilities() ) {
                    $this->customize_manager->set_post_value( $setting->id, $values[ $setting->id ] );
                }
            }
@@ -566,7 +546,8 @@ class Customize_Snapshot_Manager {
                $values = $this->snapshot->values();

                foreach ( $this->snapshot->settings() as $setting ) {
-                   if ( $this->can_preview( $setting, $values ) ) {
+                   $is_dirty = array_key_exists( $setting->id, $values );
+                   if ( $is_dirty ) {
                        $setting->preview();
                        $setting->dirty = true;
                    }

Exception thrown when attempting to activate plugin on windows environment

Can't activate the plugin due to a fatal error.
Tested on two different websites, on WP 4.7 and on the previous WP version.

Fail updating a snapshot if any of the setting values are invalid

Add support for https://core.trac.wordpress.org/ticket/34893

Published snapshot UUID can persist in the customizer exit link

Steps to reproduce:

1. Open customizer
2. Change a setting (e.g. site title)
3. Save snapshot
4. Click to view the snapshot on the frontend:
   
5. On the frontend preview, click Customize in the admin bar:
6. Publish changes.
7. Click ✖️ to close the customizer.

BUG: The snapshot UUID for the published snapshot appears in the URL. It should be stripped when the customizer changes are published.

Toggle between snapshot and live mode

Instead of presenting two buttons one of which (publish) could have disastrous results on a live site, could we instead have a toggle that let's you switch between snapshot and live mode?

We could default to snapshot mode which would have a schedule option and even a button for opening a previous snapshot to continue work.

If you switch to live mode, then the publish button replaces the save button. This would make it more obvious to a user that "Oh, if I click publish now, this change is going live!"

This also gives a visual cue that you are in snapshot mode which will provide some peace of mind which, based recent user testing, would be really helpful.

Expose snapshots in REST API

The snapshot posts should be available via the REST API, including the UUID for each snapshot and its contents. Accessing snapshots would require customize capability at least, and potentially the capability for each setting contained in the snapshot.

This should include a collection param for filtering snapshots that are authored by a given user ID.

Relates to #12

Snapshot UUID should be stripped from the URL and JS state once published

Once a snapshot is published, it should be considered frozen and a new one should be started. By stripping the UUID from the URL, this will help ensure that a user doesn't inadvertently go back to a snapshotted Customizer and not get the latest changes to modify.

Allow a snapshot to be split up into multiple snapshots

If a subset of changes from a snapshot need to be isolated into a separate snapshot, such as scheduling out a subset of settings ahead of other settings being applied, we should be able to split up a snapshot into multiple snapshots.

Given the UI for listing out the available snapshots (#12), a user could open a snapshot in an edit post screen, and from there the list of settings in the snapshot could be listed. Along with each setting there could be a checkbox to allow it to be selected, with a button then for taking the selected settings and moving them into a separate snapshot.

Filter all of generated links to include the snapshot UUID if present in the request

When viewing the frontend of the site, clicking around should preserve the snapshot state as much as possible.

See https://github.com/xwp/wordpress-develop/pull/61/files#diff-4fb8a477f559bdfad2c1e6db6d1c8b06R887

Snapshot confirmation dialog model is not user friendly

During QA, this was reported:

Test steps

1. Navigate to site and login as admin
2. View home page and click Customize to navigate to Customizer
3. Make a change (ie. to the logo) in customizer and click [save]
4. View Save Dialog Box

Expected
The user will be able to easily preview and save a ‘draft’ of their edits and understand the options

Actual
On clicking to ‘Save’ the changes in customizer a dialog displays with 2 options for Preview scope:
(.) diff - Previews the dirty settings
( ) full - Previews all the settings

It is not clear to me (or I suspect most users) what those options mean? Is a choice required here and if not, why give the user the choice?

Create a snapshot with every Customize save if no snapshot is present

This will ensure that there is revision history in the Customizer: https://core.trac.wordpress.org/ticket/31089

And it will allow any change saved in the Customizer to be rolled back: #20

Allow snapshots to be named

When listing snapshots in the admin (#12), the snapshots should be shown with a given name to easily identify what is contained in the snapshot (this would be beyond any settings listed below the snapshot when expanded, as mentioned in #18).

In addition to a name, we could make use of the post_excerpt to capture a “commit message” for a given snapshot.

Alternatively, we could just use the post title as the commit message and not have a separate name field at all.