Por que Drupal necesita unha arquitectura de consentimento deliberada

As fortalezas de Drupal e os seus riscos de consentimento proveñen do mesmo lugar. A flexibilidade editorial da plataforma, o acceso baseado en roles e o modelo de contido estruturado son exactamente o que converte en opción predeterminada para portais gobernamentais, sitios universitarios e propiedades web empresariais globais — os mesmos sitios que teñen máis probabilidades de ser auditados, que teñen os inventarios de etiquetas de terceiros máis diversos acumulados ao longo de anos de traballo de campaña, e que teñen a maior superficie de cookies non esenciais a controlar. Un sitio Drupal 10 típico que executa unha pila de análises, un píxel de automatización de mercadotecnia, un vídeo incrustado, un webform con reCAPTCHA e un widget de compartición social pode enviar máis dunha ducia de operacións de almacenamento non esenciais distintas nun único cargamento de páxina, moitas veces a través de módulos que o implementador orixinal xa non recorda ter configurado.

Cada unha desas operacións activa unha porta de consentimento separada. Baixo o Article 5(3) da Directiva ePrivacy, cada cookie non esencial ou operación análoga de almacenamento e acceso require consentimento previo, libremente dado, específico, informado e inequívoco no EEA, no UK e en calquera xurisdición que importara o mesmo estándar. Baixo o GDPR, os datos de comportamento que xeran esas operacións de almacenamento son procesamento de datos persoais porque a combinación de identificador de cookie, enderezo IP e rastro de comportamento é suficiente para distinguir un individuo. A cuestión de cumprimento nun sitio Drupal non é, polo tanto, se instalar un banner — cada equipo responsable xa o fixo —, senón se o banner realmente evita que as etiquetas se activen antes de que o usuario dese o seu consentimento, e se a decisión de consentimento sobrevive ás capas de caché de Drupal.

O panorama de módulos: EU Cookie Compliance, Klaro e as opcións integradas de provedores

O módulo EU Cookie Compliance — o módulo contribuído mantido en Drupal.org baixo ese nome — é o predeterminado histórico e a opción máis amplamente despregada. Ofrece un banner configurable, admite categorías, expón un estado de consentimento de JavaScript para que o código do tema do sitio se vincule e almacena os rexistros de consentimento na base de datos de Drupal. Os puntos fortes son a integración profunda co sistema de permisos e roles de Drupal, soporte multilingüe a través da capa de tradución de Drupal e a capacidade de bloquear as etiquetas renderizadas por Drupal por categoría no nivel de construción de páxina. Os puntos débiles son que a IU do banner está por detrás dos estándares de deseño que os reguladores esperan agora, que as etiquetas de categoría predeterminadas son vagas e que a interacción do módulo coas capas de caché de Drupal require configuración explícita.

O módulo Klaro Cookie & Consent Management é unha opción máis recente que integra a biblioteca JavaScript Klaro — un xestor de consentimento de código aberto cun moderno IU de banner e controis granulares por servizo. Os puntos fortes son a calidade da IU, a granularidade por servizo en lugar de por categoría e o desenvolvemento activo upstream. Os puntos débiles son que o módulo é máis delgado que EU Cookie Compliance, require máis esforzo de temática e empurra máis estado do consentimento ao cliente onde debe conciliarse co renderizado no lado do servidor de Drupal.

As opcións integradas de provedores — Cookiebot, OneTrust, Usercentrics e similares — son apropiadas cando o sitio forma parte dunha propiedade que xa estandarizou nun deses CMP a nivel organizativo. Adoitan ser as opcións máis sólidas en IU e rastro de auditoría, pero introducen unha dependencia de terceiros de pago e poden requirir un Acordo de Procesamento de Datos que pasa por un proceso de compra separado.

O problema de caché que derrota a maioría das implementacións de consentimento de Drupal

Este é o problema que afunde os sitios Drupal correctamente configurados noutros aspectos: o Internal Page Cache e o Dynamic Page Cache, funcionando como foron deseñados, servirán un renderizado de páxina almacenado en caché a un visitante que aínda non viu o banner, e o renderizado en caché pode incluír as etiquetas de script ou recursos externos que o banner supón bloquear. A solución non é desactivar o caché — iso desfai a razón pola que a maioría das empresas elixiron Drupal —, senón renderizar as etiquetas bloqueadas polo consentimento a través dun camiño que as capas de caché respecten.

O patrón de marcador de posición

