Como bloqueamos cookies no WordPress antes do consentimento

A maior parte do problema de conformidade de cookies da web vive no WordPress. É também onde estão instalados mais banners de consentimento, e onde um número surpreendente deles não faz grande coisa.

Publicámos o katla-app/wordpress, um plugin que liga um site WordPress ou WooCommerce ao Katla. Carrega o script de consentimento, bloqueia no servidor os scripts e os conteúdos incorporados sem consentimento, e renderiza as políticas de cookies e de privacidade que o Katla gera a partir dos cookies realmente encontrados na análise.

O problema de bloquear no navegador

O bloqueador de cookies do Katla impede que os cookies sejam escritos. É a primitiva certa e, num site feito à mão, costuma chegar, porque é o próprio que controla que scripts estão na página.

O WordPress é diferente. Um tema coloca um script em fila. Três plugins colocam mais quatro. Um construtor de páginas injeta um píxel. Quando um visitante carrega a página, já lá estão rastreadores que ninguém adicionou deliberadamente, e um rastreador que carrega já fez um pedido a um terceiro com um endereço IP e um referrer, tenha ou não conseguido definir um cookie.

Bloquear isso no navegador é uma corrida que não se ganha de forma fiável. O script de consentimento tem de executar, alterar os globais certos e neutralizar a tag antes de a tag correr. Às vezes consegue. Depois, um plugin de otimização reordena os seus scripts e deixa de conseguir.

Então bloqueie antes de a página ser enviada

O plugin faz o bloqueio no servidor, enquanto o WordPress ainda está a montar o HTML. Associe um handle de script a uma categoria, no separador Blocking ou em código:

add_action( 'wp_enqueue_scripts', function () {
	katla_block_script( 'google-analytics', 'analytics' );
	katla_block_script( 'facebook-pixel', 'marketing' );
}, 20 );

O script que chega ao navegador é inerte:

<script type="text/plain" data-katla-src="…" data-katla-category="analytics"></script>

Não há corrida, porque a versão executável nunca existiu na resposta.

O pormenor com que mais nos preocupamos é o que acontece aos scripts inline. As tags de analítica raramente são um só ficheiro: há um loader e, depois, um gtag('config', …) inline ou um push para o dataLayer associado ao mesmo handle através de wp_add_inline_script. Os bloqueadores que só tratam do src tendem a descartá-los, e a tag volta depois do consentimento mal configurada, ou nem volta. Este plugin neutraliza os scripts inline juntamente com o respetivo handle e reprodu-los pela ordem do código-fonte assim que a categoria for autorizada, para que a tag seja reposta exatamente como o WordPress a montou.

WooCommerce, onde estragar coisas sai caro

Numa loja, um plugin de consentimento tem uma segunda tarefa tão importante como a conformidade: não estragar a loja. Bloqueie o handle errado e o carrinho deixa de atualizar, ou o checkout falha em silêncio, e fica a saber por um cliente.

Por isso, a integração com o WooCommerce é sobretudo uma lista de coisas que o plugin se recusa a fazer. Os cookies de carrinho, sessão e checkout contornam o bloqueador por completo: woocommerce_cart_hash, wp_woocommerce_session_*, wc_fragments_* e companhia. Os handles essenciais para a loja, como wc-cart-fragments, wc-checkout e wc-blocks-checkout, são retirados da lista de bloqueio, para que uma regra descuidada não consiga deitar abaixo o checkout. O plugin declara compatibilidade com HPOS e com os blocos de carrinho e checkout.

Uma exceção deliberada: os cookies de atribuição de encomendas (sbjs_*) não estão na lista de permissões. São cookies de marketing: práticos, mas de marketing. Se os quiser fora antes do consentimento, condicione o handle wc-order-attribution.

Três níveis de controlo

A opção predefinida não exige código: o Katla renderiza o banner e a janela de preferências, com o estilo definido no seu painel.

Se preferir ser dono do markup, o modo headless carrega o bloqueador e o window.KatlaConsent sem a interface alojada, e o plugin renderiza o seu próprio banner, traduzido através do WordPress e estilizado com propriedades personalizadas de CSS, para herdar o seu tema:

add_filter( 'katla_banner_css_vars', function () {
	return array(
		'katla-primary' => '#111111',
		'katla-radius'  => '0px',
		'katla-font'    => 'var(--wp--preset--font-family--body)',
	);
} );

Ou desligue a interface por completo e construa a sua sobre o window.KatlaConsent e o evento katla:consent. Nos três casos, o mesmo bloqueador por baixo.

Políticas que estão mesmo na página

O [katla_policy] renderiza a sua política de cookies e de privacidade gerada no servidor, como parte do HTML da página. Não é um iframe nem um pedido do lado do cliente: é markup real, indexável, estilizado pelo seu tema e gerado de novo a partir dos seus cookies à medida que mudam. Há um bloco Gutenberg para cada shortcode, além de [katla_cookie_table], se só quiser as tabelas, e de [katla_cookie_settings] para o link de gestão de preferências de que a sua página de política precisa de qualquer forma.

Começar

Precisa de um site verificado no Katla com pelo menos uma análise concluída, porque o plugin precisa dos dados dos cookies para renderizar as políticas. Depois:

wp plugin activate katla-consent
wp katla site-id 00000000-0000-0000-0000-000000000000
wp katla verify

Ou cole o Site ID em Settings → Katla Consent.

O guia de WordPress cobre os shortcodes, os filtros, os comandos WP-CLI e as especificidades do WooCommerce, e a página de WordPress e WooCommerce tem os passos de configuração e as perguntas que as equipas de WordPress fazem antes de mudar. O plugin está no GitHub em katla-app/wordpress: issues e pull requests são bem-vindos.