wp-includes/class-wp-customize-manager.php:785Whether the changeset branching is allowed.
boolOne hook fires while WP_Customize_Manager::branching() runs, in this order:
Filters whether or not changeset branching is allowed.
public function branching() { /** * Filters whether or not changeset branching is allowed. * * By default in core, when changeset branching is not allowed, changesets will operate * linearly in that only one saved changeset will exist at a time (with a 'draft' or * 'future' status). This makes the Customizer operate in a way that is similar to going to * "edit" to one existing post: all users will be making changes to the same post, and autosave * revisions will be made for that post. * * By contrast, when changeset branching is allowed, then the model is like users going * to "add new" for a page and each user makes changes independently of each other since * they are all operating on their own separate pages, each getting their own separate * initial auto-drafts and then once initially saved, autosave revisions on top of that * user's specific post. * * Since linear changesets are deemed to be more suitable for the majority of WordPress users, * they are the default. For WordPress sites that have heavy site management in the Customizer * by multiple users then branching changesets should be enabled by means of this filter. * * @since 4.9.0 * * @param bool $allow_branching Whether branching is allowed. If `false`, the default, * then only one saved changeset exists at a time. * @param WP_Customize_Manager $wp_customize Manager instance. */ $this->branching = apply_filters( 'customize_changeset_branching', $this->branching, $this ); return $this->branching; }Introduced in 4.9.0. Unchanged from 6.7.7 through 7.1.0.
Signature, return type and hooks compared across 5 parsed releases.
src/wp-includes/class-wp-customize-manager.php, and regenerated for each WordPress release so it tracks the code rather than a snapshot of it.