Scheduled changes for the customizer

[danielbachhuber]

As a user who uses the Customizer to change the layout of my homepage (or some other non-"set it and forget it option"), I'd like to be able to make changes in the Customizer, and schedule them to go live.

Depends on #39896, #31089.

[westonruter]

I have an issue for this issue logged in the Settings Revisions plugin project: ​https://github.com/x-team/wp-settings-revisions/issues/2

[celloexpressions]

I think we would need to implement some sort of a revisions framework for the Customizer first. This would be doable for standard options and theme_mods, but could get really messy with custom setting types, and more complex implementations like Widgets and Menus.

[westonruter]

I have a working patch that adds support for scheduling Customizer settings. See #30937. The underlying mechanism for this is the proposed “Customizer transaction”. This not only facilitates scheduled settings, but it also gives us Customizer revisions.

With that patch, you can use WP-CLI to schedule a change to the blogname via:

wp post create \
    --post_type=wp_transaction \
    --post_name=$(cat /proc/sys/kernel/random/uuid) \
    --post_date_gmt="2016-01-01 00:00:00" \
    --post_status="future" \
    --post_content='{"blogname":{"value":"The 2016 Blog"},"blogdescription":{"value":"So much better than 2015!"}}'

Obviously a nicer wp transaction command abstraction would be needed, but this is a proof of concept.

[designsimply]

Just out of curiosity, what are the use cases for needing to schedule settings changes, and how common is it to want to do that?

[danielbachhuber]

what are the use cases for needing to schedule settings changes

One use case is to have a featured stories module with one to three stories. Editorial would like to be able to make changes for this module to be applied at some time in the future.

[westonruter]

Replying to designsimply:

what are the use cases for needing to schedule settings changes

Maybe you want a widget to appear in a sidebar at a specific time, or you want to change header image on Saturday at midnight, or even you want to activate a different theme at the start of the new year.

[celloexpressions]

Per the Slack conversation above, since this would involve building some UI to be usable for most people, I'd suggest waiting until after transactions land to explore it further, potentially in a future release and probably in a plugin first. Bringing in the underlying functionality with transactions, then using this ticket to make that accessible for the average user.

[westonruter]

I suggest the UI and feature be developed first in the Customize Snapshots plugin: ​https://github.com/xwp/wp-customize-snapshots/issues/15

[celloexpressions]

Let's revisit whether this is 4.6 material after the base transactions code is in core. Development in the plugin will probably be better to save for a future release.

[westonruter]

The infrastructure for this has been implemented in the patch for #30937.

To test, first do grunt patch:https://github.com/xwp/wordpress-develop/pull/161.

There is no UI as part of the patch, so to test scheduling a change to the site title in 5 minutes:

