Por que o Drupal precisa de uma arquitetura de consentimento deliberada

Os pontos fortes do Drupal e seus riscos de consentimento vêm do mesmo lugar. A flexibilidade editorial da plataforma, o acesso baseado em funções e o modelo de conteúdo estruturado são exatamente o que a torna a escolha padrão para portais governamentais, sites universitários e propriedades web corporativas globais — os mesmos sites que têm maior probabilidade de serem auditados, que têm o inventário mais diversificado de tags de terceiros acumuladas ao longo de anos de trabalho de campanha, e que têm a maior superfície de cookies não essenciais para controlar. Um site Drupal 10 típico executando uma pilha de análise, um pixel de automação de marketing, um vídeo incorporado, um formulário web com reCAPTCHA e um widget de compartilhamento social pode enviar mais de uma dúzia de operações de armazenamento não essenciais distintas em um único carregamento de página, frequentemente por meio de módulos que o implementador original não se lembra mais de ter configurado.

Cada uma dessas operações aciona uma porta de consentimento separada. Sob o Article 5(3) da Diretiva ePrivacy, cada cookie não essencial ou operação análoga de armazenamento e acesso requer consentimento prévio, livremente dado, específico, informado e inequívoco no EEA, no Reino Unido e em qualquer jurisdição que tenha importado o mesmo padrão. Sob o GDPR, os dados comportamentais que essas operações de armazenamento geram são processamento de dados pessoais porque a combinação de identificador de cookie, endereço IP e rastro comportamental é suficiente para individualizar uma pessoa. A questão de conformidade em um site Drupal portanto não é se deve instalar um banner — toda equipe responsável já fez isso — mas se o banner realmente impede que as tags sejam acionadas antes que o usuário tenha consentido, e se a decisão de consentimento sobrevive às camadas de cache do Drupal.

O panorama dos módulos: EU Cookie Compliance, Klaro e as opções integradas de fornecedores

O módulo EU Cookie Compliance — o módulo contribuído mantido no Drupal.org com esse nome — é o padrão histórico e a opção mais amplamente implantada. Ele fornece um banner configurável, suporta categorias, expõe um estado de consentimento JavaScript para o código do tema do site vincular, e armazena registros de consentimento no banco de dados do Drupal. Os pontos fortes são a integração profunda com o sistema de permissões e funções do Drupal, suporte multilíngue por meio da camada de tradução do Drupal, e a capacidade de bloquear tags renderizadas pelo Drupal por categoria no nível de construção de página. Os pontos fracos são que a interface do banner fica atrás dos padrões de design que os reguladores agora esperam, que os rótulos de categoria padrão são vagos, e que a interação do módulo com as camadas de cache do Drupal requer configuração explícita.

O módulo Klaro Cookie & Consent Management é uma opção mais recente que integra a biblioteca JavaScript Klaro — um gerenciador de consentimento de código aberto com uma interface de banner moderna e controles granulares por serviço. Os pontos fortes são a qualidade da interface, a granularidade por serviço em vez de por categoria, e o desenvolvimento ativo upstream. Os pontos fracos são que o módulo é mais fino que o EU Cookie Compliance, requer mais esforço de tematização e empurra mais do estado de consentimento para o cliente onde ele deve ser reconciliado com a renderização do lado do servidor do Drupal.

As opções integradas de fornecedores — Cookiebot, OneTrust, Usercentrics e similares — são apropriadas quando o site faz parte de um portfólio que já padroniza em um desses CMP no nível da organização. Elas são tipicamente as opções mais fortes em interface e trilha de auditoria, mas introduzem uma dependência paga de terceiros e podem exigir um Acordo de Processamento de Dados que passa por uma trilha de aquisição separada.

A armadilha de cache que derrota a maioria das implementações de consentimento do Drupal

Este é o problema que afunda sites Drupal de outra forma corretamente configurados: o Internal Page Cache e o Dynamic Page Cache, funcionando como projetados, servirão uma renderização de página em cache para um visitante que ainda não viu o banner, e a renderização em cache pode incluir as tags de script ou recursos externos que o banner deveria bloquear. A solução não é desabilitar o cache — isso derrota o motivo pelo qual a maioria das empresas escolheu o Drupal — mas renderizar tags bloqueadas por consentimento por meio de um caminho que as camadas de cache respeitam.

O padrão de espaço reservado

