WordPress Version: 4.7
/**
* Publish a snapshot's changes.
*
* @param string $new_status New post status.
* @param string $old_status Old post status.
* @param WP_Post $changeset_post Changeset post object.
*/
function _wp_customize_publish_changeset($new_status, $old_status, $changeset_post)
{
global $wp_customize, $wpdb;
$is_publishing_changeset = 'customize_changeset' === $changeset_post->post_type && 'publish' === $new_status && 'publish' !== $old_status;
if (!$is_publishing_changeset) {
return;
}
if (empty($wp_customize)) {
require_once ABSPATH . WPINC . '/class-wp-customize-manager.php';
$wp_customize = new WP_Customize_Manager(array('changeset_uuid' => $changeset_post->post_name));
}
if (!did_action('customize_register')) {
/*
* When running from CLI or Cron, the customize_register action will need
* to be triggered in order for core, themes, and plugins to register their
* settings. Normally core will add_action( 'customize_register' ) at
* priority 10 to register the core settings, and if any themes/plugins
* also add_action( 'customize_register' ) at the same priority, they
* will have a $wp_customize with those settings registered since they
* call add_action() afterward, normally. However, when manually doing
* the customize_register action after the setup_theme, then the order
* will be reversed for two actions added at priority 10, resulting in
* the core settings no longer being available as expected to themes/plugins.
* So the following manually calls the method that registers the core
* settings up front before doing the action.
*/
remove_action('customize_register', array($wp_customize, 'register_controls'));
$wp_customize->register_controls();
/** This filter is documented in /wp-includes/class-wp-customize-manager.php */
do_action('customize_register', $wp_customize);
}
$wp_customize->_publish_changeset_values($changeset_post->ID);
/*
* Trash the changeset post if revisions are not enabled. Unpublished
* changesets by default get garbage collected due to the auto-draft status.
* When a changeset post is published, however, it would no longer get cleaned
* out. Ths is a problem when the changeset posts are never displayed anywhere,
* since they would just be endlessly piling up. So here we use the revisions
* feature to indicate whether or not a published changeset should get trashed
* and thus garbage collected.
*/
if (!wp_revisions_enabled($changeset_post)) {
$post = $changeset_post;
$post_id = $changeset_post->ID;
/*
* The following re-formulates the logic from wp_trash_post() as done in
* wp_publish_post(). The reason for bypassing wp_trash_post() is that it
* will mutate the the post_content and the post_name when they should be
* untouched.
*/
if (!EMPTY_TRASH_DAYS) {
wp_delete_post($post_id, true);
} else {
/** This action is documented in wp-includes/post.php */
do_action('wp_trash_post', $post_id);
add_post_meta($post_id, '_wp_trash_meta_status', $post->post_status);
add_post_meta($post_id, '_wp_trash_meta_time', time());
$old_status = $post->post_status;
$new_status = 'trash';
$wpdb->update($wpdb->posts, array('post_status' => $new_status), array('ID' => $post->ID));
clean_post_cache($post->ID);
$post->post_status = $new_status;
wp_transition_post_status($new_status, $old_status, $post);
/** This action is documented in wp-includes/post.php */
do_action('edit_post', $post->ID, $post);
/** This action is documented in wp-includes/post.php */
do_action("save_post_{$post->post_type}", $post->ID, $post, true);
/** This action is documented in wp-includes/post.php */
do_action('save_post', $post->ID, $post, true);
/** This action is documented in wp-includes/post.php */
do_action('wp_insert_post', $post->ID, $post, true);
/** This action is documented in wp-includes/post.php */
do_action('trashed_post', $post_id);
}
}
}