WordPress как на ладони
Недорогой хостинг для сайтов на WordPress: wordpress.jino.ru
функция не описана

_wp_customize_publish_changeset() WP 4.7.0

Publishes a snapshot's changes.

  • Global. wpdb. $wpdb WordPress database abstraction object.
  • Global. WP_Customize_Manager. $wp_customize Customizer instance.
Хуки из функции

Ничего (null).


_wp_customize_publish_changeset( $new_status, $old_status, $changeset_post );
$new_status(строка) (обязательный)
New post status.
$old_status(строка) (обязательный)
Old post status.
$changeset_post(WP_Post) (обязательный)
Changeset post object.

Код wp customize publish changeset: wp-includes/theme.php WP 5.2.1

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 ) {

	if ( empty( $wp_customize ) ) {
		require_once ABSPATH . WPINC . '/class-wp-customize-manager.php';
		$wp_customize = new WP_Customize_Manager(
				'changeset_uuid'     => $changeset_post->post_name,
				'settings_previewed' => false,

	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' ) );

		/** 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. This 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 ) ) {
		$wp_customize->trash_changeset_post( $changeset_post->ID );