Come blocchiamo i cookie WordPress prima del consenso

Buona parte del problema di conformità sui cookie del web vive su WordPress. È anche il posto in cui sono installati più banner del consenso, e dove un numero sorprendente di questi non fa granché.

Abbiamo pubblicato katla-app/wordpress, un plugin che collega un sito WordPress o WooCommerce a Katla. Carica lo script del consenso, blocca sul server gli script e gli embed senza consenso, e mostra la cookie policy e l’informativa sulla privacy che Katla genera dai cookie effettivamente trovati dalla scansione.

Il problema del blocco nel browser

Il blocco dei cookie di Katla impedisce che i cookie vengano scritti. È la primitiva giusta, e su un sito costruito a mano di solito basta, perché sei tu a decidere quali script stanno sulla pagina.

WordPress è diverso. Un tema accoda uno script. Tre plugin ne accodano altri quattro. Un page builder inserisce un pixel. Quando un visitatore carica la pagina, ci sono tracker che nessuno ha aggiunto di proposito, e un tracker che si carica ha già fatto una richiesta a una terza parte con un indirizzo IP e un referrer, che sia riuscito o no a impostare un cookie.

Bloccarlo nel browser è una gara che non vinci con certezza. Lo script del consenso deve eseguirsi, modificare le variabili globali giuste e neutralizzare il tag prima che il tag parta. A volte ci riesce. Poi un plugin di ottimizzazione riordina i tuoi script e non ci riesce più.

Quindi bloccalo prima che la pagina parta

Il plugin fa il blocco lato server, mentre WordPress sta ancora componendo l’HTML. Associa l’handle di uno script a una categoria, nella scheda Blocking o nel codice:

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

Lo script che arriva al browser è inerte:

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

Non c’è nessuna gara, perché la versione eseguibile non è mai esistita nella risposta.

Il dettaglio a cui teniamo di più è cosa succede agli script inline. I tag di analytics raramente sono un solo file: c’è un loader, poi un gtag('config', …) inline o un push nel dataLayer collegati allo stesso handle tramite wp_add_inline_script. I sistemi di blocco che gestiscono solo lo src tendono a perderli, e dopo il consenso il tag torna configurato male o non torna affatto. Questo plugin neutralizza gli script inline insieme al loro handle e li riesegue nell’ordine del sorgente quando la categoria viene consentita, così il tag viene ripristinato esattamente come WordPress l’aveva composto.

WooCommerce, dove rompere le cose costa caro

Su un negozio, un plugin di consenso ha un secondo compito che conta quanto la conformità: non rompere il negozio. Blocca l’handle sbagliato e il carrello smette di aggiornarsi, o il checkout fallisce senza avvisare, e lo scopri da un cliente.

Per questo l’integrazione con WooCommerce è soprattutto un elenco di cose che il plugin si rifiuta di fare. I cookie di carrello, sessione e checkout aggirano del tutto il blocco dei cookie: woocommerce_cart_hash, wp_woocommerce_session_*, wc_fragments_* e compagnia. Gli handle indispensabili al negozio, come wc-cart-fragments, wc-checkout e wc-blocks-checkout, vengono tolti dall’elenco dei bloccati, così una regola scritta con leggerezza non può mandare giù il checkout. Il plugin dichiara la compatibilità con HPOS e con i blocchi di carrello e checkout.

Un’eccezione voluta: i cookie di attribuzione degli ordini (sbjs_*) non sono in allowlist. Sono cookie di marketing, comodi, ma di marketing. Se vuoi che spariscano prima del consenso, subordina al consenso l’handle wc-order-attribution.

Tre livelli di controllo

La modalità predefinita non richiede codice: Katla mostra il banner e la finestra delle preferenze, con lo stile impostato dalla tua dashboard.

Se preferisci avere il controllo del markup, la modalità headless carica il blocco dei cookie e window.KatlaConsent senza l’interfaccia ospitata, e il plugin mostra il proprio banner, tradotto tramite WordPress e con lo stile definito da CSS custom properties, così eredita il tuo tema:

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

Oppure disattiva del tutto l’interfaccia e costruisci la tua su window.KatlaConsent e sull’evento katla:consent. Sotto, in tutti e tre i casi, c’è lo stesso blocco dei cookie.

Policy che stanno davvero sulla pagina

[katla_policy] mostra la cookie policy e l’informativa sulla privacy generate lato server, come parte dell’HTML della pagina. Non un iframe, non un fetch lato client: markup vero, indicizzabile, con lo stile del tuo tema, e rigenerato dai tuoi cookie man mano che cambiano. C’è un blocco Gutenberg per ogni shortcode, più [katla_cookie_table] se vuoi solo le tabelle e [katla_cookie_settings] per il link “gestisci preferenze” che la tua pagina della policy deve comunque avere.

Come iniziare

Ti serve un sito Katla verificato con almeno una scansione completata: il plugin ha bisogno dei dati dei cookie per mostrare le policy. Poi:

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

Oppure incolla il Site ID in Settings → Katla Consent.

La guida WordPress copre shortcode, filtri, comandi WP-CLI e i dettagli su WooCommerce, e la pagina WordPress e WooCommerce contiene i passaggi di configurazione e le domande che i team WordPress si fanno prima di cambiare. Il plugin è su GitHub all’indirizzo katla-app/wordpress: issue e pull request sono benvenute.