← Alle innlegg
WordPress1. sep. 20264 min lesetid

Slik blokkerer vi WordPress-cookies før samtykke

Katlas WordPress-plugin blokkerer cookies før samtykke ved å holde tilbake skript på serveren, før siden sendes. WooCommerce-kassen får være i fred.

Katla-teamet

Mesteparten av nettets problemer med samtykke til informasjonskapsler (cookies) bor på WordPress. Det er også der flest samtykkebannere er installert, og der overraskende mange av dem ikke gjør særlig mye.

Vi har publisert katla-app/wordpress, en plugin som kobler et WordPress- eller WooCommerce-nettsted til Katla. Den laster samtykkeskriptet, blokkerer skript og innebygd innhold uten samtykke på serveren, og rendrer cookie-erklæringen og personvernerklæringen som Katla genererer fra de faktiske, skannede cookiene dine.

Problemet med å blokkere i nettleseren

Katlas cookie-vakt hindrer at cookies blir skrevet. Det er den riktige byggesteinen, og på et håndbygd nettsted er det som regel nok, fordi du selv styrer hvilke skript som ligger på siden.

WordPress er annerledes. Et tema legger et skript i køen. Tre plugins legger til fire til. En sidebygger skyter inn en piksel. Når en besøkende laster siden, ligger det sporere der som ingen bevisst har lagt til, og en sporer som lastes, har allerede sendt en forespørsel til en tredjepart med IP-adresse og referrer, enten den klarte å sette en cookie eller ikke.

Å blokkere det i nettleseren er et kappløp du ikke vinner hver gang. Samtykkeskriptet må kjøre, patche de riktige globalene og nøytralisere taggen før taggen kjører. Noen ganger går det. Så endrer en optimaliseringsplugin rekkefølgen på skriptene dine, og da går det ikke.

Så blokker det før siden sendes

Pluginen blokkerer på serveren, mens WordPress fortsatt setter sammen HTML-en. Koble en skript-handle til en kategori, i fanen Blocking eller i kode:

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

Skriptet som når nettleseren, er uvirksomt:

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

Det finnes ikke noe kappløp, fordi den kjørbare versjonen aldri fantes i svaret.

Detaljen vi bryr oss mest om, er hva som skjer med inline-skript. Analysetagger er sjelden én fil: det er en loader, og så en inline gtag('config', …) eller en dataLayer-push knyttet til den samme handlen via wp_add_inline_script. Blokkere som bare håndterer src, har en tendens til å miste dem, og taggen kommer tilbake etter samtykke feilkonfigurert, eller ikke i det hele tatt. Denne pluginen nøytraliserer inline-skript sammen med handlen deres og spiller dem av i kilderekkefølge når kategorien er tillatt, så taggen gjenopprettes nøyaktig slik WordPress satte den sammen.

WooCommerce, der det koster å ødelegge ting

En samtykke-plugin i en nettbutikk har en jobb til som betyr like mye som etterlevelse: ikke ødelegg butikken. Blokker feil handle, og handlekurven slutter å oppdatere seg eller kassen feiler i det stille, og du får vite det fra en kunde.

Derfor er WooCommerce-integrasjonen stort sett en liste over ting pluginen nekter å gjøre. Cookies for handlekurv, økt og kasse går helt utenom vakten: woocommerce_cart_hash, wp_woocommerce_session_*, wc_fragments_* og lignende. Handles som butikken er avhengig av, som wc-cart-fragments, wc-checkout og wc-blocks-checkout, fjernes fra blokkeringslisten, så en uforsiktig regel ikke kan ta ned kassen. Pluginen erklærer kompatibilitet med HPOS og med blokkene for handlekurv og kasse.

Ett bevisst unntak: cookies for ordreattribusjon (sbjs_*) står ikke på tillatelseslisten. De er markedsføringscookies, praktiske, men likevel markedsføring. Vil du bli kvitt dem før samtykke, legger du handlen wc-order-attribution bak samtykke.

Tre nivåer av kontroll

Standardvalget krever ingen kode: Katla rendrer banneret og innstillingsdialogen, stylet fra dashbordet ditt.

Vil du heller eie markupen selv, laster headless-modus vakten og window.KatlaConsent uten det hostede grensesnittet, og pluginen rendrer sitt eget banner, oversatt via WordPress og stylet med CSS custom properties, så det arver temaet ditt:

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å av grensesnittet helt og bygg ditt eget mot window.KatlaConsent og hendelsen katla:consent. Den samme vakten ligger under i alle tre tilfellene.

Erklæringer som faktisk står på siden

[katla_policy] rendrer den genererte cookie-erklæringen og personvernerklæringen din på serveren, som en del av sidens HTML. Ikke en iframe, ikke en henting på klientsiden, men ekte markup, indekserbar, stylet av temaet ditt og generert på nytt fra cookiene dine når de endres. Det finnes en Gutenberg-blokk for hver kortkode, pluss [katla_cookie_table] hvis du bare vil ha tabellene, og [katla_cookie_settings] for lenken til å administrere innstillingene som personvernsiden din uansett trenger.

Kom i gang

Du trenger et verifisert nettsted i Katla med minst én fullført skanning, for pluginen trenger cookie-data for å rendre erklæringer. Deretter:

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

Eller lim inn Site ID under Settings → Katla Consent.

Advarsel

La skriptplasseringen stå på Head, og unnta cdn.katla.app fra utsetting eller sammenslåing av JS i optimaliseringsplugins. Cookie-vakten må kjøre før alt som setter cookies. En utsatt vakt er den vanligste måten et WordPress-nettsted ender opp med å bryte reglene på, mens alt ser ut til å fungere perfekt.

WordPress-guiden dekker kortkodene, filtrene, WP-CLI-kommandoene og detaljene for WooCommerce, og siden for WordPress og WooCommerce har oppsettstegene og spørsmålene WordPress-team stiller før de bytter. Pluginen ligger på GitHub på katla-app/wordpress, og issues og pull requests er velkomne.