Acceso de cliente al backend: qué permisos hacen falta de verdad
Un cliente tiene que poder mantener textos. La vía más rápida es un acceso de administrador, y también la más cara. No porque alguien vaya a hacer algo malo, sino porque un clic equivocado en el área de plugins cuesta más que los diez minutos que habría requerido un rol bien configurado.
Lo que WordPress trae de serie
| Rol | Puede | Adecuado para |
|---|---|---|
| Colaborador | escribir entradas propias, sin publicarlas | Autores invitados |
| Autor | escribir y publicar entradas propias | redactores individuales |
| Editor | todas las entradas y páginas, también las ajenas | la mayoría de los clientes |
| Administrador | todo, incluidos plugins y usuarios | ti |
En la mayoría de los casos, Editor es la respuesta correcta. Cubre por completo los contenidos y deja fuera la parte técnica.
Dónde se queda corto aun así el rol de editor
Hay tres cosas que a un editor le faltan con regularidad, y para cada una existe una respuesta mejor que «pues entonces, administrador»:
- Editar menús: requiere un permiso que normalmente tiene el administrador y que se puede asignar de forma específica
- Usar maquetadores: muchos traen permisos propios que se pueden asignar por separado
- Gestionar formularios o la tienda: esos mismos plugins definen permisos propios para ello
El camino es siempre el mismo: añadir el único permiso que falta en lugar de cambiar de rol. Precisamente para eso existe una matriz de permisos.
Ordenar es más importante que bloquear
Un backend con doce entradas de menú, diez de ellas bloqueadas, no es seguro, sino confuso. El cliente busca, hace clic donde no es y llama por teléfono. Los permisos dicen lo que alguien puede hacer; igual de importante es lo que llega a ver.
- Reducir el menú de administración a lo que se necesita
- Limitar la biblioteca de medios a los archivos propios cuando varios clientes usan la misma instalación
- Ocultar widgets y menús de navegación cuando no le conciernen a nadie
- Tras el inicio de sesión, redirigir adonde empieza el trabajo, no al escritorio con cinco cuadros de aviso
La prueba que dura un minuto
Los permisos no se pueden valorar en la pantalla en la que se asignan. Crea un usuario de prueba por rol e inicia sesión como ese usuario, en un segundo navegador, para que tu propio acceso siga abierto.
Y para los contenidos protegidos hay una segunda prueba: cierra sesión y abre /wp-json/wp/v2/posts?search= con una palabra de la entrada protegida. Si el contenido aparece en la respuesta, tu regla solo cambia la vista: los datos están al descubierto.
Esta prueba vale para cualquier plugin de permisos. «Ocultar» y «bloquear» son dos cosas distintas, y solo una de ellas se sostiene.
Dos trampas cuando hay varias personas a cargo
La primera: quien puede asignar permisos puede darse más a sí mismo. WordPress tiene un mecanismo de control para eso, get_editable_roles(), y un plugin que lo ignora abre precisamente la vía que debería cerrar.
La segunda afecta a las redes multisitio: allí los roles son en parte válidos para toda la red. Quien los sobrescribe desde un subsitio los cambia para todos los sitios, también para los que no le pertenecen.
En la despedida
- Desactivar el acceso, no eliminarlo de inmediato: si no, las entradas pierden su autor.
- Transferir las entradas a otra cuenta antes de eliminarla.
- Revocar las contraseñas de aplicación de esa cuenta; sobreviven a un cambio de contraseña.
- Cerrar las sesiones activas.
- Anotar en el registro de cambios cuándo y por qué.
Preguntas frecuentes
¿Puede un cliente actualizar plugins sin permisos de administrador?
¿Y si el cliente quiere ser administrador de todos modos?
¿Necesito un plugin para esto?
¿Cuántos roles propios tienen sentido?
¿Tiene efecto una restricción también en el frontend?
Kakapo Roles: paga una vez, úsalo para siempre.
Los nueve plugins por 149 € una vez en lugar de 13 € al mes. Pago seguro con Stripe. Durante los primeros 14 días: problema resuelto o te devolvemos el dinero.
Conseguir Lifetime Todas las funciones