Så blockerar vi WordPress-cookies före samtycke

Det mesta av webbens problem med cookieregler finns på WordPress. Det är också där flest samtyckesbanners är installerade, och där förvånansvärt många av dem inte gör särskilt mycket.

Vi har publicerat katla-app/wordpress, ett plugin som kopplar en WordPress- eller WooCommerce-webbplats till Katla. Det laddar samtyckesskriptet, blockerar skript och inbäddningar utan samtycke på servern och renderar de cookie- och integritetspolicyer som Katla genererar från dina faktiska, skannade cookies.

Problemet med att blockera i webbläsaren

Katlas cookiespärr hindrar cookies från att skrivas. Det är rätt grundmekanism, och på en handbyggd webbplats räcker den oftast, eftersom du styr vilka skript som finns på sidan.

WordPress är annorlunda. Ett tema köar ett skript. Tre plugins köar fyra till. En sidbyggare injicerar en pixel. När en besökare laddar sidan finns det spårare på den som ingen medvetet har lagt dit, och en spårare som laddas har redan skickat en förfrågan till en tredje part med en IP-adress och en referrer, oavsett om den lyckades sätta en cookie eller inte.

Att blockera det i webbläsaren är en kapplöpning som du inte vinner varje gång. Samtyckesskriptet måste köras, patcha rätt globala objekt och oskadliggöra taggen innan taggen körs. Ibland lyckas det. Sedan flyttar ett optimeringsplugin om dina skript, och då lyckas det inte.

Så blockera det innan sidan skickas

Pluginet blockerar på serversidan, medan WordPress fortfarande sätter ihop HTML:en. Koppla en skript-handle till en kategori, på fliken Blocking eller i kod:

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

Skriptet som når webbläsaren är overksamt:

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

Det finns ingen kapplöpning, eftersom den körbara versionen aldrig fanns i svaret.

Detaljen vi bryr oss mest om är vad som händer med inline-skript. Analystaggar är sällan en enda fil: det finns en loader, och sedan ett inline-anrop gtag('config', …) eller en push till dataLayer som hänger på samma handle via wp_add_inline_script. Blockerare som bara hanterar src brukar tappa dem, och taggen kommer tillbaka efter samtycket felkonfigurerad eller inte alls. Det här pluginet oskadliggör inline-skript tillsammans med deras handle och spelar upp dem i källordning när kategorin tillåts, så att taggen återställs exakt som WordPress satte ihop den.

WooCommerce, där det är dyrt att förstöra saker

Ett samtyckesplugin i en butik har ett andra jobb som är lika viktigt som regelefterlevnaden: att inte förstöra butiken. Blockera fel handle så slutar varukorgen att uppdateras, eller så fallerar kassan i det tysta, och du får veta det av en kund.

Därför är WooCommerce-integrationen mest en lista över saker som pluginet vägrar att göra. Cookies för varukorg, session och kassa går helt förbi spärren: woocommerce_cart_hash, wp_woocommerce_session_*, wc_fragments_* och liknande. Handles som butiken är beroende av, som wc-cart-fragments, wc-checkout och wc-blocks-checkout, tas bort från blockeringslistan, så att en slarvig regel inte kan få ner kassan. Pluginet deklarerar kompatibilitet med HPOS och med blocken för varukorg och kassa.

Ett medvetet undantag: cookies för orderattribution (sbjs_*) är inte vitlistade. De är marknadsföringscookies, praktiska sådana, men marknadsföring. Vill du bli av med dem före samtycke, villkora handlen wc-order-attribution.

Tre nivåer av kontroll

Standardläget kräver ingen kod: Katla renderar bannern och inställningsdialogen, stylade från din dashboard.

Vill du hellre äga markupen laddar headless-läget spärren och window.KatlaConsent utan det hostade gränssnittet, och pluginet renderar en egen banner, översatt via WordPress och stylad med CSS custom properties, så att den ärver ditt 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 stäng av gränssnittet helt och bygg ditt eget mot window.KatlaConsent och händelsen katla:consent. Samma spärr ligger under i alla tre fallen.

Policyer som faktiskt finns på sidan

[katla_policy] renderar din genererade cookie- och integritetspolicy på servern, som en del av sidans HTML. Ingen iframe, ingen hämtning på klientsidan, utan riktig markup som kan indexeras, stylas av ditt tema och genereras om från dina cookies när de ändras. Det finns ett Gutenberg-block för varje shortcode, plus [katla_cookie_table] om du bara vill ha tabellerna och [katla_cookie_settings] för länken till cookieinställningarna som din policysida ändå behöver.

Kom igång

Du behöver en verifierad webbplats i Katla med minst en slutförd skanning, eftersom pluginet behöver cookiedata för att rendera policyer. Sedan:

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

Eller klistra in ditt Site ID under Settings → Katla Consent.

WordPress-guiden går igenom shortcodes, filter, WP-CLI-kommandon och det som är specifikt för WooCommerce, och sidan om WordPress och WooCommerce har installationsstegen och frågorna som WordPress-team ställer innan de byter. Pluginet finns på GitHub som katla-app/wordpress, och issues och pull requests är välkomna.