O padrão que funciona em produção é renderizar cada tag não essencial como um espaço reservado no HTML em cache — tipicamente uma tag <script type="text/plain"> com um atributo de categoria, ou um elemento personalizado que o JavaScript do módulo de consentimento ativa somente no lado do cliente após a porta relevante ter sido acionada. A própria página do Drupal é cacheável porque o espaço reservado é o mesmo para cada visitante; a lógica de ativação está no JavaScript do módulo de consentimento e é executada no momento da hidratação contra o estado de consentimento por visitante armazenado no navegador. O EU Cookie Compliance suporta esse padrão imediatamente; para Klaro o equivalente é o mecanismo de substituição de script por serviço que a biblioteca upstream fornece.

As camadas de render-cache e Varnish

O cache de renderização do Drupal e qualquer cache Varnish ou CDN upstream devem ser configurados para variar no estado de consentimento somente quando o estado de consentimento altera o HTML renderizado — o que, com o padrão de espaço reservado, não ocorre. O próprio banner é renderizado como um bloco cacheável separado com um contexto que distingue "banner necessário" de "banner não necessário", e o restante da página é renderizado identicamente independentemente do estado de consentimento. Esta é a escolha arquitetural que torna as camadas de cache do Drupal compatíveis com uma implantação com consentimento em primeiro lugar. A alternativa — renderizar a página de forma diferente por estado de consentimento e desabilitar o cache para usuários que fizeram uma escolha — é o que produz o comportamento de páginas lentas após aceitação que leva os usuários a dispensar banners.

Padrões de integração módulo a módulo

O trabalho de integração em um site Drupal é em grande parte sobre conectar o estado de consentimento aos módulos que emitem cookies não essenciais ou recursos externos. O padrão se repete em todo o ecossistema de módulos contribuídos.

• Google Analytics module e Google Tag Manager module devem ser configurados para renderizar suas tags como espaços reservados bloqueados por consentimento, com a categoria de consentimento mapeada para a porta de análise. Ambos os módulos expõem um gancho que o módulo EU Cookie Compliance pode conectar.
• Webform module com reCAPTCHA é o vazamento sutil mais comum: o reCAPTCHA define cookies não essenciais no carregamento mesmo antes de o usuário enviar o formulário. A solução é bloquear a biblioteca reCAPTCHA atrás da categoria funcional ou de marketing relevante, ou usar a variante invisible-v3 que adia a gravação de cookies até o envio do formulário.
• Incorporações de vídeo do módulo Media do YouTube, Vimeo ou Brightcove devem usar o modo de privacidade aprimorada ou ser envoltas em um espaço reservado de clique para carregar que adia a solicitação de terceiros até que o usuário a ative. O padrão Lite YouTube Embed é o equivalente que vários temas Drupal adotaram.
• Widgets de compartilhamento social de fornecedores nativos são um padrão dos anos 2010 que deve ser aposentado em favor de links de compartilhamento estáticos que não carregam JavaScript de terceiros. Se o widget do fornecedor precisar permanecer, ele fica atrás da porta de marketing.
• Drupal Commerce e quaisquer cookies relacionados ao carrinho são estritamente necessários e não requerem consentimento, mas identificadores de programas de fidelidade, cookies de mecanismo de recomendação e eventos de carrinho vinculados a análise requerem a porta apropriada.

Validação, trilha de auditoria e o ângulo multilíngue

A etapa de validação em um site Drupal é a mesma sequência de quatro verificações que se aplica em qualquer lugar: uma visita sem ação deve produzir zero cookies não essenciais, uma visita de rejeição deve manter esse estado, uma visita de aceite deve produzir apenas as tags consentidas, e uma retirada deve parar imediatamente mais ativações de tags e expirar os cookies relevantes. Especificamente no Drupal, essa validação deve ser feita com o cache de página quente — não contornado — para confirmar que o padrão de espaço reservado está operando corretamente sob condições de tráfego realistas.

A trilha de auditoria no Drupal se beneficia dos pontos fortes da plataforma. O EU Cookie Compliance armazena registros de consentimento no banco de dados com carimbos de tempo e estado de categoria; o Klaro pode ser configurado para fazer o mesmo por meio de um gancho do lado do Drupal. Qualquer caminho produz um log de consentimento consultável que pode ser respondido a uma solicitação de regulador. O ângulo multilíngue também importa: a camada de tradução do Drupal se estende ao texto do banner de consentimento, portanto o aviso de privacidade e os rótulos de categoria devem ser traduzidos para cada idioma que o site serve, e o log de consentimento deve registrar qual versão de idioma o usuário realmente viu. Uma implantação defensável do Drupal em 2026 é aquela onde a escolha do módulo, o padrão de cache, as integrações por módulo e a trilha de auditoria multilíngue foram todas consideradas em conjunto — e onde a escolha do Drupal como plataforma subjacente foi transformada de uma responsabilidade de cache em uma vantagem de consentimento.