Jak blokujemy pliki cookie w WordPressie przed zgodą

Większość problemów internetu ze zgodnością plików cookie z przepisami mieszka na WordPressie. To tam zainstalowano też najwięcej banerów zgody i tam zaskakująco wiele z nich robi niewiele.

Opublikowaliśmy katla-app/wordpress, wtyczkę, która łączy stronę na WordPressie lub sklep na WooCommerce z Katlą. Ładuje skrypt zgody, blokuje skrypty i osadzone treści bez zgody na serwerze i renderuje politykę cookies i politykę prywatności, które Katla generuje z Twoich faktycznie zeskanowanych plików cookie.

Problem z blokowaniem w przeglądarce

Blokada cookies w Katli powstrzymuje pliki cookie przed zapisaniem. To właściwy mechanizm bazowy i na ręcznie zbudowanej stronie zwykle wystarcza, bo kontrolujesz, jakie skrypty są na stronie.

WordPress to co innego. Motyw dołącza skrypt. Trzy wtyczki dołączają kolejne cztery. Page builder wstrzykuje piksel. Zanim odwiedzający załaduje stronę, są na niej trackery, których nikt świadomie nie dodał, a tracker, który się załadował, wysłał już do strony trzeciej żądanie z adresem IP i refererem, niezależnie od tego, czy udało mu się ustawić plik cookie.

Blokowanie tego w przeglądarce to wyścig, którego nie wygrywasz z pewnością. Skrypt zgody musi się wykonać, podmienić właściwe obiekty globalne i zneutralizować tag, zanim tag się uruchomi. Czasem się udaje. Potem wtyczka optymalizacyjna zmienia kolejność skryptów i już się nie udaje.

Więc zablokuj to, zanim strona zostanie wysłana

Wtyczka blokuje po stronie serwera, gdy WordPress jeszcze składa HTML. Przypisz uchwyt skryptu do kategorii, w zakładce Blocking albo w kodzie:

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

Skrypt, który dociera do przeglądarki, jest nieaktywny:

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

Nie ma wyścigu, bo wykonywalna wersja nigdy nie istniała w odpowiedzi serwera.

Szczegół, na którym zależy nam najbardziej, to los skryptów inline. Tagi analityczne rzadko są jednym plikiem: jest loader, a potem inline’owe gtag('config', …) albo push do dataLayer dołączony do tego samego uchwytu przez wp_add_inline_script. Blokery, które obsługują tylko src, zwykle je gubią, a tag wraca po zgodzie źle skonfigurowany albo nie wraca wcale. Ta wtyczka neutralizuje skrypty inline razem z ich uchwytem i odtwarza je w kolejności ze źródła, gdy kategoria dostanie zgodę, więc tag wraca dokładnie w takiej postaci, w jakiej złożył go WordPress.

WooCommerce, gdzie psucie rzeczy słono kosztuje

Wtyczka do zgód w sklepie ma drugie zadanie, równie ważne jak zgodność z przepisami: nie psuć sklepu. Zablokuj niewłaściwy uchwyt, a koszyk przestanie się aktualizować albo kasa po cichu przestanie działać, i dowiesz się o tym od klienta.

Dlatego integracja z WooCommerce to głównie lista rzeczy, których wtyczka odmawia. Pliki cookie koszyka, sesji i kasy całkowicie omijają blokadę: woocommerce_cart_hash, wp_woocommerce_session_*, wc_fragments_* i podobne. Uchwyty krytyczne dla sklepu, takie jak wc-cart-fragments, wc-checkout i wc-blocks-checkout, są usuwane z listy blokowanych, więc nieostrożna reguła nie położy kasy. Wtyczka deklaruje zgodność z HPOS oraz z blokami koszyka i kasy.

Jeden celowy wyjątek: pliki cookie atrybucji zamówień (sbjs_*) nie są na liście dozwolonych. To marketingowe pliki cookie, wygodne, ale jednak marketingowe. Jeśli chcesz, żeby zniknęły przed zgodą, zablokuj uchwyt wc-order-attribution.

Trzy poziomy kontroli

Ustawienie domyślne nie wymaga kodu: Katla renderuje baner i okno preferencji, stylowane z poziomu Twojego panelu.

Jeśli wolisz mieć własny markup, tryb headless ładuje blokadę i window.KatlaConsent bez hostowanego interfejsu, a wtyczka renderuje własny baner, tłumaczony przez WordPressa i stylowany zmiennymi CSS, więc dziedziczy wygląd Twojego motywu:

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

Albo całkiem wyłącz interfejs i zbuduj własny na window.KatlaConsent i zdarzeniu katla:consent. We wszystkich trzech przypadkach pod spodem działa ta sama blokada.

Polityki, które naprawdę są na stronie

[katla_policy] renderuje wygenerowaną politykę cookies i politykę prywatności po stronie serwera, jako część HTML strony. Nie iframe, nie pobieranie po stronie klienta, tylko prawdziwy markup, indeksowalny, stylowany przez Twój motyw i generowany na nowo z Twoich plików cookie, gdy się zmieniają. Każdy shortcode ma swój blok Gutenberga, a do tego jest [katla_cookie_table], jeśli chcesz tylko tabel, oraz [katla_cookie_settings] dla linku „zarządzaj preferencjami”, którego Twoja strona z polityką i tak potrzebuje.

Pierwsze kroki

Potrzebujesz zweryfikowanej strony w Katli z co najmniej jednym ukończonym skanowaniem: wtyczka potrzebuje danych o plikach cookie, żeby renderować polityki. Następnie:

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

Albo wklej Site ID w Settings → Katla Consent.

Przewodnik po WordPressie opisuje shortcode’y, filtry, polecenia WP-CLI i szczegóły dotyczące WooCommerce, a strona o WordPressie i WooCommerce zawiera kroki konfiguracji i pytania, które zespoły pracujące z WordPressem zadają przed zmianą narzędzia. Wtyczka jest na GitHubie: katla-app/wordpress. Zgłoszenia i pull requesty mile widziane.