← Alle indlæg
WordPress1. sep. 20264 min. læsetid

Sådan blokerer vi WordPress-cookies før samtykke

Katlas WordPress-plugin blokerer cookies før samtykke ved at holde scripts tilbage på serveren, før siden sendes. WooCommerce-checkout får lov at være.

Katla-teamet

Størstedelen af nettets problemer med cookie-compliance bor på WordPress. Det er også dér, flest samtykkebannere er installeret, og dér, et overraskende antal af dem ikke gør ret meget.

Vi har udgivet katla-app/wordpress, et plugin, der forbinder et WordPress- eller WooCommerce-website med Katla. Det indlæser samtykkescriptet, blokerer scripts og embeds uden samtykke på serveren og renderer de cookie- og privatlivspolitikker, som Katla genererer ud fra dine faktisk scannede cookies.

Problemet med at blokere i browseren

Katlas cookiespærre forhindrer cookies i at blive skrevet. Det er den rigtige byggesten, og på et håndbygget website er det som regel nok, fordi du selv bestemmer, hvilke scripts der er på siden.

WordPress er anderledes. Et tema sætter et script i kø. Tre plugins sætter fire mere i kø. En page builder indsætter en pixel. Når en besøgende indlæser siden, er der trackere på den, som ingen bevidst har tilføjet, og en tracker, der indlæses, har allerede sendt en forespørgsel til en tredjepart med en IP-adresse og en referrer, uanset om den nåede at sætte en cookie.

At blokere det i browseren er et kapløb, du ikke kan regne med at vinde. Samtykkescriptet skal køre, patche de rigtige globale variabler og neutralisere tagget, før tagget kører. Nogle gange lykkes det. Så ændrer et optimeringsplugin rækkefølgen af dine scripts, og så lykkes det ikke.

Så bloker det, før siden bliver sendt

Pluginet blokerer på serveren, mens WordPress stadig samler HTML’en. Knyt et script-handle til en kategori, på fanen Blocking eller i kode:

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

Det script, der når frem til browseren, er virkningsløst:

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

Der er intet kapløb, fordi den eksekverbare version aldrig fandtes i svaret.

Den detalje, vi går mest op i, er, hvad der sker med inline-scripts. Analysetags er sjældent én fil: der er en loader og derefter et inline gtag('config', …) eller et dataLayer-push, der er knyttet til samme handle via wp_add_inline_script. Blokeringsværktøjer, der kun håndterer src, har en tendens til at smide dem væk, og tagget kommer tilbage efter samtykke med forkert konfiguration eller slet ikke. Det her plugin neutraliserer inline-scripts sammen med deres handle og kører dem igen i kildekodens rækkefølge, når kategorien er tilladt, så tagget bliver genskabt præcis, som WordPress samlede det.

WooCommerce, hvor det er dyrt at ødelægge noget

Et samtykkeplugin i en webshop har en anden opgave, der betyder lige så meget som compliance: lad være med at ødelægge butikken. Bloker det forkerte handle, og kurven holder op med at opdatere, eller checkout fejler i stilhed, og det hører du om fra en kunde.

Derfor er WooCommerce-integrationen for det meste en liste over ting, pluginet nægter at gøre. Cookies til kurv, session og checkout går helt uden om spærren: woocommerce_cart_hash, wp_woocommerce_session_*, wc_fragments_* og deres venner. Butikskritiske handles som wc-cart-fragments, wc-checkout og wc-blocks-checkout fjernes fra blokeringslisten, så en skødesløs regel ikke kan lægge checkout ned. Pluginet erklærer kompatibilitet med HPOS og med kurv- og checkout-blokkene.

Én bevidst undtagelse: cookies til ordreattribution (sbjs_*) er ikke på tilladelseslisten. De er marketingcookies. Praktiske, ja, men marketing. Hvis du vil have dem væk før samtykke, så sæt handlet wc-order-attribution bag samtykke.

Tre niveauer af kontrol

Standardopsætningen kræver ingen kode: Katla renderer banneret og præferencedialogen, stylet fra dit dashboard.

Vil du hellere eje markuppen selv, indlæser headless-tilstand spærren og window.KatlaConsent uden den hostede UI, og pluginet renderer sit eget banner, oversat via WordPress og stylet med CSS custom properties, så det arver dit tema:

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

Eller slå UI’en helt fra, og byg din egen oven på window.KatlaConsent og eventet katla:consent. Den samme spærre ligger nedenunder i alle tre tilfælde.

Politikker, der faktisk står på siden

[katla_policy] renderer din genererede cookie- og privatlivspolitik på serveren som en del af sidens HTML. Ikke en iframe, ikke en hentning på klientsiden: rigtig markup, der kan indekseres, styles af dit tema og genereres igen ud fra dine cookies, efterhånden som de ændrer sig. Der er en Gutenberg-blok til hver shortcode, plus [katla_cookie_table], hvis du kun vil have tabellerne, og [katla_cookie_settings] til det link til at administrere præferencer, som din politikside alligevel skal have.

Kom i gang

Du skal bruge et verificeret Katla-website med mindst én gennemført scanning, fordi pluginet skal bruge cookiedata til at rendere politikkerne. Derefter:

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

Eller indsæt dit Site ID under Settings → Katla Consent.

Advarsel

Behold scriptets placering på Head, og undtag cdn.katla.app fra udskydelse eller sammenlægning af JS i optimeringsplugins. Cookiespærren skal køre før alt, der sætter cookies, og en udskudt spærre er den mest almindelige måde, et WordPress-website ender med at bryde reglerne på, mens det ser ud til at virke perfekt.

WordPress-guiden dækker shortcodes, filtre, WP-CLI-kommandoerne og det specifikke for WooCommerce, og siden om WordPress og WooCommerce har opsætningstrinnene og de spørgsmål, WordPress-teams stiller, før de skifter. Pluginet ligger på GitHub på katla-app/wordpress, og issues og pull requests er velkomne.