Restreindre le type de publication personnalisé au rôle d'administrateur de site uniquement

Comment puis-je supprimer ce type de publication personnalisé d'être affiché dans le tableau de bord pour les utilisateurs non administrateurs?

/* 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'); 
}

custom-post-types posts customization

— urok93
source

register_post_type()accepte un paramètre capabilitiesdans ses arguments. Voir get_post_type_capabilities()pour les valeurs possibles. D'après les commentaires:

Par défaut, sept clés sont acceptées dans le cadre du tableau des capacités:

edit_post, read_postEt delete_postsont des méta capacités, qui sont ensuite généralement mis en correspondance avec des capacités primitives correspondantes en fonction du contexte, ce qui serait le poste en cours d' édition / lecture / supprimé et l'être de l' utilisateur ou le rôle vérifié. Ainsi, ces capacités ne seraient généralement pas accordées directement aux utilisateurs ou aux rôles.

edit_posts - Contrôle si les objets de ce type de publication peuvent être modifiés.

edit_others_posts- Contrôle si les objets de ce type appartenant à d'autres utilisateurs peuvent être modifiés. Si le type de publication ne prend pas en charge un auteur, cela se comportera comme edit_posts.

publish_posts - Contrôle la publication des objets de ce type de publication.

read_private_posts - Contrôle si les objets privés peuvent être lus.

Ces quatre capacités primitives sont vérifiées dans le noyau à divers endroits. Il existe également sept autres capacités primitives qui ne sont pas référencées directement dans le noyau, sauf dans map_meta_cap(), qui prend les trois méta capacités susmentionnées et les traduit en une ou plusieurs capacités primitives qui doivent ensuite être vérifiées par rapport à l'utilisateur ou au rôle, selon le contexte.

read - Contrôle si les objets de ce type de message peuvent être lus.

delete_posts - Contrôle si les objets de ce type de publication peuvent être supprimés.

delete_private_posts - Contrôle si les objets privés peuvent être supprimés.

delete_published_posts - Contrôle si les objets publiés peuvent être supprimés.

delete_others_posts- Contrôle si les objets appartenant à d'autres utilisateurs peuvent être supprimés. Si le type de publication ne prend pas en charge un auteur, cela se comportera commedelete_posts .

edit_private_posts - Contrôle si les objets privés peuvent être modifiés.

edit_published_posts - Contrôle si les objets publiés peuvent être modifiés.

Ces capacités supplémentaires ne sont utilisées que dans map_meta_cap(). Par conséquent, ils ne sont attribués par défaut que si le type de publication est enregistré avec l' 'map_meta_cap'argument défini sur true(par défaut false).

Dans vos arguments d'enregistrement, ajoutez:

'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
source

Comment feriez-vous la même chose en permettant aux administrateurs et aux éditeurs d'accéder au cpt?

— urok93

@drtanz Donne à la fois une fonctionnalité personnalisée et un filtre user_has_cap. Voir cette réponse pour un exemple.

— fuxia

Puis-je le faire de la même manière que vous l'avez suggéré, mais mettre la capacité manage_links (partagée entre les administrateurs et les éditeurs) au lieu de update_core?

— urok93

@drtanz Oui, mais j'utiliserais une fonctionnalité personnalisée. Le gestionnaire de liens sera finalement supprimé, et vous ne savez pas alors ce qui arrive aux capacités attribuées.

— fuxia

Remarque sur update_core; Seuls les administrateurs d'installations à site unique ont cette capacité. Dans Multisite, seul le Super Admin a cette capacité.

— numediaweb