Alternativa a User Role Editor: cinco preguntas antes de cambiar
Quien busca una alternativa a un plugin de permisos normalmente no ha sufrido un error, sino que ha detectado una carencia: un cliente ve entradas de menú que no le conciernen. Una entrada protegida aparece, pese a todo, en algún sitio. O ya no se puede decir quién recibió qué permiso y cuándo. Cinco preguntas ponen orden en esto.
Pregunta 1: ¿se sostiene la regla también sin el backend?
Es la más importante, y puedes responderla tú mismo en un minuto. Protege una entrada de forma que solo la vea un rol concreto. Cierra sesión. Abre /wp-json/wp/v2/posts?search= con una palabra de esa entrada.
Si el contenido aparece en la respuesta, tu regla solo cambia la vista. La API REST de WordPress es accesible de serie y consulta otros puntos del código distintos de los de un listado de entradas en el backend. Kakapo Roles aplica expresamente la regla de visibilidad también ahí; precisamente por eso, esta prueba es la forma más rápida de evaluar un plugin de permisos.
Haz también esta prueba con el plugin que usas ahora, antes de cambiar. A veces la carencia está en otro sitio, por ejemplo en un maquetador que sirve contenidos a través de un endpoint propio.
Pregunta 2: ¿puede alguien darse más permisos a sí mismo?
Un plugin de permisos que permite a cualquiera con acceso a la interfaz ascender su propio rol anula su propósito. WordPress tiene un mecanismo de control para eso, get_editable_roles(), que determina qué roles puede editar alguien. Pregunta para la alternativa: ¿se respeta en todos los puntos?
En una red multisitio se añade un segundo límite: allí los roles son en parte válidos para toda la red. Quien los sobrescribe desde un subsitio los cambia para todos los sitios de la red, también para los que no le pertenecen.
Pregunta 3: ¿se puede ordenar el backend?
Los permisos dicen lo que alguien PUEDE hacer. Para un cliente es igual de importante lo que VE. Un editor que tiene delante doce entradas de menú, diez de ellas bloqueadas, no tiene un backend seguro, sino uno confuso.
Por eso, comprueba si la alternativa va más allá de roles y permisos: menú de administración por rol, biblioteca de medios limitada a los archivos propios, widgets y menús de navegación, shortcodes permitidos, redirección tras el inicio de sesión. Kakapo Roles lo trae integrado; en muchos plugins de este tipo son extensiones sueltas o fragmentos de código.
Pregunta 4: ¿se puede consultar qué se ha cambiado?
Los permisos se cambian rara vez y, casi siempre, con prisas. Seis meses después surge la pregunta de por qué un rol puede hacer algo. Sin registro, la respuesta es una suposición.
Pregunta para la alternativa: ¿hay un registro de cambios, y consta en él QUIÉN recibió o perdió QUÉ permiso y CUÁNDO? Kakapo Roles lleva uno y anota también los cambios que se producen mediante asignaciones y migraciones.
Pregunta 5: ¿tengo que construirlo de nuevo en cada sitio?
Quien gestiona varias instalaciones construye la misma estructura de permisos varias veces, y cada vez se desvía un poco. Al cabo de un año, cinco sitios son cinco casos especiales. Por eso, comprueba si la estructura se puede exportar e importar, y qué pasa con los roles existentes al importar: ¿se añade o se sustituye?
Kakapo Roles puede hacer ambas cosas e indica antes de importar cuál de las dos vías está seleccionada. «Sustituir» (en alemán: „Ersetzen“) es la más peligrosa, y por eso hay que confirmarla expresamente.
La lista de comprobación, en resumen
| Criterio | Por qué importa | En Kakapo Roles |
|---|---|---|
| Efecto en la API REST | Si no, la regla solo protege la vista | aplicado expresamente |
| Protección frente a la escalada de permisos | Si no, el plugin se anula a sí mismo | se respeta get_editable_roles, también en redes multisitio |
| Ordenar el backend | Un cliente debe ver lo que le concierne | menú de administración, biblioteca de medios, widgets, menús de navegación, shortcodes |
| Redirección tras el inicio de sesión por rol | El cliente llega adonde trabaja | integrado |
| Papelera para roles | Rara vez se borra un rol con total tranquilidad | con restauración |
| Registro de cambios | Seis meses después, lo que cuenta es tener constancia | quién, cuándo, qué permiso |
| Trasladable a otros sitios | Si no, cada sitio se convierte en un caso especial | exportación e importación, añadir o sustituir |
| Varios sitios con una sola licencia | Una factura en lugar de cinco | nueve plugins, un solo inicio de sesión |
Qué deberías hacer antes de cambiar
- Deja constancia de la situación actual: qué roles propios existen y qué permisos tienen asociados.
- Crea una copia de seguridad. Los permisos están en la base de datos, y un error afecta a todos los usuarios a la vez.
- Reconstruye la estructura en el nuevo plugin y compárala fila por fila.
- Inicia sesión con un usuario de prueba por rol y comprueba lo que ve realmente.
- Haz la prueba REST de la pregunta 1.
- Desactiva el plugin antiguo en lugar de eliminarlo, durante dos semanas.
Dos plugins de permisos a la vez escriben en los mismos roles, y gana quien guarda en último lugar. Durante el periodo de transición, haz cambios solo en uno de los dos.
Preguntas frecuentes
¿Se pierden mis roles al cambiar?
¿Puedo tener ambos funcionando en paralelo?
¿Lo necesito realmente si solo tengo dos editores?
¿Afecta esto al tiempo de carga?
¿Qué pasa sin una licencia válida?
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