Rootstuff Block Permissions es un plugin gratuito para WordPress que te permite controlar qué bloques de Gutenberg y patrones ve cada rol de usuario, diferenciado además por tipo de contenido. En 2026, con sitios que manejan múltiples roles y tipos de post, es una solución concreta para agencias que no quieren que su cliente rompa el layout con el bloque Cover.
En 30 segundos
- Rootstuff Block Permissions permite ocultar bloques de Gutenberg por rol de usuario (Editor, Author, Contributor, roles personalizados) y por tipo de contenido (Posts, Pages, custom post types) de forma simultánea.
- A diferencia de otros plugins de gestión de bloques, la regla puede ser tan específica como «Editor en Pages ve estos bloques, Editor en Posts ve otros diferentes».
- El plugin es gratuito, disponible en el repositorio oficial de WordPress.org, y no requiere código para configurarlo.
- Lista vacía significa que no se bloquea nada: marcás solo lo que querés ocultar, y los bloques nuevos que se agreguen al sitio quedan permitidos automáticamente.
- Permite también deshabilitar el directorio remoto de patrones de WordPress.org y los patrones core por completo.
WordPress es un sistema de gestión de contenidos de código abierto creado por Matt Mullenweg y desarrollado por The WordPress Foundation. Se utiliza para crear, publicar y administrar contenido en sitios web y blogs.
Qué es Rootstuff Block Permissions y por qué es diferente
Rootstuff Block Permissions es un plugin liviano, pensado para agencias, que te deja decidir qué bloques de Gutenberg y qué patrones puede ver cada rol de usuario, segmentado además por tipo de contenido. Disponible gratis en WordPress.org, resuelve un problema concreto: la mayoría de los plugins de gestión de bloques ocultan un bloque para todo el mundo, sin importar quién lo usa ni dónde.
El problema con ese enfoque global es que se cae en cuanto tenés más de un perfil de usuario. Ponele que tenés un cliente que edita Pages y un equipo interno que trabaja sobre Posts. Con una solución genérica, o todos ven el bloque Cover o nadie lo ve. Rootstuff rompe esa lógica y te deja decir: «el Author no puede usar Cover en Pages, pero el Editor sí, y en Posts las reglas son distintas».
Eso es lo que lo diferencia de competidores como Block Permissions o incluso de Advanced Gutenberg: la combinación rol + tipo de contenido en una sola regla, sin escribir una línea de PHP.
Cómo funciona el control de permisos por rol y tipo de contenido
El modelo es sencillo una vez que lo entendés. Las reglas se construyen cruzando dos ejes: el rol del usuario (Editor, Author, Contributor, o cualquier rol personalizado) y el tipo de contenido sobre el que está trabajando (Posts, Pages, o cualquier custom post type registrado en el sitio).
Cuando combinás ambos, podés construir escenarios como estos:
- Un Author en Posts solo ve bloques de texto, imagen y botón.
- El mismo Author en Pages tiene bloques adicionales como columnas o separador.
- Un Editor en Posts accede a todo el set de bloques, incluyendo los de ACF.
- Un Contributor en cualquier tipo de contenido queda bloqueado a lo básico.
- Los administradores pueden estar completamente exentos (o incluidos si querés previsualizar la experiencia del cliente).
Acá viene lo bueno: el sistema trabaja por exclusión. La lista vacía significa «no bloqueás nada». Vos tildás lo que querés ocultar, y cualquier bloque que se agregue al sitio después (un plugin nuevo, un tema que registra bloques propios) queda automáticamente permitido a menos que vuelvas y lo tildés.
Instalación y configuración inicial
El proceso es el de siempre con cualquier plugin gratuito de WordPress.org: Plugins → Agregar nuevo → buscás «Rootstuff Block Permissions» → instalás → activás. Sin requerimientos especiales de versión PHP ni dependencias de otros plugins.
Una vez activo, la configuración aparece en el menú de ajustes del administrador. La interfaz es directa: lista de todos los bloques registrados en el sitio, con checkboxes para ocultar. Los filtros por rol y tipo de contenido están disponibles como selectores sobre esa lista. Más contexto en gestión de roles y permisos.
Guardás los cambios y ya. No hay que vaciar caché manualmente ni reiniciar nada. La próxima vez que un usuario con ese rol abra el editor en ese tipo de contenido, el insertor de bloques ya muestra solo lo que configuraste.
Configurar bloques por rol de usuario
Desde la pantalla de configuración seleccionás el rol que querés ajustar. Aparecen todos los bloques registrados en el sitio: core de WordPress, bloques del tema, bloques de plugins activos y bloques de ACF si los tenés instalados. Tildás los que querés esconder para ese rol, guardás, listo.
El comportamiento por defecto es permisivo: si no tildás nada para un rol, ese rol ve todos los bloques. Eso tiene sentido operativo, porque si venís de no tener ningún control, no rompés nada el día que instalás el plugin.
Los administradores pueden ser excluidos de todas las restricciones (lo cual tiene sentido para el desarrollo y la configuración del sitio), o incluirse deliberadamente para ver exactamente lo que ve el cliente (útil para testear antes de entregar).
Configurar bloques por tipo de contenido
El segundo eje de control es el tipo de contenido. Podés establecer reglas específicas para Posts, Pages, o cualquier custom post type que esté registrado en el sitio (WooCommerce Products, portafolios, recetas, lo que sea).
Esto es especialmente útil cuando el sitio tiene áreas con propósitos bien diferentes. Un blog de noticias donde los autores solo deben publicar texto e imágenes no necesita los mismos bloques que una sección de landing pages donde el diseñador trabaja con columnas complejas y sliders. Con Rootstuff podés especializar la experiencia de edición por área sin hackear nada. Relacionado: crear landing pages en WordPress.
¿Y cuándo combinás ambas dimensiones? Eso es cuando el plugin muestra su verdadero valor. Una configuración real de agencia podría ser: el cliente (Editor en Pages) ve bloques básicos más un bloque personalizado de «testimonios». El mismo Editor en Posts accede a todo el editor estándar. El equipo de redactores (Authors en Posts) solo ve texto, imagen y quote. Tres escenarios distintos, cero código.
Casos de uso reales: agencias y sitios con múltiples roles
El caso de uso más común en agencias es el de entrega de sitio a cliente. Terminás el desarrollo, le entregás acceso, y el cliente inevitablemente hace algo que no tenía que hacer porque el editor de bloques ofrece demasiadas opciones (spoiler: siempre es el bloque Cover mal usado o una tabla que rompe el layout mobile).
Con Rootstuff, antes de entregar, configurás el rol del cliente con solo los bloques que necesita para su flujo de trabajo: texto, imagen, botón, quizás video embed y el bloque personalizado que armaste para sus casos particulares. El resto desaparece del insertor. El cliente no lo puede usar porque no lo ve, y vos no recibís el ticket de soporte a las tres de la mañana.
Otro escenario: blog colaborativo con tres niveles de autor. Los Contributors solo pueden publicar con texto e imágenes simples. Los Authors tienen acceso a más bloques de layout. Los Editors tienen el set completo. Es un patrón de permisos escalonado que antes requería o un plugin pesado o código custom. Acá lo configurás con checkboxes.
Para sitios en un hosting WordPress, este tipo de control de interfaz reduce drásticamente los errores de edición y el tiempo de soporte post-entrega. Si trabajás con el hosting WordPress de Donweb y manejás múltiples clientes bajo un mismo plan, la combinación de Rootstuff con staging y backups automáticos te da un workflow de entrega bastante sólido.
Gestión de patrones y bloques de terceros
Además de bloques individuales, Rootstuff permite controlar los patrones. Podés ocultar patrones específicos de la misma forma que ocultás bloques, lo cual es útil si el tema incluye patrones de página completa que no querés que el cliente use (o modifique accidentalmente).
Dos opciones adicionales que vale destacar: deshabilitar el directorio remoto de patrones de WordPress.org, y deshabilitar los patrones core de WordPress por completo. La primera opción es especialmente relevante para sitios que operan en entornos con restricciones de red, o donde no querés que el cliente tenga acceso a patrones externos no revisados. Te puede servir nuestra cobertura de probar cambios en staging primero.
Los bloques de ACF (Advanced Custom Fields) y los de otros plugins se registran como bloques normales de Gutenberg, así que Rootstuff los detecta y los lista junto con los bloques core. No hay configuración extra: aparecen solos en la lista una vez que el plugin está activo.
Alternativas disponibles y cuándo elegir cada una
La comparativa honesta es esta:
| Plugin | Control por rol | Control por tipo de contenido | Combinar ambos | Gratis |
|---|---|---|---|---|
| Rootstuff Block Permissions | Sí | Sí | Sí | Sí |
| Block Permissions | Sí | No | No | Sí |
| Advanced Gutenberg | Sí (por perfil) | Parcial | Limitado | Freemium |
| PublishPress Blocks | Sí | Sí (versión pro) | Solo en pro | Freemium |

