Allow a snapshot to be scheduled

[westonruter]

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.

[westonruter]

See also the ability to split up a snapshot into multiple: #16

[westonruter]

@valendesigns here is the code from the transactions PR for handling the publishing of a transaction post: https://github.com/xwp/wordpress-develop/blob/97fd5019c488a0713d34b517bdbff67c62c48a5d/src/wp-includes/theme.php#L2071-L2120

For snapshots I suppose this logic would have to be short-circuited if customize_save is happening already. It would be only done if the snapshot post is being published by the user in the WP admin or if WP Cron is transitioning the future-snapshot to publish. See https://github.com/xwp/wordpress-develop/blob/97fd5019c488a0713d34b517bdbff67c62c48a5d/src/wp-includes/class-wp-customize-transaction.php#L366-L372

[westonruter]

There may need to be a “Snapshots” Customizer section that contains the fields for the future published date. This section could also contain a UI for selecting another snapshot to load, and also to provide a name for the snapshot (commit message), as in #19.

See also the (defunct) Settings Revisions plugin:

Nevertheless, I think it would be ideal if the controls for managing the snapshot remained in the header bar since they should be more meta.

[valendesigns]

The issue I see with using the header bar is that switching could be problematic in the small amount of real estate we have up there. I guess we could have an edit button that opens a dialog which allows naming and switching? Or using a key event like control+click or similar.

[westonruter]

Note regarding calling $setting->save() during publishing: since the snapshot could have settings added to it from multiple users who don't all have the capability to modify each other's settings, or especially in the case of WP Cron transitioning a snapshot's status to publish, it will be important to ensure that during the routing for loading the snapshot to save all settings, that a filter be added for user_has_cap to grant everything so that every setting will be able to be saved.

[westonruter]

Actually, I'm wrong about having to grant all caps during the save process. All we have to do is grant a cap that everyone has to all of the settings, and all of the settings will then be able to be saved. For example:

foreach ( $settings as $setting ) {
    $setting->capability = 'exist';
}
foreach ( $settings as $setting ) {
    $setting->save();
}

I loop over the settings first to set the capability in case there is a setting being saved that has a dependency, and thus tries to save the dependency before it gets saved.