Ogranicz niestandardowy typ postu tylko do roli administratora witryny

17

Jak mogę usunąć ten niestandardowy typ postu z panelu administracyjnego, aby nie był wyświetlany użytkownikom niebędącym administratorami?

/* 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'); 
}
urok93
źródło

Odpowiedzi:

13

register_post_type()akceptuje parametr capabilitiesw swoich argumentach. Sprawdź get_post_type_capabilities()możliwe wartości. Z komentarzy:

Domyślnie siedem kluczy jest akceptowanych jako część tablicy możliwości:

  • edit_post, read_posti delete_postsą meta możliwościami, które są następnie mapowane na odpowiadające im prymitywne funkcje w zależności od kontekstu, którym byłby edytowany / czytany / usuwany post oraz sprawdzany użytkownik lub rola. Dlatego te funkcje zasadniczo nie byłyby przyznawane bezpośrednio użytkownikom ani rolom.

  • edit_posts - Kontroluje, czy można edytować obiekty tego typu postów.

  • edit_others_posts- Kontroluje, czy obiekty tego typu należące do innych użytkowników mogą być edytowane. Jeśli typ postu nie obsługuje autora, będzie to wyglądać tak edit_posts.
  • publish_posts - Kontroluje publikowanie obiektów tego typu postów.
  • read_private_posts - Kontroluje, czy można odczytać obiekty prywatne.

Te cztery podstawowe funkcje są sprawdzane w rdzeniu w różnych lokalizacjach. Istnieje również siedem innych prymitywnych możliwości, do których nie ma bezpośredniego odniesienia w rdzeniu, z wyjątkiem map_meta_cap(), który bierze trzy wyżej wspomniane meta-zdolności i tłumaczy je na jedną lub więcej prymitywnych możliwości, które należy następnie sprawdzić w odniesieniu do użytkownika lub roli, w zależności od kontekstu.

  • read - Kontroluje, czy można odczytać obiekty tego typu postów.
  • delete_posts - Kontroluje, czy obiekty tego typu postów można usunąć.
  • delete_private_posts - Kontroluje, czy można usunąć prywatne obiekty.
  • delete_published_posts - Kontroluje, czy opublikowane obiekty można usunąć.
  • delete_others_posts- Kontroluje, czy obiekty należące do innych użytkowników mogą być usuwane. Jeśli typ postu nie obsługuje autora, będzie to wyglądać tak delete_posts.
  • edit_private_posts - Kontroluje, czy obiekty prywatne mogą być edytowane.
  • edit_published_posts - Kontroluje, czy opublikowane obiekty można edytować.

Te dodatkowe możliwości są używane tylko w map_meta_cap(). Dlatego są one przypisywane domyślnie tylko wtedy, gdy typ wpisu jest zarejestrowany z 'map_meta_cap'argumentem ustawionym na true(domyślnie jest false).

W argumentach rejestracyjnych dodaj:

'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'
),
fuxia
źródło
Jak zrobiłbyś to samo, ale pozwalając administratorom i redaktorom na dostęp do cpt?
urok93
@drtanz Daj zarówno niestandardowe możliwości, jak i filtr user_has_cap. Zobacz tę odpowiedź jako przykład.
fuxia
Czy mogę to zrobić tak, jak zasugerowałeś, ale zamiast funkcji update_core umieść opcję manage_links (współdzieloną przez administratorów i redaktorów)?
urok93
@drtanz Tak, ale użyłbym niestandardowej funkcji. Menedżer łączy zostanie ostatecznie usunięty i nie wiesz, co stanie się z przypisanymi możliwościami.
fuxia
2
Uwaga na temat update_core; Tylko administratorzy instalacji w pojedynczej lokalizacji mają taką możliwość. W Multisite tylko Super Administrator ma takie możliwości.
numediaweb