Si lo que necesitás es ocultar un bloque para todos los usuarios sin distinción, cualquier solución te sirve. El diferencial de Rootstuff aparece cuando necesitás la combinación rol + tipo de contenido en la versión gratuita, sin pagar por un plan pro ni lidiar con una interfaz pesada.
Advanced Gutenberg ofrece más opciones globales de gestión de editor (perfiles personalizados, estilos de bloques, etc.), pero su curva de configuración es más empinada y algunas funciones clave están detrás del pago. PublishPress Blocks es una alternativa seria, pero la combinación rol + tipo de contenido está en el plan pago.
Rootstuff zafa bien para el 80% de los casos de agencia sin pagar nada.
Qué está confirmado y qué todavía no
- Confirmado: Control por rol de usuario (Editor, Author, Contributor, roles custom), control por tipo de contenido (Posts, Pages, CPTs), combinación de ambos ejes, ocultamiento de patrones, deshabilitación del directorio remoto de patrones, deshabilitación de patrones core, soporte para bloques de ACF y plugins de terceros, disponibilidad gratuita en WordPress.org.
- Confirmado: Comportamiento «lista vacía = todo permitido» y auto-permiso de nuevos bloques.
- No confirmado todavía: Compatibilidad garantizada con el editor de sitio (FSE) y bloques de plantillas de temas de bloque. El plugin se presenta como enfocado en el editor de contenido; su comportamiento en contextos de plantillas globales no está documentado en la página oficial.
- No confirmado todavía: Planes de versión pro o funciones premium. Por ahora todo es gratis y sin mención de monetización futura.
Errores comunes al configurar permisos de bloques en WordPress
Confundir «ocultar» con «bloquear». Rootstuff oculta bloques del insertor, pero no impide que un usuario con conocimientos de HTML pegue el bloque directamente en el editor de código. Si el riesgo es de seguridad real, necesitás restricciones a nivel de capacidades de usuario, no solo de interfaz. Para gestión de roles y permisos de WordPress en profundidad, el blog hermano seguridadenwordpress.com tiene más contexto sobre ese enfoque.
No testear con el rol correcto. Configurás los permisos como administrador, guardás, y todo se ve igual porque el administrador está exento de las restricciones. Para verificar que la configuración funciona, tenés que iniciar sesión con un usuario del rol que configuraste, o usar un plugin de switching de usuarios.
Olvidarse de los custom post types registrados por plugins. Si el sitio tiene WooCommerce, el tipo «product» existe y tiene su propio contexto de edición. Si no configurás permisos para ese CPT, los usuarios del rol que querías restringir van a ver todos los bloques cuando editen productos. Las reglas de Posts y Pages no se aplican automáticamente a CPTs.
Asumir que la configuración persiste después de cambiar el tema. Los temas registran sus propios bloques y patrones. Si cambiás de tema o actualizás uno que agrega bloques nuevos, esos bloques van a aparecer como «permitidos por defecto» (que es el comportamiento correcto del plugin), pero puede sorprenderte si no lo tenés en cuenta al hacer mantenimiento del sitio.
Si querés saber más, tenemos un artículo detallado sobre [FREE] Rootstuff Block Permissions | Control Gutenberg block.
Preguntas Frecuentes
¿Cómo restringir bloques de Gutenberg según el rol de usuario?
Instalás Rootstuff Block Permissions desde WordPress.org, vas a la configuración del plugin, seleccionás el rol (Editor, Author, Contributor, o uno personalizado) y tildás los bloques que querés ocultar para ese rol. Los bloques tildados desaparecen del insertor para ese perfil de usuario. Si no tildás nada, el rol accede a todos los bloques. Sobre eso hablamos en preservar la calidad del contenido.
¿Puedo mostrar diferentes bloques en Pages versus Posts?
Sí, y eso es precisamente lo que diferencia a Rootstuff de otras soluciones. La configuración combina dos ejes: el rol del usuario y el tipo de contenido. Podés establecer que un Editor en Pages vea un set de bloques distinto al que ve cuando edita Posts, sin que una configuración afecte a la otra.
¿Los bloques de ACF y de plugins de terceros también se pueden ocultar?
Sí. Rootstuff lista todos los bloques registrados en la instalación de WordPress, incluyendo bloques de ACF, bloques de plugins activos y bloques del tema. No hay diferencia de tratamiento entre bloques core y de terceros: todos aparecen en la misma lista con sus checkboxes correspondientes.
¿Qué pasa cuando se instala un plugin nuevo que agrega bloques?
Los bloques nuevos quedan automáticamente permitidos para todos los roles. El sistema funciona por exclusión: solo están bloqueados los bloques que vos tildaste explícitamente. Esto evita que una actualización de plugin o un plugin nuevo rompa el acceso de usuarios que deberían poder usar esos bloques. Si querés ocultar el bloque nuevo, tenés que volver a la configuración y tildarlo.
¿Es posible limitar bloques sin escribir código en WordPress?
Sí, y Rootstuff Block Permissions es una de las opciones más directas para lograrlo gratis. Toda la configuración es mediante checkboxes en el panel de administración. No requiere PHP, no requiere hooks, no requiere editar el functions.php. Alternativas como Advanced Gutenberg o PublishPress Blocks también ofrecen configuración visual, pero las funciones más avanzadas de combinación de rol y tipo de contenido suelen estar en sus versiones pagas.
Conclusión
Rootstuff Block Permissions resuelve un problema real que cualquier agencia o desarrollador que entrega sitios WordPress a clientes conoce bien: el editor de bloques ofrece demasiado, y el cliente siempre encuentra la forma de romper algo. La solución hasta ahora era código custom, un plugin pesado, o aceptar el riesgo.
Lo que hace interesante a este plugin en 2026 es específicamente la combinación de rol + tipo de contenido en una sola regla, gratis, sin código. Eso es lo que la mayoría de las alternativas no logran sin pasar por caja. Para agencias que manejan múltiples proyectos con diferentes perfiles de usuario, el ahorro de tiempo en soporte post-entrega es concreto y medible.
Si tu sitio tiene un solo tipo de usuario y no necesitás granularidad por tipo de contenido, cualquier solución más simple te alcanza. Pero si manejás editores, autores, y clientes con necesidades distintas en distintas secciones del sitio, Rootstuff vale la instalación de diez minutos.
![[FREE] Rootstuff Block Permissions | Control Gutenberg blocks and patterns by role and post type - ilustracion](https://wordpress.donweb.com/wp-content/uploads/2026/05/rootstuff-block-permissions-control-permisos-bloques-gutenbe-hero-1024x576.jpg)



