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

Re-maps ‘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 #40922 is addressed in core.

See also


Array of the user’s capabilities.
Capability name.
The user ID.
Adds the context to the cap. Typically the object ID.


array Capabilities.


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;



User Contributed Notes

You must log in before being able to contribute a note or feedback.