[wp-trac] [WordPress Trac] #42457: Scheduled changeset won't publish if Customizer is opened first after missing schedule

[WordPress Trac]

#42457: Scheduled changeset won't publish if Customizer is opened first after
missing schedule
-------------------------------------+------------------
 Reporter:  LittleBigThing           |       Owner:
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  4.9
Component:  Customize                |     Version:  4.9
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:
-------------------------------------+------------------
Changes (by westonruter):

 * keywords:   => has-patch needs-testing
 * milestone:  Awaiting Review => 4.9


Comment:

 I can reproduce this. For anyone who wants to test, it is particularly
 helpful to add `define( 'DISABLE_WP_CRON', true );` to your `wp-
 config.php`.

 The problem is that `wp_publish_post( $changeset_post->ID )` is getting in
 `customize.php` called //after// the settings have already been previewed
 (after the filters have been added to apply the changeset's values to
 WordPress). In the case of options particularly, calls to
 `update_option()` will short-circuit if the value being updated is the
 same value that it finds when doing a `get_option()` call. Since the
 filters would be supplying the changeset's previewed value at that point,
 then none of the options would get saved because `update_option()` would
 short-circuit for each one. This problem is what we introduced the
 `settings_previewed` arg for in #39221. However, in `customize.php` this
 argument is not set to `false` like it is in
 `_wp_customize_publish_changeset()` which is normally called when WP Cron
 publishes a scheduled changeset.

 So the fix here in [attachment:42457.0.diff] is simply to replace the call
 to `wp_publish_post()` with a call to `spawn_cron()`. This will result in
 a loopback request to `wp-cron.php` being opened up, and in that request
 `WP_Customize_Manager` will not be instantiated with
 `settings_previewed=true`, allowing option settings to be saved
 successfully.

 I noticed that all of the settings you described failing to save were in
 fact of the `option` type. So that confirms my suspicion.

 @LittleBigThing Please test the patch.

 This may be the same issue as reported at
 https://wordpress.org/support/topic/beta-v4-9-twenty-seventeen-does-not-
 make-any-scheduled-changes-to-customizer/

--
Ticket URL: <https://core.trac.wordpress.org/ticket/42457#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform