Restrinja el tipo de publicación personalizada solo a la función de administrador del sitio

¿Cómo puedo eliminar este tipo de publicación personalizada para que no se muestre en el panel para usuarios que no sean administradores?

/* 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
fuente

register_post_type()acepta un parámetro capabilitiesen sus argumentos. Ver get_post_type_capabilities()para posibles valores. De los comentarios:

Por defecto, se aceptan siete claves como parte de la matriz de capacidades:

edit_post, read_posty delete_postson meta capacidades, que generalmente se asignan a las capacidades primitivas correspondientes según el contexto, que sería la publicación que se edita / lee / elimina y el usuario o rol que se verifica. Por lo tanto, estas capacidades generalmente no se otorgarían directamente a los usuarios o roles.

edit_posts - Controla si los objetos de este tipo de publicación se pueden editar.

edit_others_posts- Controla si los objetos de este tipo propiedad de otros usuarios pueden editarse. Si el tipo de publicación no es compatible con un autor, esto se comportará como edit_posts.

publish_posts - Controla la publicación de objetos de este tipo de publicación.

read_private_posts - Controla si los objetos privados se pueden leer.

Estas cuatro capacidades primitivas se verifican en el núcleo en varias ubicaciones. También hay otras siete capacidades primitivas a las que no se hace referencia directamente en el núcleo, excepto en map_meta_cap(), que toma las tres capacidades meta antes mencionadas y las traduce en una o más capacidades primitivas que luego deben verificarse contra el usuario o rol, según el contexto.

read - Controla si los objetos de este tipo de publicación se pueden leer.

delete_posts - Controla si los objetos de este tipo de publicación se pueden eliminar.

delete_private_posts - Controla si los objetos privados se pueden eliminar.

delete_published_posts - Controla si los objetos publicados se pueden eliminar.

delete_others_posts- Controla si los objetos de otros usuarios pueden ser eliminados. Si el tipo de publicación no es compatible con un autor, esto se comportará como delete_posts.

edit_private_posts - Controla si los objetos privados se pueden editar.

edit_published_posts - Controla si los objetos publicados se pueden editar.

Estas capacidades adicionales solo se utilizan en map_meta_cap(). Por lo tanto, solo se asignan de manera predeterminada si el tipo de publicación se registra con el 'map_meta_cap'argumento establecido en true(el valor predeterminado es false).

En sus argumentos de registro agregue:

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

¿Cómo haría lo mismo pero permitiendo que los administradores y editores accedan al cpt?

— urok93

@drtanz Proporcione tanto una capacidad personalizada como un filtro user_has_cap. Vea esta respuesta para un ejemplo.

— fuxia

¿Podría hacerlo de la misma manera que sugirió, pero poner la capacidad de manage_links (compartida entre administradores y editores) en lugar de update_core?

— urok93

@drtanz Sí, pero usaría una capacidad personalizada. El administrador de enlaces se eliminará eventualmente, y entonces no sabe qué sucede con las capacidades asignadas.

— fuxia

Nota sobre update_core; Solo los administradores de instalaciones de un solo sitio tienen esta capacidad. En Multisite, solo el Super Admin tiene estas habilidades.

— numediaweb