Los sitios web universitarios los publica prácticamente todo el mundo. Facultades, departamentos, admisiones, centros de investigación y servicios estudiantiles ponen páginas en línea, normalmente a través de docenas de colaboradores cuyo trabajo principal no es la web. Sin una ruta definida, esto genera erratas, páginas que no respetan la marca, información que nadie recordó retirar y, en ocasiones, algo sensible que aparece publicado antes de que nadie con autoridad lo haya leído.
Un flujo de trabajo de aprobación de contenido ofrece a cada página la misma ruta hacia el público. Comienza como borrador, espera a un revisor designado y se publica en cuanto ese revisor la aprueba. Drupal gestiona esto con dos módulos del núcleo y sin complementos de pago. Este artículo explica cómo encajan esos módulos entre sí, cómo dimensionar el proceso según la institución, qué cambia en sitios multilingües y los detalles de configuración que determinan si una cola de revisión sigue avanzando o se estanca silenciosamente.
Por qué la publicación universitaria necesita un paso de revisión
Una universidad es un editor grande y descentralizado, y esa combinación es precisamente lo que dificulta el control editorial. Hay colaboradores en cada facultad y unidad con niveles de formación web muy dispares, mientras que la comunicación central y TI siguen siendo responsables de la exactitud, la marca, la accesibilidad y, en páginas de admisiones o normativas, del riesgo legal y reputacional.
Las instituciones que gestionan los mayores patrimonios de Drupal en la educación superior están construidas precisamente en torno a este problema. Harvard, Yale, Stanford y Duke operan cada una su propia plataforma institucional de Drupal, con nombre propio, en la que publican los departamentos y grupos de investigación, en lugar de mantener una dispersión de sitios inconexos, y la propia documentación de la plataforma de Harvard enumera la publicación de contenido y la gestión de usuarios lado a lado como funciones esenciales. Cuando cientos de unidades comparten una sola plataforma, decidir quién puede publicar deja de ser un detalle y se convierte en la cuestión central de gobernanza de la plataforma.
El objetivo no es ralentizar a los colaboradores. Es permitir que un autor de una facultad que publica por primera vez redacte con libertad, mientras alguien con formación confirma que la página cumple los estándares antes de que la vea nadie ajeno a la institución.
Cómo funciona: Workflows y Content Moderation
Por defecto, una página de Drupal tiene dos estados, publicada o no publicada, lo cual no basta para describir un proceso de revisión. Dos módulos del núcleo lo amplían.
Workflows define los estados que puede ocupar el contenido y las transiciones entre ellos. Es la forma abstracta de su proceso, y nada más. Por sí solo no hace absolutamente nada, y si se instala en solitario aparece una pantalla que indica que no hay tipos de flujo de trabajo disponibles.
Content Moderation aporta ese tipo de flujo de trabajo. Vincula el flujo de trabajo a contenido real, como tipos de contenido específicos, y ata cada transición a su propio permiso, de modo que solo los roles previstos pueden avanzar una página.
Ambos son módulos del núcleo, y merece la pena conocer su historial de estabilización porque a menudo se relata de forma imprecisa. Content Moderation entró en el núcleo como módulo experimental en Drupal 8.2, y Workflows le siguió en la 8.3. Workflows se marcó como estable en la 8.4, mientras que Content Moderation seguía en beta, y Content Moderation alcanzó la estabilidad en Drupal 8.5.0. Content Moderation requiere Drupal 8.4 o posterior. En Drupal 10 y 11, ambos forman simplemente parte del núcleo y se habilitan desde la página Extender. La documentación oficial de Content Moderation explica paso a paso la configuración.
Estados, transiciones y los permisos que los hacen cumplir
Tres conceptos subyacen a todo flujo de trabajo de Drupal. Los estados son las condiciones que puede ocupar el contenido. Las transiciones son los movimientos permitidos entre ellos, y son direccionales, por lo que una página no puede saltar de borrador a archivada a menos que usted lo permita. Las revisiones son el historial versionado que subyace a todo ello. Drupal admite revisiones pendientes, lo que significa que un editor puede preparar una nueva versión de una página ya publicada sin que ese trabajo se muestre públicamente hasta que sea aprobado.
Los permisos son lo que convierte esto de un diagrama en un mecanismo de control real. Drupal crea un permiso independiente para cada transición, de modo que el derecho a usar la transición Publicar puede concederse a los revisores y negarse a los colaboradores. Ese único mecanismo constituye toda la cadena de aprobación.
Activar Content Moderation crea un flujo de trabajo Editorial por defecto que contiene Borrador, Publicado y Archivado. Un detalle sorprende a muchos: ese flujo de trabajo por defecto solo se crea automáticamente si el sitio se instaló a partir del perfil de instalación estándar. En un perfil mínimo o personalizado, hay que construirlo uno mismo.
Un conjunto de estados funcional para una universidad suele ampliar ligeramente el conjunto por defecto.
| Estado | Qué significa | Lo mueve a este estado |
|---|---|---|
| Borrador | Se está escribiendo o revisando, no visible para el público | Cualquier colaborador |
| Requiere revisión | Enviado y a la espera de un revisor | Cualquier colaborador |
| Requiere ajustes | Devuelto al autor con comentarios | Revisores |
| Publicado | Activo en el sitio | Revisores y administradores |
| Archivado | Retirado del sitio pero conservado | Administradores |
Una consecuencia del flujo de trabajo por defecto sorprende a la mayoría de los editores nuevos: no hay botón de despublicar. Para retirar una página activa, se pasa la revisión publicada al estado Archivado.
Dimensionar el flujo de trabajo para una universidad
En la práctica, una universidad traslada esto a un conjunto reducido de roles, no a uno amplio.
| Rol | Qué puede hacer | Habitualmente lo ocupa |
|---|---|---|
| Colaborador | Crea y edita borradores, envía contenido a revisión. Sin transición de publicación. | Personal de facultades y departamentos |
| Revisor | Revisa, edita, publica o devuelve contenido. Necesita permiso para ver contenido no publicado y la última versión. | Editores de facultad formados o equipo web central |
| Administrador | Todo lo que puede hacer un revisor, además de asignar roles y configurar flujos de trabajo. | TI central o comunicación |
El principio rector es el del privilegio mínimo. Quien mantiene páginas de asignaturas no necesita configuración del sitio ni gestión de usuarios, y mantener ese rol acotado protege a la plataforma en su conjunto.
Drupal permite varios flujos de trabajo en un mismo sitio, cada uno aplicado a distintos tipos de contenido, y es aquí donde el modelo se vuelve realmente útil a escala universitaria. Las páginas ordinarias de un departamento siguen la ruta corta. Las normativas de admisiones, los comunicados de prensa y los avisos legales pasan por un estado de aprobación adicional que las páginas ordinarias se saltan. Se aplica tanta supervisión como cada tipo de contenido realmente requiere, en lugar de forzar todo a través de un único proceso.
Este es el equivalente editorial de la gobernanza arquitectónica, y en patrimonios grandes ambos funcionan juntos. Nuestra guía sobre la gestión de sitios web universitarios con Drupal multisite cubre la mitad arquitectónica.
Sitios multilingües: revisar cada traducción por separado
Drupal 8.5 añadió soporte para moderar las traducciones de forma independiente, y en un sitio universitario bilingüe eso cambia la forma del proceso.
Cada traducción tiene su propio estado de moderación. La versión en inglés de una página puede estar publicada mientras otro idioma sigue en revisión, o al revés. Esto importa porque un único revisor rara vez tiene la competencia lingüística para aprobar todas las versiones, y un revisor que aprueba contenido que no puede leer del todo actúa como un mero sello burocrático, no como un control real.
Defina la titularidad de cada idioma antes de configurar nada. Decida quién revisa cada idioma y qué deberían ver los visitantes cuando una traducción está aprobada y otra no. La moderación independiente significa que una página puede estar legítimamente activa en un idioma y ausente en otro, así que confirme que el comportamiento de reserva (fallback) coincide con lo que pretende.
Detalles de configuración que estancan una cola de revisión
La mayoría de los flujos de trabajo de aprobación que fallan no fallan por su diseño. Fallan por pequeños detalles de configuración que dejan la cola invisible o inutilizable.
- Los revisores no pueden ver lo que se supone que deben revisar. Los permisos de transición por sí solos no bastan. Los revisores también necesitan permiso para ver la última versión y para ver cualquier contenido no publicado. Sin eso, la cola de revisión simplemente parece vacía.
- Los borradores se acumulan y se publican juntos. Las revisiones de borrador son acumulativas, así que cada una se construye sobre la anterior en lugar de ser independiente. Si varias personas guardan borradores de la misma página antes de que alguien la revise, publicar no libera solo uno de esos cambios. Los libera todos a la vez, algo fácil de pasar por alto en una página con más de un autor.
- El contenido no puede saltar directamente a revisión. Las transiciones son direccionales, así que, a menos que defina explícitamente un movimiento de Publicado a su estado de revisión, un colaborador que actualiza una página activa tiene que guardarla primero como borrador y enviarla después. Esa transición es fácil de omitir cuando el flujo de trabajo se diseña pensando en páginas nuevas y no en ediciones de páginas existentes.
- Nadie sabe que le toca actuar. Si se deja a la comprobación manual, el contenido permanece en revisión porque nadie notó su llegada. Content Moderation Notifications envía un correo a un rol elegido o al autor del contenido cada vez que una pieza cambia de estado, y se configura en /admin/config/workflow/notifications. Un panel que enumere todo lo que hay actualmente en curso cubre el resto.
- Los revisores siguen teniendo que iniciar sesión. Drupal solo muestra las revisiones no publicadas a los usuarios autenticados que tienen los permisos correctos, así que un flujo de trabajo que dependa de que un decano ocupado eche un vistazo a una página no funcionará como se diseñó.
Cuándo no merece la pena un flujo de trabajo de aprobación
La moderación existe para separar a las personas que crean contenido de las que lo aprueban. Cuando se trata de las mismas personas, añade fricción sin añadir supervisión.
Un sitio gestionado por uno o dos editores de confianza que tienen todos derechos de publicación no necesita uno, porque encauzar el propio trabajo a través de la propia cola ralentiza la publicación sin ningún beneficio. Un flujo de trabajo también se convierte en un lastre cuando la cadena es más larga de lo que la institución puede dotar de personal. Si una página debe pasar por varios aprobadores muy ocupados, la cola se convierte en un cuello de botella y los colaboradores empiezan a buscar formas de sortearla, lo que deja a la institución con menos control del que tenía antes.
El consejo que se sostiene en instituciones grandes es mantener la moderación tan sencilla como el riesgo realmente justifique. Empiece con los estados que de verdad necesita y añada uno nuevo solo cuando surja una necesidad editorial real, en lugar de construir proceso por el proceso mismo. Un flujo de trabajo que la gente rodea es peor que no tener ninguno.
Vale la pena conocer dos límites antes de comprometerse. La moderación se aplica solo a entidades con revisiones, lo que cubre nodos, tipos de bloque personalizados y términos de taxonomía, pero no todo lo que hay en un sitio. Y la decisión de plataforma subyace a todo esto; si esa cuestión sigue abierta, nuestra comparación de Drupal y WordPress para universidades explica dónde encaja cada uno.
Configurada con esa disciplina, la aprobación de contenido deja de ser una capa extra y pasa a formar parte del funcionamiento de la plataforma. Facultades y departamentos contribuyen ampliamente, y hay una comprobación fiable ante todo lo que llega al público. En Drupart, el equipo de Drupal4edu construye plataformas Drupal para universidades como la Universidad Sabancı, la METU y la Universidad Técnica de Yıldız, donde la aprobación editorial se apoya en el mismo fundamento del núcleo descrito aquí. Nuestro resumen sobre Drupal en el sector educativo profundiza en por qué ese fundamento encaja con la educación superior.
Preguntas frecuentes sobre la moderación de contenido en Drupal
¿La moderación de contenido forma parte del núcleo de Drupal?
Sí. Workflows y Content Moderation son ambos módulos del núcleo, se habilitan desde la página Extender y no hay nada que comprar ni descargar. Workflows se marcó como estable en Drupal 8.4 y Content Moderation en la 8.5.0, y Content Moderation requiere Drupal 8.4 o posterior. Extras opcionales como las notificaciones por correo electrónico y los paneles de moderación proceden de módulos contribuidos, pero la mecánica de aprobación en sí está integrada en Drupal.
¿Cuál es la diferencia entre un estado y una transición?
Un estado es una condición en la que puede estar el contenido, como Borrador, Requiere revisión, Publicado o Archivado. Una transición es un movimiento permitido de un estado a otro, como Publicar o Archivar. La distinción importa porque los permisos se vinculan a las transiciones y no a los estados. Se controla quién puede avanzar una página concediendo o denegando cada transición, de modo que los estados describen dónde se encuentra el contenido en cada momento, y las transiciones definen cómo, y por quién, llega al siguiente paso.
¿Pueden distintos tipos de contenido usar distintos flujos de trabajo?
Sí, y en un sitio universitario esta es una de las configuraciones más útiles que se pueden hacer. Puede crear varios flujos de trabajo y aplicar cada uno a distintos tipos de contenido. Una noticia de un departamento podría usar una ruta sencilla de borrador a publicado, mientras que una normativa de admisiones pasa por un estado de aprobación adicional. Así, cada tipo de contenido lleva solo la supervisión que realmente necesita.
¿Cómo despublico una página una vez activada la moderación?
Con el flujo de trabajo Editorial por defecto no existe una acción independiente de despublicar. En su lugar, se pasa la revisión publicada al estado Archivado, lo que elimina la página del sitio público a la vez que conserva intacto su historial de revisiones. Los editores acostumbrados a un simple interruptor de publicado suelen necesitar que se les señale esto una vez, y después se vuelve rutinario.
¿Cómo saben los revisores cuándo algo los está esperando?
A través de Content Moderation Notifications, un módulo contribuido que envía un correo electrónico cuando el contenido pasa entre estados. Puede notificar a todos los que tengan un rol de revisor o al autor del contenido, se configura en /admin/config/workflow/notifications y funciona junto con Content Moderation del núcleo. Combinado con un panel que muestra todo lo que hay actualmente en curso, evita que el contenido quede en revisión sin que nadie lo note.