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
- 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.
- 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.
- 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.
- 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 🙂 |