Zo blokkeren we WordPress-cookies vóór toestemming

Het grootste deel van het cookieprobleem van het web zit op WordPress. Daar zijn ook de meeste consentbanners geïnstalleerd, en een verrassend aantal daarvan doet niet zo veel.

We hebben katla-app/wordpress gepubliceerd, een plugin die een WordPress- of WooCommerce-site aan Katla koppelt. Hij laadt het consentscript, blokkeert scripts en embeds zonder toestemming op de server, en toont het cookie- en privacybeleid dat Katla genereert uit je echte, gescande cookies.

Het probleem met blokkeren in de browser

De cookieblokker van Katla voorkomt dat cookies worden geschreven. Dat is het juiste uitgangspunt, en op een zelfgebouwde site is het meestal genoeg, omdat je zelf bepaalt welke scripts er op de pagina staan.

WordPress is anders. Een thema laadt een script. Drie plugins laden er nog vier. Een pagebuilder injecteert een pixel. Tegen de tijd dat een bezoeker de pagina laadt, staan er trackers op die niemand bewust heeft toegevoegd, en een tracker die laadt, heeft al een verzoek met een IP-adres en een referrer naar een derde partij gestuurd, of hij er nu in slaagde een cookie te zetten of niet.

Dat in de browser blokkeren is een race die je niet betrouwbaar wint. Het consentscript moet draaien, de juiste globals patchen en de tag neutraliseren voordat de tag draait. Soms lukt dat. Dan herschikt een optimalisatieplugin je scripts en lukt het niet meer.

Blokkeer het dus voordat de pagina vertrekt

De plugin blokkeert op de server, terwijl WordPress de HTML nog opbouwt. Koppel een scripthandle aan een categorie, op het tabblad Blocking of in code:

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

Het script dat de browser bereikt, doet niets:

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

Er is geen race, omdat de uitvoerbare versie nooit in de response heeft gestaan.

Het detail waar we het meest om geven, is wat er met inline scripts gebeurt. Analyticstags zijn zelden één bestand: er is een loader, en dan een inline gtag('config', …) of een dataLayer-push die via wp_add_inline_script aan dezelfde handle hangt. Blokkers die alleen de src afhandelen, laten die vaak vallen, en de tag komt na toestemming verkeerd geconfigureerd terug, of helemaal niet. Deze plugin neutraliseert inline scripts samen met hun handle en speelt ze in de volgorde van de broncode opnieuw af zodra de categorie is toegestaan, zodat de tag precies wordt hersteld zoals WordPress hem had opgebouwd.

WooCommerce, waar dingen kapotmaken duur is

Een consentplugin in een webwinkel heeft een tweede taak die net zo belangrijk is als compliance: de winkel niet slopen. Blokkeer de verkeerde handle en de winkelwagen werkt niet meer bij, of de checkout faalt zonder foutmelding, en dat hoor je van een klant.

De WooCommerce-integratie is daarom vooral een lijst van dingen die de plugin weigert te doen. Winkelwagen-, sessie- en checkoutcookies omzeilen de cookieblokker volledig: woocommerce_cart_hash, wp_woocommerce_session_*, wc_fragments_* en consorten. Handles die de winkel nodig heeft, zoals wc-cart-fragments, wc-checkout en wc-blocks-checkout, worden van de blokkeerlijst gehaald, zodat een slordige regel de checkout niet kan platleggen. De plugin declareert compatibiliteit met HPOS en met de winkelwagen- en checkoutblokken.

Eén bewuste uitzondering: cookies voor orderattributie (sbjs_*) staan niet op de allowlist. Het zijn marketingcookies, handige, maar marketing. Wil je ze vóór toestemming weg, scherm dan de handle wc-order-attribution af.

Drie niveaus van controle

De standaard vraagt geen code: Katla rendert de banner en het voorkeurenvenster, gestyled vanuit je dashboard.

Wil je de markup liever zelf in handen hebben, dan laadt de headless modus de cookieblokker en window.KatlaConsent zonder de gehoste UI, en rendert de plugin zijn eigen banner: vertaald via WordPress en gestyled met CSS custom properties, zodat hij je thema overneemt:

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

Of zet de UI helemaal uit en bouw je eigen UI op window.KatlaConsent en het event katla:consent. In alle drie de gevallen zit dezelfde cookieblokker eronder.

Beleid dat echt op de pagina staat

[katla_policy] rendert je gegenereerde cookie- en privacybeleid op de server, als deel van de HTML van de pagina. Geen iframe, geen fetch aan de clientkant, maar echte markup: indexeerbaar, gestyled door je thema en opnieuw gegenereerd uit je cookies zodra die veranderen. Er is een Gutenberg-blok voor elke shortcode, plus [katla_cookie_table] als je alleen de tabellen wilt en [katla_cookie_settings] voor de link “voorkeuren beheren” die je beleidspagina toch al nodig heeft.

Aan de slag

Je hebt een geverifieerde Katla-site nodig met minstens één afgeronde scan: de plugin heeft cookiegegevens nodig om beleid te tonen. Dan:

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

Of plak de Site-ID in Settings → Katla Consent.

De WordPress-gids behandelt de shortcodes, de filters, de WP-CLI-commando’s en de details voor WooCommerce, en de pagina over WordPress en WooCommerce bevat de installatiestappen en de vragen die WordPress-teams stellen voordat ze overstappen. De plugin staat op GitHub op katla-app/wordpress: issues en pull requests zijn welkom.