Ограничить пользовательский тип записи только ролью администратора сайта


17

Как я могу удалить этот пользовательский тип записи, чтобы он не отображался на приборной панели для пользователей без прав администратора?

/* Add Websites Custom Post Type */
add_action( 'init', 'create_website_type' );
function create_website_type() {

    register_post_type( 'website',
        array(
            'labels' => array(
                'name' => __( 'Websites' ),
                'singular_name' => __( 'Website' ),
                'add_new' => __( 'Add New Website' ),
                'add_new_item' => __( 'Add New Website' ),
                'edit' => __( 'Edit Website' ),             
                'edit_item' => __( 'Edit Website' ),                
                'new_item' => __( 'Add New Website' ),              
                'view' => __( 'View Website' ),         
                'view_item' => __( 'View Website' ),                    
                'search_items' => __( 'Search Websites' ),  
                'not_found' => __( 'No Websites Found' ),
                'not_found_in_trash' => __( 'No Websites found in Trash' ),                                         
            ),
            'description' => __('Websites to be shown in Resources section.'),
            'public' => true,
            'show_ui' => true,
            'publicly_queryable' => true,
            'exclude_from_search' => false,
            'menu_position' => 20,
            'supports' => array('title', 'editor'),
            'can_export' => true        
        )
    ); 
    remove_post_type_support('website','editor'); 
}

Ответы:


13

register_post_type()принимает параметр capabilitiesв своих аргументах. Смотрите get_post_type_capabilities()возможные значения. Из комментариев:

По умолчанию семь ключей принимаются как часть массива возможностей:

  • edit_post, read_postИ delete_postявляются мета возможности, которые затем , как правило , отображенные на соответствующие примитивные возможности в зависимости от контекста, который был бы пост редактируется / чтения / удаления , и пользователь или роль проверяется. Таким образом, эти возможности обычно не предоставляются непосредственно пользователям или ролям.

  • edit_posts - Управляет возможностью редактирования объектов этого типа.

  • edit_others_posts- Управляет возможностью редактирования объектов этого типа, принадлежащих другим пользователям. Если тип сообщения не поддерживает автора, то это будет вести себя как edit_posts.
  • publish_posts - Управляет публикацией объектов этого типа.
  • read_private_posts - Контролирует, можно ли читать частные объекты.

Эти четыре примитивные возможности проверяются в ядре в различных местах. Есть также семь других примитивных возможностей, на которые не ссылаются непосредственно в ядре, кроме как в map_meta_cap(), который берет три вышеупомянутые мета-возможности и переводит их в одну или несколько примитивных возможностей, которые затем должны проверяться в отношении пользователя или роли, в зависимости от контекста.

  • read - Управляет возможностью чтения объектов этого типа.
  • delete_posts - Управляет возможностью удаления объектов этого типа.
  • delete_private_posts - Управляет возможностью удаления личных объектов.
  • delete_published_posts - Управляет возможностью удаления опубликованных объектов.
  • delete_others_posts- Управляет возможностью удаления объектов, принадлежащих другим пользователям. Если тип сообщения не поддерживает автора, то это будет вести себя как delete_posts.
  • edit_private_posts - Управляет возможностью редактирования личных объектов.
  • edit_published_posts - Управляет возможностью редактирования опубликованных объектов.

Эти дополнительные возможности используются только в map_meta_cap(). Таким образом, они назначаются по умолчанию только в том случае, если тип записи зарегистрирован с 'map_meta_cap'аргументом, установленным в true(по умолчанию false).

В свои регистрационные аргументы добавьте:

'capabilities' => array(
    'edit_post'          => 'update_core',
    'read_post'          => 'update_core',
    'delete_post'        => 'update_core',
    'edit_posts'         => 'update_core',
    'edit_others_posts'  => 'update_core',
    'delete_posts'       => 'update_core',
    'publish_posts'      => 'update_core',
    'read_private_posts' => 'update_core'
),

Как бы вы поступили так же, но позволили администраторам и редакторам получить доступ к cpt?
urok93

@drtanz Дайте как пользовательскую возможность, так и фильтр user_has_cap. Смотрите этот ответ для примера.
fuxia

Могу ли я сделать это так же, как вы предлагали, но вместо функции update_core добавьте возможность manage_links (совместно используемую администраторами и редакторами)?
urok93

@drtanz Да, но я бы использовал пользовательские возможности. Менеджер ссылок будет удален, и вы не знаете, что произойдет с назначенными возможностями.
fuxia

2
Примечание об update_core; Только администраторы одного сайта установки имеют такие возможности. В Multisite только Super Admin имеет такие возможности.
numediaweb
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.