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.
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 verifyEller 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.