WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 2 months ago

Last modified 2 weeks ago

#28721 closed enhancement (fixed)

Scheduled changes for the customizer

Reported by: danielbachhuber Owned by: sayedwp
Milestone: 4.9 Priority: high
Severity: normal Version:
Component: Customize Keywords: needs-patch
Focuses: Cc:

Description (last modified by westonruter)

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.

Change History (31)

#1 @westonruter
3 years ago

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

#2 @celloexpressions
3 years ago

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.

#3 @westonruter
3 years ago

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.

Last edited 6 weeks ago by westonruter (previous) (diff)

#4 follow-up: @designsimply
3 years ago

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?

#5 @danielbachhuber
3 years ago

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.

#6 in reply to: ↑ 4 @westonruter
3 years ago

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.

#7 @westonruter
20 months ago

  • Milestone changed from Future Release to 4.6

This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.


19 months ago

#9 @celloexpressions
19 months ago

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.

#10 @westonruter
19 months ago

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

#11 @celloexpressions
19 months ago

  • Milestone changed from 4.6 to Future Release

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.

#12 @westonruter
14 months ago

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

Last edited 2 weeks ago by westonruter (previous) (diff)

#13 @westonruter
13 months ago

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.

This ticket was mentioned in Slack in #core-customize by westonruter. View the logs.


9 months ago

#15 @westonruter
9 months ago

  • Description modified (diff)

#16 @westonruter
5 months ago

  • Milestone changed from Future Release to 4.9

This ticket was mentioned in Slack in #core-customize by melchoyce. View the logs.


3 months ago

This ticket was mentioned in Slack in #core-customize by joshuawold. View the logs.


3 months ago

#19 @JoshuaWold
3 months ago

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

Last edited 3 months ago by JoshuaWold (previous) (diff)

This ticket was mentioned in Slack in #core by westonruter. View the logs.


3 months ago

#21 @jbpaul17
2 months ago

  • Owner set to sayedwp
  • Status changed from new to assigned

#22 @westonruter
2 months ago

  • Priority changed from normal to high

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

This ticket was mentioned in Slack in #core-customize by jeffpaul. View the logs.


2 months ago

#24 @westonruter
2 months ago

  • Resolution set to fixed
  • Status changed from assigned to closed

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.

#25 @westonruter
4 weeks ago

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.

#26 @westonruter
3 weeks ago

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.

#27 @westonruter
3 weeks ago

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.

#28 @westonruter
2 weeks ago

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.

#29 @westonruter
2 weeks ago

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.

#30 @westonruter
2 weeks ago

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.

#31 @westonruter
2 weeks ago

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.

Note: See TracTickets for help on using tickets.