O patrón que funciona en produción é renderizar cada etiqueta non esencial como un marcador de posición no HTML almacenado en caché — normalmente unha etiqueta <script type="text/plain"> cun atributo de categoría, ou un elemento personalizado que o JavaScript do módulo de consentimento activa só no lado do cliente despois de que se voltou a porta relevante. A propia páxina Drupal é almacenable en caché porque o marcador de posición é o mesmo para cada visitante; a lóxica de activación está no JavaScript do módulo de consentimento e execútase no momento da hidratación contra o estado de consentimento por visitante almacenado no navegador. EU Cookie Compliance admite este patrón de forma nativa; para Klaro o equivalente é o mecanismo de substitución de scripts por servizo que proporciona a biblioteca upstream.

As capas de caché de renderizado e varnish

O caché de renderizado de Drupal e calquera caché Varnish ou CDN upstream debe configurarse para variar segundo o estado do consentimento só cando o estado do consentimento cambia o HTML renderizado — o que, co patrón de marcador de posición, non sucede. O propio banner renderízase como un bloque almacenable en caché separado cun contexto que distingue «banner necesario» de «banner non necesario», e o resto da páxina renderízase de xeito idéntico independentemente do estado do consentimento. Esta é a elección arquitectónica que fai que as capas de caché de Drupal sexan compatibles cun despregamento centrado no consentimento. A alternativa — renderizar a páxina de xeito diferente por estado de consentimento e desactivar o caché para os usuarios que fixeron unha elección — é o que produce o comportamento de páxinas lentas tras a aceptación que leva aos usuarios a descartar banners.

Patróns de integración módulo a módulo

O traballo de integración nun sitio Drupal é principalmente sobre conectar o estado do consentimento aos módulos que emiten cookies non esenciais ou recursos externos. O patrón repítese no ecosistema de módulos contribuídos.

• O Google Analytics module e o Google Tag Manager module deben configurarse para renderizar as súas etiquetas como marcadores de posición bloqueados polo consentimento, coa categoría de consentimento asignada á porta analítica. Ambos os módulos expoñen un hook ao que o módulo EU Cookie Compliance pode conectarse.
• O Webform module con reCAPTCHA é a filtración sutil máis común: reCAPTCHA establece cookies non esenciais na carga incluso antes de que o usuario envíe o formulario. A solución é bloquear a biblioteca reCAPTCHA detrás da categoría funcional ou de mercadotecnia relevante, ou usar a variante invisible-v3 que apraza as escrituras de cookies ata o envío do formulario.
• Os vídeos incrustados do Media module de YouTube, Vimeo ou Brightcove deben usar o modo de privacidade mellorada ou estar envoltos nun marcador de posición de clic para cargar que apraza a solicitude de terceiros ata que o usuario o active. O patrón Lite YouTube Embed é o equivalente que varios temas de Drupal adoptaron.
• Os widgets de compartición social de provedores nativos son un patrón dos anos 2010 que debería retirarse en favor de ligazóns de compartición estáticas que non cargan JavaScript de terceiros. Se o widget do provedor debe permanecer, sitúase detrás da porta de mercadotecnia.
• Drupal Commerce e calquera cookie relacionado co carriño son estritamente necesarios e non requiren consentimento, pero os identificadores de programas de fidelidade, os cookies de motores de recomendación e os eventos de carriño vinculados ás análises requiren a porta adecuada.

Validación, rastro de auditoría e o aspecto multilingüe

O paso de validación nun sitio Drupal é a mesma secuencia de catro comprobacións que se aplica en todas partes: unha visita sen acción debe producir cero cookies non esenciais, unha visita de rexeitamento debe manter ese estado, unha visita de aceptación debe producir só as etiquetas consentidas, e unha retirada debe deter inmediatamente os disparos de etiquetas adicionais e expirar as cookies relevantes. En Drupal especificamente, esta validación debe realizarse co caché de páxina quente — non eludido — para confirmar que o patrón de marcador de posición está operando correctamente baixo condicións de tráfico realistas.

O rastro de auditoría en Drupal benefíciase das fortalezas da plataforma. EU Cookie Compliance almacena os rexistros de consentimento na base de datos con marcas temporais e estado de categoría; Klaro pode configurarse para facer o mesmo a través dun hook do lado de Drupal. Calquera dos camiños produce un rexistro de consentimento consultable ante o que pode responderse a solicitude dun regulador. O aspecto multilingüe tamén importa: a capa de tradución de Drupal estendese ao texto do banner de consentimento, polo que o aviso de privacidade e as etiquetas de categoría deben traducirse para cada idioma que sirve o sitio, e o rexistro de consentimento debe rexistrar que versión lingüística viu realmente o usuario. Un despregamento Drupal defendible en 2026 é aquel no que a elección do módulo, o patrón de caché, as integracións por módulo e o rastro de auditoría multilingüe foron considerados todos xuntos — e onde a elección de Drupal como plataforma subxacente foi transformada dunha responsabilidade de caché en unha vantaxe de consentimento.