Como comprobar permisos con current_user_can en PHP en WordPress

Contents

Introducción: ¿Qué hace current_user_can()?

current_user_can() es la función central de WordPress para comprobar si el usuario actual tiene una determinada capacidad (capability). Devuelve true o false y debe usarse siempre que necesites autorizar la visualización de una interfaz o la ejecución de una acción en el servidor. A diferencia de comprobar roles (por ejemplo, administrator), las capacidades describen permisos concretos (edit_posts, manage_options) y permiten una autorización más flexible y segura.

Firma y comportamiento básico

La función se usa normalmente así:

if ( current_user_can( manage_options ) ) {
    // El usuario puede gestionar opciones (habitualmente administradores)
}

También admite parámetros adicionales para capacidades meta (p. ej. comprobar edición de un post concreto):

if ( current_user_can( edit_post, post_id ) ) {
    // El usuario puede editar el post con ID post_id
}

Conceptos clave

  • Capacidades vs Roles: Las capacidades son permisos concretos los roles agrupan capacidades. Usa capacidades en las comprobaciones, no nombres de rol.
  • Meta-capabilities: Capacidades como edit_post se mapean a capacidades concretas (p. ej. edit_others_posts o edit_posts) mediante map_meta_cap. current_user_can hace este mapeo internamente.
  • Servidor y UI: Realiza comprobaciones tanto en la interfaz (para ocultar botones) como siempre en el servidor antes de ejecutar acciones.
  • Multisite: Para privilegios de red usa funciones como is_super_admin() y capacidades específicas de red.

Ejemplos prácticos

1) Mostrar un enlace solo para usuarios con capacidad

if ( current_user_can( edit_pages ) ) {
    echo lta href=/wp-admin/edit.php?post_type=pagegtEditar páginaslt/agt
}

2) Comprobar edición de un post concreto

post_id = 123

if ( ! current_user_can( edit_post, post_id ) ) {
    wp_die( No tienes permiso para editar este post. )
}

// Procesar guardado seguro...

3) Comprobación combinada de varias capacidades

// Requiere que el usuario pueda publicar y editar publicaciones
if ( current_user_can( publish_posts )  current_user_can( edit_posts ) ) {
    // Lógica para usuarios con ambas capacidades
}

4) AJAX: validar nonce y capacidad en admin-ajax.php

add_action( wp_ajax_mi_accion, mi_accion_callback )

function mi_accion_callback() {
    check_ajax_referer( mi_nonce, security )

    if ( ! current_user_can( edit_posts ) ) {
        wp_send_json_error( array( message => Sin permisos ), 403 )
    }

    // Procesar petición...
    wp_send_json_success( array( message => Ok ) )
}

5) REST API: permission_callback

register_rest_route( mi-plugin/v1, /recurso, array(
    methods  => POST,
    callback => mi_recurso_crear,
    permission_callback => function( request ) {
        return current_user_can( edit_posts )
    },
) )

6) Añadir una capacidad personalizada a un role

// En la activación del plugin
function mi_plugin_activate() {
    role = get_role( editor )
    if ( role ) {
        role->add_cap( manage_eventos )
    }
}
register_activation_hook( __FILE__, mi_plugin_activate )

7) Registrar Custom Post Type con capacidades personalizadas

register_post_type( evento, array(
    label => Eventos,
    capability_type => evento,
    map_meta_cap => true,
    capabilities => array(
        edit_post          => edit_evento,
        read_post          => read_evento,
        delete_post        => delete_evento,
        edit_posts         => edit_eventos,
        edit_others_posts  => edit_others_eventos,
        publish_posts      => publish_eventos,
        read_private_posts => read_private_eventos,
    ),
) )

// Luego hay que añadir esas capacidades a roles adecuados

Lista rápida de capacidades comunes

Capacidad Descripción
manage_options Acceso a opciones del sitio (ajustes). Suele ser administrador.
edit_posts Editar sus propias entradas.
edit_others_posts Editar entradas de otros usuarios.
publish_posts Publicar entradas.
delete_posts Eliminar sus propias entradas.
read Acceso básico al área de administración (suscriptores tienen esto).

Buenas prácticas y recomendaciones

  • Comprobar siempre en el servidor: Ocultar botones en la UI no sustituye la verificación en el servidor antes de ejecutar cambios persistentes.
  • Usar capacidades, no roles: Chequea capacidades con current_user_can en vez de roles (p. ej. administrator).
  • Verificar nonces y sanitizar datos: Acompaña current_user_can con check_admin_referer/check_ajax_referer y sanitización (sanitize_text_field, intval, etc.).
  • No confiar en is_admin() para permisos: is_admin() solo comprueba si se está en el área de administración, no permisos de usuario.
  • Capacidades meta: Para objetos (posts, terms) usa current_user_can con el ID correspondiente (p. ej. edit_post, edit_term).
  • Persistencia de cambios en roles: Cuando añades capacidades a roles, hazlo en la activación del plugin y evita hacerlo en cada carga.
  • Pruebas: Prueba con cuentas de distintos roles y usuarios para validar el comportamiento.

Problemas frecuentes y cómo resolverlos

  1. Capacidad mal escrita: current_user_can(edit_posts) vs edit_post (nota la diferencia). Revisa la documentación y el código del plugin/tema.
  2. Las capacidades no se aplican: Si añadiste capabilities a un rol y no se reflejan, asegúrate de haber ejecutado la lógica en activation hook y de no sobrescribir roles en otra parte del código.
  3. Custom Post Type y map_meta_cap: Si usas map_meta_cap = true en register_post_type, utiliza la capacidad meta (edit_post, post_id) en las comprobaciones.
  4. Multisite: En una red, algunas capacidades se gestionan globalmente. Usa is_super_admin() cuando corresponda.

Herramientas útiles en tiempo de desarrollo

  • wp_roles() y get_editable_roles() para examinar qué capacidades tienen los roles actuales.
  • Plugins como Members o User Role Editor para inspeccionar y modificar capacidades durante pruebas.
  • Registros y logging para ver por qué una comprobación falla (por ejemplo, error_log(print_r( wp_get_current_user(), true ) ) ).

Resumen práctico

current_user_can() es la forma correcta y recomendada de comprobar permisos en WordPress. Utilízala siempre junto con validación del lado servidor (nonces y sanitización), usa capacidades en vez de roles y adapta la comprobación para meta-capabilities (por ejemplo, pasando el ID de post cuando corresponda). Cuando registres tipos personalizados o capacidades nuevas, asegúrate de mapear y asignar las capacidades a los roles adecuados en la activación del plugin o tema.

Referencias rápidas

Documentación oficial de capacidades y roles en el Codex/Developer Handbook: https://developer.wordpress.org/plugins/security/authorization/



Acepto donaciones de BAT's mediante el navegador Brave 🙂



Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *