Обмежте спеціальний тип публікації лише роллю адміністратора сайту


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

Чи можу я зробити це так само, як ви запропонували, але поставити можливість management_links (поділитися між адміністраторами та редакторами) замість update_core?
urok93

@drtanz Так, але я б використовував спеціальні можливості. Менеджер посилань буде видалено з часом, і ви не знаєте, що станеться із призначеними можливостями.
fuxia

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