1. Change the blogname in the customizer to “Scheduled Title” and note that that a changeset_uuid query param is added to the URL.
2. Open the console and (assuming your browser timezone is the same as the blog's timezone_string):

   inOneMinute = (new Date( new Date().valueOf() + 5 * 60 * 1000 )); 
   changesetDate = inOneMinute.getFullYear() + '-' + ( '00' + ( inOneMinute.getMonth() + 1 ) ).substr( -2 ) + '-' + ( '00' + inOneMinute.getDate() ).substr( -2 ) + ' ' + ( '00' + inOneMinute.getHours() ).substr( -2 ) + ':' + ( '00' + inOneMinute.getMinutes() ).substr( -2 ) + ':' + ( '00' + inOneMinute.getSeconds() ).substr( -2 );
   wp.customize.previewer.save( { 
       status: 'future', 
       date: changesetDate
    } )
   

Update: As of WordPress 4.9 the save call should be changed to the following so that the UI reflects the new state:

wp.customize.state( 'selectedChangesetStatus' ).set( 'future' );
wp.customize.state( 'selectedChangesetDate' ).set( changesetDate );
wp.customize.previewer.save(); // Reads from state for default values.

3. Assuming that WP Cron is running properly your environment, you should see the new site title “Scheduled Title” at the designated time.

Alternatively, here is how you can schedule a change using WP-CLI without going into the customizer at all:

wp post create \
    --post_type=customize_changeset \
    --post_name=$( uuidgen ) \
    --post_status=future \
    --post_date="$( wp eval "echo get_date_from_gmt( gmdate( 'Y-m-d H:i:s', time() + 5 * 60 ) );" )" \
    --post_content='{"blogname":{ "value":"Scheduled Title"}}'

If WP Cron isn't firing, you can always wp cron event run publish_future_post

[westonruter]

In 38810:

Customize: Implement customized state persistence with changesets.

Includes infrastructure developed in the Customize Snapshots feature plugin.

See ​https://make.wordpress.org/core/2016/10/12/customize-changesets-technical-design-decisions/

Props westonruter, valendesigns, utkarshpatel, stubgo, lgedeon, ocean90, ryankienstra, mihai2u, dlh, aaroncampbell, jonathanbardo, jorbin.
See #28721.
See #31089.
Fixes #30937.
Fixes #31517.
Fixes #30028.
Fixes #23225.
Fixes #34142.
Fixes #36485.

[JoshuaWold]

Just posted some options based on a conversation last week (on the save and publish button discussion) on https://core.trac.wordpress.org/ticket/39896#comment:18

[westonruter]

Bumping priority to high for visibility and alignment with 4.9 goals, and given proximity to beta 1 deadline.

[westonruter]

In 41626:

Customize: Introduce drafting and scheduling for Customizer changesets.

• Incorporates code from the Customize Snapshots and Customize Posts feature plugins.
• Adds a new Publish Settings section for managing the changeset status, scheduled date, and frontend preview link.
• Updates Publish button to reflect the status selected in the Publish Settings (including Save Draft and Schedule).
• Deactivates the Themes section when a non-publish status selected, and deactivates the Publish Settings section when previewing a theme switch.
• Introduces an outer section type (wp.customize.OuterSection in JS) for the Publish Settings section to use and for available widgets and available nav menu panels to use in the future. These sections can be expanded while other sections are expanded.
• Introduces WP_Customize_Date_Time_Control in PHP and wp.customize.DateTimeControl in JS for managing a date/time value.
• Keeps track of scheduled time and proactively publish from the client when the time arrives, as opposed to waiting for WP Cron.
• Auto-publishes a scheduled changeset when attempting to access one that missed its schedule.
• Starts a new changeset if attempting to save a changeset that was previously publish.
• Adds force arg to requestChangesetUpdate() to force an update request even when there are no pending changes.
• Adds utils methods for getCurrentTimestamp and getRemainingTime.
• Adds new state values for selectedChangesetStatus, changesetDate, selectedChangesetDate.
• Fixes logic for when to short-circuit check to close Customizer when there are unsaved changes.
• Adds getter methods for autosaved and branching parameters, with the latter applying the customize_changeset_branching filter.
• Call to establish_loaded_changeset on the fly when changeset_uuid() is called if no changeset UUID was specififed.
• De-duplicates logic for dismissing auto-draft changesets.
• Includes unit tests.

Builds on [41597].
Props sayedwp, westonruter, melchoyce, JoshuaWold, folletto, stubgo, karmatosed, dlh, paaljoachim, afercia, johnregan3, utkarshpatel, valendesigns.
See #30937.
Fixes #39896, #28721, #39275.

[westonruter]

In 42042:

Customize: Allow 0:00-0:59 in date/time control when 24-hour time used.

• Let min hour be 0 and max be 23 in 24-hour time; let min hour be 1 and max be 12 in 12-hour time.
• Show error notification when an invalid date value is provided, not just when not a future date.
• Fix translation of custom validity message.
• Start checking for validity after all inputs have been initially populated.
• Remove support for being able to enter 24:00.
• Cease forcing date input elements from being casted to integers, to allow for invalid inputs to be detected.

Props westonruter, Presskopp, peterwilsoncc, atachibana for testing.
See #39896, #28721.
Fixes #42373.

[westonruter]

In 42109:

Customize: Always use underlying changeset post date as initial date in scheduled date fields if date is future.

Prevent user from having to re-enter the previously-supplied future date if they had switched from schedule to draft but wanted to switch back again. Improves parity with behavior of post edit screen.

Props dlh, westonruter, obenland.
See #39896, #28721.
Fixes #42413.

[westonruter]

In 42111:

Customize: Present the date/time control input fields in the same format (and order) as date_format.

Props westonruter, obenland, atachibana for testing, Mirucon for testing.
See #42373, #28721.
Fixes #42394.

[westonruter]

In 42138:

Customize: Fix reliability of just-in-time publishing for changesets that miss their schedule when visiting customize.php.

When just doing wp_publish_post() for the changeset from customize.php, any option-based settings will fail to get saved because WP_Customize_Manager would have already been loaded with settings_previewed, resulting in update_option() calls being short-circuited. So an admin-ajax request to customize_save is used to work around this.

Props westonruter, jeremyfelt, dlh for testing, LittleBigThing for testing.
Amends [41626].
See #28721, #39221.
Fixes #42457 for trunk.

[westonruter]

In 42139:

Customize: Fix reliability of just-in-time publishing for changesets that miss their schedule when visiting customize.php.

When just doing wp_publish_post() for the changeset from customize.php, any option-based settings will fail to get saved because WP_Customize_Manager would have already been loaded with settings_previewed, resulting in update_option() calls being short-circuited. So an admin-ajax request to customize_save is used to work around this.

Props westonruter, jeremyfelt, dlh for testing, LittleBigThing for testing.
Amends [41626].
See #28721, #39221.
Fixes #42457 for 4.9.

[westonruter]

In 42148:

Customize: Ensure customization drafts are published instead of trashed when scheduled changeset goes live while non-admin user is authenticated (such as during WP Cron).

Props designsimply for testing, dlh for testing, melchoyce for testing.
See #28721, #34923, #42220.
Fixes #42489 for trunk.

[westonruter]

In 42149:

Customize: Ensure customization drafts are published instead of trashed when scheduled changeset goes live while non-admin user is authenticated (such as during WP Cron).

Props designsimply for testing, dlh for testing, melchoyce for testing.
See #28721, #34923, #42220.
Fixes #42489 for 4.9.