diff --git src/wp-admin/customize.php src/wp-admin/customize.php
index 7f9e5a9dc7..dd67d1bc3b 100644
|
|
if ( $wp_customize->changeset_post_id() ) { |
42 | 42 | get_post_time( 'G', true, $changeset_post ) < time() |
43 | 43 | ); |
44 | 44 | if ( $missed_schedule ) { |
45 | | wp_publish_post( $changeset_post->ID ); |
| 45 | /* |
| 46 | * Note that cron is spawned here instead of just calling `wp_publish_post( $changeset_post->ID )`. |
| 47 | * The reason for this is that WP_Customize_Manager is not instantiated for customize.php with |
| 48 | * the `settings_previewed=false` argument. Because of this, settings cannot by reliably saved just |
| 49 | * since some settings will short-circuit if they detect that the current value is the same as |
| 50 | * the value to be saved. This is particularly true for options due to logic in the update_option() |
| 51 | * function. For more, See #39221. So by spawning cron, then the changeset will get published in |
| 52 | * the request to `wp-cron.php` where WP_Customize_Manager will get instantiated with |
| 53 | * `settings_previewed=false` according to `_wp_customize_publish_changeset()`. |
| 54 | */ |
| 55 | spawn_cron(); |
| 56 | |
46 | 57 | wp_die( |
47 | 58 | '<h1>' . __( 'Your scheduled changes just published' ) . '</h1>' . |
48 | 59 | '<p><a href="' . esc_url( remove_query_arg( 'changeset_uuid' ) ) . '">' . __( 'Customize New Changes' ) . '</a></p>', |