WP_Customize_Manager::grant_edit_post_capability_for_changeset() │ public │ WP 4.9.0

Re-maps edit_post 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 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() 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.

Метод класса: WP_Customize_Manager{}

Хуков нет.

Возвращает

Массив. Capabilities.

Использование

$WP_Customize_Manager = new WP_Customize_Manager();
$WP_Customize_Manager->grant_edit_post_capability_for_changeset( $caps, $cap, $user_id, $args );

$caps(string[]) (обязательный)

Array of the user's capabilities.

$cap(строка) (обязательный)

Capability name.

$user_id(int) (обязательный)

The user ID.

$args(массив) (обязательный)

Adds the context to the cap. Typically the object ID.

Заметки

• Смотрите: WP_Customize_Manager::save_changeset_post()
• Смотрите: _wp_translate_postdata()

Список изменений

Код WP_Customize_Manager::grant_edit_post_capability_for_changeset() WP Customize Manager::grant edit post capability for changeset ^{WP 6.2}

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;
}