Restringir tipo de publicación personalizada solo al rol de administrador del sitio

Question

Restringir tipo de publicación personalizada solo al rol de administrador del sitio

12 jun 2012, 14:00:51

Vistas: 15.7K

Votos: 20

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

/* Añadir Tipo de Publicación Personalizado para Sitios Web */
add_action( 'init', 'create_website_type' );
function create_website_type() {

    register_post_type( 'website',
        array(
            'labels' => array(
                'name' => __( 'Sitios Web' ),
                'singular_name' => __( 'Sitio Web' ),
                'add_new' => __( 'Añadir Nuevo Sitio Web' ),
                'add_new_item' => __( 'Añadir Nuevo Sitio Web' ),
                'edit' => __( 'Editar Sitio Web' ),             
                'edit_item' => __( 'Editar Sitio Web' ),                
                'new_item' => __( 'Añadir Nuevo Sitio Web' ),              
                'view' => __( 'Ver Sitio Web' ),         
                'view_item' => __( 'Ver Sitio Web' ),                    
                'search_items' => __( 'Buscar Sitios Web' ),  
                'not_found' => __( 'No se encontraron Sitios Web' ),
                'not_found_in_trash' => __( 'No hay Sitios Web en la Papelera' ),                                         
            ),
            'description' => __('Sitios web para mostrar en la sección de Recursos.'),
            '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

4.05K

tipos de entradas personalizadas publicaciones personalización

Todas las respuestas a la pregunta

Comentarios

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

urok93

12 jul 2013 02:54:52

@drtanz Asigna a ambos una capacidad personalizada y filtra user_has_cap. Mira esta respuesta para ver un ejemplo.

fuxia

12 jul 2013 02:58:00

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

urok93

12 jul 2013 03:00:05

@drtanz Sí, pero yo usaría una capacidad personalizada. El gestor de enlaces eventualmente será eliminado, y no sabes qué pasará con las capacidades asignadas entonces.

fuxia

12 jul 2013 03:01:59

Intenté usar manage_categories pero obtuve errores, estaba tratando de encontrar algunas capacidades únicas para editores y administradores en http://codex.wordpress.org/Roles_and_Capabilities#Capability_vs._Role_Table

urok93

12 jul 2013 03:36:26

Mostrar los 2 comentarios restantes

Para el administrador de Multisitio puede usar el siguiente código en functions.php:

/* Agregar Tipo de Entrada Personalizado para Sitios Web */

function crear_TipoEntradaPersonalizada_website() {

    register_post_type( 'website',
        array(
            'labels' => array(
                'name' => __( 'Sitios Web' ),
                'singular_name' => __( 'Sitio Web' ),
                'add_new' => __( 'Agregar Nuevo Sitio Web' ),
                'add_new_item' => __( 'Agregar Nuevo Sitio Web' ),
                'edit' => __( 'Editar Sitio Web' ),             
                'edit_item' => __( 'Editar Sitio Web' ),                
                'new_item' => __( 'Agregar Nuevo Sitio Web' ),              
                'view' => __( 'Ver Sitio Web' ),         
                'view_item' => __( 'Ver Sitio Web' ),                    
                'search_items' => __( 'Buscar Sitios Web' ),  
                'not_found' => __( 'No se encontraron Sitios Web' ),
                'not_found_in_trash' => __( 'No hay Sitios Web en la Papelera' ),                                         
            ),
            'description' => __('Sitios web para mostrar en la sección de Recursos.'),
            'public' => true,
            'show_ui' => true,
            'publicly_queryable' => true,
            'exclude_from_search' => false,
            'menu_position' => 20,
            'supports' => array('title', 'editor'),
            'can_export' => true        
        )
    ); 
}

 // si el usuario inicia sesión como administrador, muestra el tipo de entrada personalizado, de lo contrario no
add_action( 'init', function(){
     $rolUsuarioActual = wp_get_current_user()->caps;
     $esAdministrador = $rolUsuarioActual['administrator'] ?? null;

     if( $esAdministrador) {
          crear_TipoEntradaPersonalizada_website();
             }
 

} );

El código anterior agrega un tipo de entrada personalizado para todos los usuarios administradores en modo multisitio y super administradores, y lo oculta y restringe para otros roles de usuario como autor, editor, etc.

charll

1

25 jul 2023 15:33:40

fuxia 107K · Accepted Answer · 2012-06-12T14:28:08Z

register_post_type() acepta un parámetro capabilities en sus argumentos. Consulta get_post_type_capabilities() para los valores posibles. De los comentarios:

Por defecto, se aceptan siete claves como parte del array de capacidades:

edit_post, read_post y delete_post son capacidades meta, que generalmente se mapean a capacidades primitivas correspondientes dependiendo del contexto, que sería el post que se está editando/leyendo/eliminando y el usuario o rol que se está verificando. Por lo tanto, estas capacidades generalmente no se otorgan directamente a usuarios o roles.

edit_posts - Controla si los objetos de este tipo de post pueden editarse.

edit_others_posts - Controla si los objetos de este tipo propiedad de otros usuarios pueden editarse. Si el tipo de post no admite un autor, entonces esto se comportará como edit_posts.

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

read_private_posts - Controla si los objetos privados pueden leerse.

Estas cuatro capacidades primitivas se verifican en el núcleo en varios lugares. También hay otras siete capacidades primitivas que no se referencian directamente en el núcleo, excepto en map_meta_cap(), que toma las tres capacidades meta mencionadas anteriormente y las traduce en una o más capacidades primitivas que luego deben verificarse contra el usuario o rol, dependiendo del contexto.

read - Controla si los objetos de este tipo de post pueden leerse.

delete_posts - Controla si los objetos de este tipo de post pueden eliminarse.

delete_private_posts - Controla si los objetos privados pueden eliminarse.

delete_published_posts - Controla si los objetos publicados pueden eliminarse.

delete_others_posts - Controla si los objetos propiedad de otros usuarios pueden eliminarse. Si el tipo de post no admite un autor, entonces esto se comportará como delete_posts.

edit_private_posts - Controla si los objetos privados pueden editarse.

edit_published_posts - Controla si los objetos publicados pueden editarse.

Estas capacidades adicionales solo se usan en map_meta_cap(). Por lo tanto, solo se asignan por defecto si el tipo de post se registra con el argumento 'map_meta_cap' establecido en true (el valor predeterminado es false).

En tus argumentos de registro añade:

'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'
),