_wp_customize_publish_changeset( string $new_status, string $old_status, WP_Post $changeset_post )

Parameters

$new_statusstring

New post status.

$old_statusstring

Old post status.

$changeset_postWP_Post

Changeset post object.

Cost profile

Measured from the compiled opcodes, not from a stopwatch. Every number here is identical on any machine that runs the same PHP version, and every function in core is ranked by these figures.

Cost class

Trivial

Touches nothing outside its own arguments.

Scaling

Constant

No loop in the body: the same number of instructions runs whatever you pass in.

Instructions

10–57

Executed per call on PHP 8.4, depending on the branch taken. The body compiles to 58.

Plugin surface

1 hook

Third-party callbacks on 'customize_register' run inside this call, and their cost is not bounded by anything here.

Called by

0

Nothing in core calls this; the cost is only what you spend yourself.

What it touches

• hookthird-party callbacksdo_action()called directly

What one call costs · 9 distinct outcomes

One number would be a lie: the work depends on which branch runs. These are every distinct cost _wp_customize_publish_changeset() can have, taken from its control-flow graph on PHP 8.4.

Across PHP versions

Oldest PHP that compiles this body: 7.4. An instruction is not a fixed amount of time, so a version with the same count is not necessarily the same speed; what the count rules out is a difference in the work itself.

Hooks fired · 1

One hook fires while _wp_customize_publish_changeset() runs, in this order:

1. 1
   do_action( customize_register )actionline 3682 (+43 into the body)

   Fires once WordPress has loaded, allowing scripts and styles to be initialized.

Uses · 5

• did_action()Retrieves the number of times an action has been fired during the current request.
• remove_action()Removes a callback function from an action hook.
• do_action()Calls the callback functions that have been added to an action hook.
• wp_revisions_enabled()Determines whether revisions are enabled for a given post.
• WP_Customize_Manager::__construct()Constructor.

Source

View on Trac ↗View on GitHub ↗

3639function _wp_customize_publish_changeset( $new_status, $old_status, $changeset_post ) {3640	global $wp_customize;3641 3642	$is_publishing_changeset = (3643		'customize_changeset' === $changeset_post->post_type3644		&&3645		'publish' === $new_status3646		&&3647		'publish' !== $old_status3648	);3649	if ( ! $is_publishing_changeset ) {3650		return;3651	}3652 3653	if ( empty( $wp_customize ) ) {3654		require_once ABSPATH . WPINC . '/class-wp-customize-manager.php';3655		$wp_customize = new WP_Customize_Manager(3656			array(3657				'changeset_uuid'     => $changeset_post->post_name,3658				'settings_previewed' => false,3659			)3660		);3661	}3662 3663	if ( ! did_action( 'customize_register' ) ) {3664		/*3665		 * When running from CLI or Cron, the customize_register action will need3666		 * to be triggered in order for core, themes, and plugins to register their3667		 * settings. Normally core will add_action( 'customize_register' ) at3668		 * priority 10 to register the core settings, and if any themes/plugins3669		 * also add_action( 'customize_register' ) at the same priority, they3670		 * will have a $wp_customize with those settings registered since they3671		 * call add_action() afterward, normally. However, when manually doing3672		 * the customize_register action after the setup_theme, then the order3673		 * will be reversed for two actions added at priority 10, resulting in3674		 * the core settings no longer being available as expected to themes/plugins.3675		 * So the following manually calls the method that registers the core3676		 * settings up front before doing the action.3677		 */3678		remove_action( 'customize_register', array( $wp_customize, 'register_controls' ) );3679		$wp_customize->register_controls();3680 3681		/** This filter is documented in wp-includes/class-wp-customize-manager.php */3682		do_action( 'customize_register', $wp_customize );3683	}3684	$wp_customize->_publish_changeset_values( $changeset_post->ID );3685 3686	/*3687	 * Trash the changeset post if revisions are not enabled. Unpublished3688	 * changesets by default get garbage collected due to the auto-draft status.3689	 * When a changeset post is published, however, it would no longer get cleaned3690	 * out. This is a problem when the changeset posts are never displayed anywhere,3691	 * since they would just be endlessly piling up. So here we use the revisions3692	 * feature to indicate whether or not a published changeset should get trashed3693	 * and thus garbage collected.3694	 */3695	if ( ! wp_revisions_enabled( $changeset_post ) ) {3696		$wp_customize->trash_changeset_post( $changeset_post->ID );3697	}3698}

History

Introduced in 4.7.0. Unchanged from 6.7.7 through 7.1.0.

1. 6.7.7
2. 6.8.8
3. 6.9.7
4. 7.0.4
5. 7.1.0

Signature, return type and hooks compared across 5 parsed releases.

About this page

Parsed data

Generated from the wordpress-develop 7.1.0 tag, from src/wp-includes/theme.php, and regenerated for each WordPress release so it tracks the code rather than a snapshot of it.

Corrections

Something wrong on this page? Report it and it gets fixed in the next regeneration.