WP_Customize_Manager::grant_edit_post_capability_for_changeset( array $caps, string $cap, int $user_id, array $args )

Re-map ‘edit_post’ meta cap for a customize_changeset post to be the same as ‘customize’ maps.


There is essentially a "meta meta" cap in play here, where ‘edit_post’ meta cap maps to the ‘customize’ meta cap which then maps to ‘edit_theme_options’. This is currently required in core for wp_create_post_autosave() because it will call _wp_translate_postdata() which in turn will check if a user can ‘edit_post’, but the the caps for the customize_changeset post type are all mapping to the meta capability. This should be able to be removed once https://core.trac.wordpress.org/ticket/40922 is addressed in core.

See also



(Required) Returns the user's actual capabilities.


(Required) Capability name.


(Required) The user ID.


(Required) Adds the context to the cap. Typically the object ID.


(array) Capabilities.


File: wp-includes/class-wp-customize-manager.php

	public function grant_edit_post_capability_for_changeset( $caps, $cap, $user_id, $args ) {
		if ( 'edit_post' === $cap && ! empty( $args[0] ) && 'customize_changeset' === get_post_type( $args[0] ) ) {
			$post_type_obj = get_post_type_object( 'customize_changeset' );
			$caps = map_meta_cap( $post_type_obj->cap->$cap, $user_id );
		return $caps;


Version Description
WP-4.9.0 Introduced.