Complianz + Polylang: Cookie Policy częściowo po angielsku — przyczyna i bezpieczny fix

Na pierwszy rzut oka wyglądało to jak zwykły problem z brakującym tłumaczeniem. Polska strona miała poprawny tytuł „Polityka plików cookie (UE)”, właściwy permalink i polski link z bannera Complianz. Sam wygenerowany dokument zaczynał się jednak po angielsku: Introduction, What are cookies?, What are scripts? i kolejne akapity pozostawały w języku angielskim.

Co ważniejsze, dokument nie był angielski w całości. W dalszej części pojawiały się polskie etykiety, nazwy funkcji i opisy usług, po czym główna treść znów wracała do angielskiego. Ten mieszany wynik okazał się najważniejszą wskazówką w całej diagnostyce.

W moim przypadku nie pomogło czyszczenie cache, ponowne sprawdzanie locale ani szukanie całej treści dokumentu w Polylang → String translations. Przyczyna była głębiej: Complianz budował główne elementy dokumentu zanim Polylang w trybie The language is set from content ustalał język bieżącej strony.

Rozwiązaniem nie była edycja plików Complianz ani odłączenie dokumentu od synchronizacji. Zastosowałem wąski MU-plugin, który po ustaleniu języka przez Polylang bezpiecznie odbudowuje tylko zsynchronizowaną Cookie Policy (EU) dla PL i DE. Po wdrożeniu test produkcyjny zakończył się wynikiem PL PASS / DE PASS / EN PASS.

Ważne: to jest opis rzeczywistego compatibility case’u i przetestowanego workaroundu, a nie oficjalny patch Complianz lub Polylang. Kod ma celowo wąski zakres i nie należy stosować go automatycznie do każdej wielojęzycznej instalacji.

Objaw: język strony był poprawny, język dokumentu nie

Strona działa w trzech językach. Angielski jest językiem domyślnym Polylang, a polski i niemiecki są powiązanymi tłumaczeniami.

W chwili diagnozy środowisko wyglądało tak:

• WordPress 7.1;
• PHP 8.5.7;
• Complianz 7.5.4;
• Polylang w trybie The language is set from content;
• locale: en_US, de_DE, pl_PL;
• EN jako język domyślny;
• dokument pozostawiony w trybie Synchronize document with Complianz.

Angielska Cookie Policy (EU) działała normalnie. Następnie utworzyłem w Polylang powiązaną stronę polską. Jej tytuł był polski, a po publikacji Page ID 2453 działała pod adresem /polityka-plikow-cookie-ue/. Banner również prowadził do właściwej polskiej strony.

Problem był wewnątrz dokumentu: większość głównych nagłówków i akapitów nadal była po angielsku.

Analogiczny test wersji niemieckiej dał ten sam wzorzec. Tytuł i kontekst językowy strony były niemieckie, ale główna część zsynchronizowanego dokumentu pozostawała po angielsku.

Najważniejsza wskazówka: dokument był tylko częściowo po angielsku

Gdyby brakowało całego pakietu językowego, spodziewałbym się raczej konsekwentnie angielskiego dokumentu. Tutaj było inaczej.

W sekcji z wykrytymi usługami można było zobaczyć polskie elementy takie jak:

• Używanie;
• Udostępnianie danych;
• Nazwa;
• Wygaśnięcie;
• Funkcja;
• polskie klasyfikacje usług.

Jednocześnie otaczające je nagłówki i akapity, np. Placed cookies, Consent czy kolejne fragmenty tekstu prawnego, pozostawały angielskie.

To był bardzo charakterystyczny objaw. Oznaczał, że nie wszystkie fragmenty dokumentu powstają w tym samym momencie requestu. Część danych była renderowana później i widziała już właściwy locale PL, podczas gdy główne elementy dokumentu zostały przetłumaczone wcześniej i zachowały EN.

Ta obserwacja później dokładnie zgodziła się z kodem Complianz.

Co sprawdziłem przed analizą kodu

Zanim zacząłem szukać problemu w hookach WordPressa, wykluczyłem bardziej oczywiste przyczyny.

1. Locale Polylang

Konfiguracja języków była prawidłowa:

• English → en_US — język domyślny;
• Deutsch → de_DE;
• Polski → pl_PL.

Nie było więc prostego błędu typu pl zamiast pl_PL albo niepoprawnie przypisanego języka strony.

2. Fizyczne pliki tłumaczeń Complianz

Na serwerze sprawdziłem wp-content/languages/plugins/. Polskie i niemieckie zasoby Complianz rzeczywiście istniały, m.in. pliki odpowiadające complianz-gdpr-pl_PL.* oraz complianz-gdpr-de_DE.*.

To wykluczyło najprostszy scenariusz: „WordPress nie pobrał tłumaczenia wtyczki”.

3. Cache

Cache był wiarygodnym podejrzanym, bo wcześniej osobny problem z tekstem bannera wyglądał jak opóźniona/stara wersja. W przypadku legal document zrobiłem jednak purge dostępnych warstw cache i wzorzec pozostał taki sam zarówno dla PL, jak i DE.

Dlatego tego konkretnego problemu nie klasyfikuję jako błędu cache.

4. Polylang String translations

Polylang → String translations jest właściwym miejscem dla części tekstów bannera i własnych stringów. Nie znalazłem tam jednak głównej treści generated Cookie Policy, np. całych akapitów Introduction czy What are cookies?.

Ręczne przepisywanie kompletnego dokumentu do String translations nie byłoby właściwym rozwiązaniem.

5. Synchronizacja dokumentu

Blok Complianz był nadal ustawiony na:

Synchronize document with Complianz

Nie wybrałem Edit document and stop synchronization jako sposobu naprawy. Ręczne odłączenie dokumentu pozwoliłoby zmienić treść, ale odbiera jedną z głównych zalet generated legal document: dalszą synchronizację z Complianz.

Krótki fałszywy alarm: 404 przy pierwszym teście

Podczas pierwszego testu polski link prowadził do /?page_id=2453, a anonimowy frontend zwracał 404. To nie był element właściwego błędu tłumaczenia.

Strona PL miała wtedy status Draft, więc publiczny 404 był oczekiwanym zachowaniem WordPressa. Po publikacji routing działał poprawnie i strona otrzymała permalink /polityka-plikow-cookie-ue/. Dopiero wtedy było widać właściwy problem: poprawna polska strona, ale angielski body dokumentu.

To drobny detal, ale przy debugowaniu WordPressa warto oddzielać problemy routingu/statusu wpisu od problemów renderowania treści.

Source audit: gdzie naprawdę powstaje Cookie Policy

Po wykluczeniu locale, translation files, cache i String translations przejrzałem dokładne pliki produkcyjnego Complianz 7.5.4. Kluczowe były cztery miejsca.

gutenberg/block.php

Render callback bloku complianz/document nie buduje sam tłumaczenia. Dla zsynchronizowanego dokumentu sprowadza się do wywołania:

$html = COMPLIANZ::$document->get_document_html( $type, $region );

Czyli sam blok Gutenberga nie ustawia locale i nie odtwarza głównych stringów.

documents/class-document.php

get_document_html() pobiera wcześniej przygotowaną tablicę:

$elements = COMPLIANZ::$config->pages[ $region ][ $type ]["document_elements"];

Potem przechodzi po tych elementach i renderuje ich nagłówki oraz treść. Jeśli element ma callback, callback jest wykonywany podczas tej późniejszej fazy renderowania.

To wyjaśnia, dlaczego wynik mógł być mieszany: część zwykłych elementów była już gotowa, ale niektóre fragmenty dynamiczne wykonywały się później.

config/class-config.php

Tutaj pojawiła się kluczowa różnica czasu.

load_documents() ładuje pliki dokumentów, a następnie filtruje utworzone document_elements. W produkcyjnym kodzie ta procedura jest rejestrowana na WordPressowym init.

config/documents/cookie-policy-eu.php

W tym pliku główne elementy EU Cookie Policy są tworzone bezpośrednio podczas include. Przykładowo nagłówek:

_x(
    'Introduction',
    'Legal document cookie policy:paragraph title',
    'complianz-gdpr'
)

jest wykonywany od razu, a wynik trafia do document_elements.

To znaczy, że jeśli w tym momencie aktywny locale jest jeszcze angielski, w tablicy zostanie już zapisane Introduction. Późniejsza zmiana języka requestu nie cofnie czasu i nie przetłumaczy automatycznie istniejącej wartości w tablicy.

Druga połowa układanki: kiedy Polylang ustala język

Dokumentacja developerska Polylang rozróżnia dwa scenariusze. W używanym przeze mnie trybie The language is set from content Polylang musi poczekać na informację wynikającą z aktualnej treści i definiuje język dopiero na akcji WordPress wp z priority 5.

Dokumentacja Polylang ostrzega też autorów wtyczek, aby w tym trybie nie próbowali tłumaczyć stringów przed wykonaniem wp.

W mojej konfiguracji kolejność wyglądała więc w uproszczeniu tak:

WordPress init
    ↓
Complianz load_documents()
    ↓
cookie-policy-eu.php wykonuje _x()/__()
    ↓
document_elements powstają jeszcze jako EN
    ↓
WordPress wp, priority 5
    ↓
Polylang ustala finalny język PL lub DE
    ↓
Complianz renderuje wcześniej przygotowane document_elements
    ↓
część callbacków wykonywana później widzi już PL/DE

I właśnie dlatego otrzymywałem tak dziwny wynik: główna treść po angielsku, ale część dynamicznych elementów poprawnie po polsku lub niemiecku.

Rozwiązanie: wąski MU-plugin zamiast edycji Complianz

Mógłbym zmodyfikować pliki Complianz, ale byłby to zły kierunek. Update wtyczki nadpisałby zmianę, a późniejsze porównanie własnego forka z upstreamem stałoby się niepotrzebnie trudne.

Nie chciałem również przebudowywać całej architektury URL Polylang tylko z powodu jednego compatibility edge case’u. Tryb The language is set from content pozostaje świadomą częścią konfiguracji tej strony.

Finalnym rozwiązaniem został więc osobny MU-plugin:

wp-content/mu-plugins/bybrzoza-complianz-polylang-legal-i18n-fix.php

Workaround uruchamia się na:

add_action(
    'wp',
    'bybrzoza_cmplz_polylang_relocalize_cookie_policy',
    20
);

Priority 20 jest celowe: kod wykonuje się po udokumentowanym punkcie wp/5, w którym Polylang w tym trybie ustala język.

Plugin nie próbuje przełączać języka samodzielnie. Najpierw sprawdza, czy Polylang i WordPress już zgadzają się co do aktywnego locale, a dopiero potem — pod szeregiem dodatkowych warunków — odbudowuje konkretne document_elements.

Dlaczego workaround ma tyle guardrails

Najłatwiejsza wersja takiej poprawki mogłaby po prostu ponownie includować cookie-policy-eu.php na każdym requestcie. Celowo tego nie zrobiłem.

Fix 0.1.0 działa tylko wtedy, gdy spełnione są wszystkie istotne warunki:

• request jest frontendowy;
• to zwykła strona WordPressa;
• aktywne są Polylang i Complianz;
• istnieją wymagane stałe i obiekty Complianz;
• Complianz ma wersję >= 7.5.4 i < 8.0.0;
• bieżący locale Polylang jest identyczny z locale WordPressa;
• locale to dokładnie pl_PL lub de_DE;
• strona jest dokumentem typu cookie-statement;
• region dokumentu to eu;
• istnieje oczekiwana struktura document_elements;
• bieżący pierwszy nagłówek ma dokładnie broken state Introduction;
• _x() wykonane już po ustaleniu języka rzeczywiście zwraca inne, poprawne tłumaczenie.

Jeśli dokument jest już prawidłowo przetłumaczony, plugin robi no-op. To ważne również na przyszłość: gdy upstream sam naprawi kolejność ładowania, workaround nie powinien na siłę przebudowywać poprawnego dokumentu.

Po ponownym include kod ponownie stosuje filtr cmplz_document_elements, tak jak robi to standardowa ścieżka Complianz. Następnie sprawdza wynik. Jeśli nowy stan nie odpowiada oczekiwanemu tłumaczeniu albo wystąpi wyjątek, przywraca request-local oryginalne elementy i kończy działanie.

Nie ma żadnego zapisu do bazy danych.

<?php
/**
 * Plugin Name: byBrzoza Complianz + Polylang Legal i18n Fix
 * Description: Narrow compatibility fix for Complianz legal-document translations when Polylang uses “The language is set from content”.
 * Version: 0.1.0
 * Author: byBrzoza
 */

defined( 'ABSPATH' ) || exit;

/**
 * Rebuild the synchronized EU Cookie Policy after Polylang has selected the
 * language from the current page content.
 *
 * Why this exists:
 * - Polylang's content-based language mode defines the language on `wp`
 *   (priority 5).
 * - Complianz 7.5.4 loads/translates cookie-policy-eu.php earlier, on `init`.
 * - The resulting document_elements can therefore be frozen in the default
 *   locale (EN), while later callback-driven sections render in PL/DE.
 *
 * Safety / update behavior:
 * - front end only;
 * - only synchronized EU Cookie Policy pages;
 * - only pl_PL and de_DE;
 * - only if the current main heading is exactly the broken EN value
 *   "Introduction";
 * - self-noops if Complianz/upstream already renders the correct translation;
 * - guards Complianz version and internal structure and does nothing on an
 *   unexpected state;
 * - no database writes and no vendor-file modifications.
 */
function bybrzoza_cmplz_polylang_relocalize_cookie_policy(): void {
	static $done = false;

	if ( $done ) {
		return;
	}
	$done = true;

	if ( is_admin() || wp_doing_ajax() || wp_doing_cron() || ( defined( 'REST_REQUEST' ) && REST_REQUEST ) ) {
		return;
	}

	if ( ! function_exists( 'pll_current_language' ) || ! class_exists( 'COMPLIANZ' ) ) {
		return;
	}

	if ( ! defined( 'CMPLZ_VERSION' ) || ! defined( 'CMPLZ_PATH' ) ) {
		return;
	}

	if ( ! isset( COMPLIANZ::$config, COMPLIANZ::$document ) ) {
		return;
	}

	// Tested against Complianz 7.5.4. Allow 7.x updates only while the guarded
	// internal structure still matches; stop automatically at the next major.
	$cmplz_version = strtok( (string) CMPLZ_VERSION, '#' );
	if ( version_compare( $cmplz_version, '7.5.4', '<' ) || version_compare( $cmplz_version, '8.0.0', '>=' ) ) {
		return;
	}

	if ( ! is_page() ) {
		return;
	}

	global $post;
	if ( ! ( $post instanceof WP_Post ) ) {
		return;
	}

	// Ensure Polylang and WordPress agree on the active locale at this point.
	$pll_locale = pll_current_language( 'locale' );
	$wp_locale  = get_locale();
	if ( ! is_string( $pll_locale ) || $pll_locale === '' || $pll_locale !== $wp_locale ) {
		return;
	}

	if ( ! in_array( $wp_locale, array( 'pl_PL', 'de_DE' ), true ) ) {
		return;
	}

	if ( ! method_exists( COMPLIANZ::$document, 'get_document_data' ) ) {
		return;
	}

	$document_data = COMPLIANZ::$document->get_document_data( $post->ID );
	if ( ! is_array( $document_data ) || ( $document_data['type'] ?? '' ) !== 'cookie-statement' ) {
		return;
	}

	$region = $document_data['region'] ?? false;
	if ( ! $region && function_exists( 'cmplz_get_region_from_legacy_type' ) ) {
		$region = cmplz_get_region_from_legacy_type( 'cookie-statement' );
	}
	if ( $region !== 'eu' ) {
		return;
	}

	$pages = COMPLIANZ::$config->pages;
	if ( ! isset( $pages['eu']['cookie-statement']['document_elements'] ) || ! is_array( $pages['eu']['cookie-statement']['document_elements'] ) ) {
		return;
	}

	$original_elements = $pages['eu']['cookie-statement']['document_elements'];
	$current_intro     = bybrzoza_cmplz_find_first_document_title( $original_elements );
	$expected_intro    = _x( 'Introduction', 'Legal document cookie policy:paragraph title', 'complianz-gdpr' );

	// Missing/failed translation: fail closed rather than rewriting anything.
	if ( ! is_string( $expected_intro ) || $expected_intro === '' || $expected_intro === 'Introduction' ) {
		return;
	}

	// Upstream/another integration already fixed it: no-op.
	if ( $current_intro === $expected_intro ) {
		return;
	}

	// Do not overwrite a custom/unknown document state.
	if ( $current_intro !== 'Introduction' ) {
		return;
	}

	$document_file = trailingslashit( CMPLZ_PATH ) . 'config/documents/cookie-policy-eu.php';
	if ( ! is_readable( $document_file ) ) {
		return;
	}

	$reload = function ( string $file ): bool {
		include $file;

		if ( ! isset( $this->pages['eu']['cookie-statement']['document_elements'] ) || ! is_array( $this->pages['eu']['cookie-statement']['document_elements'] ) ) {
			return false;
		}

		// Mirror Complianz::load_documents() so integrations using this official
		// filter are preserved on the rebuilt element set.
		$this->pages['eu']['cookie-statement']['document_elements'] = apply_filters(
			'cmplz_document_elements',
			$this->pages['eu']['cookie-statement']['document_elements'],
			'eu',
			'cookie-statement',
			$this->fields
		);

		return true;
	};

	$restore = function ( array $elements ): void {
		$this->pages['eu']['cookie-statement']['document_elements'] = $elements;
	};

	try {
		$loaded = $reload->call( COMPLIANZ::$config, $document_file );
		if ( ! $loaded ) {
			$restore->call( COMPLIANZ::$config, $original_elements );
			return;
		}

		$pages_after = COMPLIANZ::$config->pages;
		$new_elements = $pages_after['eu']['cookie-statement']['document_elements'] ?? array();
		$new_intro    = is_array( $new_elements ) ? bybrzoza_cmplz_find_first_document_title( $new_elements ) : null;

		if ( $new_intro !== $expected_intro ) {
			$restore->call( COMPLIANZ::$config, $original_elements );
		}
	} catch ( Throwable $e ) {
		// Front-end availability wins over the workaround. Restore the exact
		// request-local original state and fail closed without exposing details.
		$restore->call( COMPLIANZ::$config, $original_elements );
	}
}

/**
 * Return the first non-empty document title.
 *
 * @param array $elements Complianz document elements.
 * @return string|null
 */
function bybrzoza_cmplz_find_first_document_title( array $elements ): ?string {
	foreach ( $elements as $element ) {
		if ( is_array( $element ) && isset( $element['title'] ) && is_string( $element['title'] ) && $element['title'] !== '' ) {
			return $element['title'];
		}
	}
	return null;
}

// In Polylang's "language from content" mode the locale is defined on `wp`
// at priority 5. Running later avoids changing the site's URL architecture.
add_action( 'wp', 'bybrzoza_cmplz_polylang_relocalize_cookie_policy', 20 );

Instalacja krok po kroku

Przed wdrożeniem zrobiłem to jak zwykłą zmianę produkcyjną, a nie jak snippet wklejany „na próbę”.

1. Backup. Upewnij się, że masz aktualną kopię plików i bazy albo potwierdzony, odtwarzalny backup.
2. Katalog MU-pluginów. Sprawdź, czy istnieje wp-content/mu-plugins/. Jeśli nie, utwórz go.
3. Wgraj jeden plik. Umieść bybrzoza-complianz-polylang-legal-i18n-fix.php bezpośrednio w wp-content/mu-plugins/.
4. Nie modyfikuj Complianz ani Polylang. Workaround nie wymaga edycji ich plików.
5. Wyczyść aktywny page cache. Nie zakładaj jednak, że sam purge naprawia bug — tutaj chodzi tylko o usunięcie starego wygenerowanego HTML po zmianie kodu.
6. Sprawdź PL. Polska Cookie Policy powinna mieć polski tytuł i polską główną treść.
7. Sprawdź DE. Analogicznie zweryfikuj niemiecką wersję.
8. Sprawdź EN regression. Angielska bazowa /cookie-policy-eu/ musi pozostać po angielsku.
9. Sprawdź link z bannera i relacje Polylang. Fix nie powinien zmieniać routingu ani powiązań tłumaczeń.

W moim wdrożeniu finalny runtime test dał:

PL: PASS
DE: PASS
EN regression: PASS

Dlaczego nie zmieniłem Site Language ani sposobu URL Polylang

W internecie można znaleźć porady, żeby przy problemach z tłumaczeniem legal documents zmieniać główny język WordPressa albo przechodzić na URL-e z prefiksem języka.

To może być sensowna decyzja architektoniczna na innej stronie, ale nie jest neutralnym „fixem” jednego dokumentu. Zmiana sposobu określania języka wpływa na całą wielojęzyczną witrynę: routing, istniejące adresy, SEO, canonical, hreflang i przełącznik języka.

W tym przypadku zależało mi na zachowaniu istniejącego trybu The language is set from content, więc rozwiązanie zostało ograniczone do konkretnego konfliktu czasu wykonania Complianz/Polylang.

Podobnie nie zmieniłem WordPress Site Language tylko po to, aby wymusić polski lub niemiecki tekst. EN jest prawidłowym językiem domyślnym tej instalacji.

Rollback

Rollback jest prosty właśnie dlatego, że workaround nie modyfikuje vendor files i nie zapisuje niczego do DB.

1. Usuń:

wp-content/mu-plugins/bybrzoza-complianz-polylang-legal-i18n-fix.php

2. Wyczyść aktywny page cache.

To wszystko. Nie ma osobnego rollbacku bazy danych.

Po usunięciu fixu wraca standardowe zachowanie aktualnego Complianz/Polylang.

Co po aktualizacji Complianz lub Polylang

MU-plugin nie zostanie nadpisany przez normalny update obu wtyczek, ale to nie oznacza wiecznej kompatybilności z ich wewnętrznym API.

Po każdej aktualizacji Complianz lub Polylang wykonuję krótki smoke test:

1. PL Cookie Policy;
2. DE Cookie Policy;
3. EN regression;
4. linki z bannera;
5. relacje/przełącznik Polylang.

Fix 0.1.0 jest celowo aktywny tylko dla Complianz >=7.5.4 i <8.0.0. Przy Complianz 8.x robi no-op. Major update jest sygnałem do nowego source auditu, a nie do automatycznego rozszerzenia zakresu wersji w jednym version_compare().

Kiedy NIE używać tego workaroundu

Nie instalowałbym tego MU-pluginu, jeżeli:

• używasz innego trybu ustalania języka Polylang;
• cały problem wynika po prostu z brakujących translation files;
• Twoja strona nie korzysta z wygenerowanej/synchronizowanej EU Cookie Policy;
• chcesz naprawić banner, a nie legal document;
• pierwszym symptomem nie jest opisany tutaj broken state;
• używasz Complianz 8.x bez ponownego audytu kodu;
• aktualny Complianz/Polylang już renderuje dokument poprawnie bez workaroundu.

To nie jest uniwersalny „plugin do tłumaczenia Complianz”. Jest to compatibility workaround dla konkretnej kolejności wykonania w konkretnej konfiguracji.

Stan upstream na 1 września 2026

W chwili przygotowywania tego artykułu najnowszym publicznym wydaniem Complianz jest 7.5.4 z 31 sierpnia 2026. To ta sama wersja, na której problem został potwierdzony w produkcji. Publiczny changelog 7.5.4 nie opisuje poprawki dotyczącej Polylang The language is set from content ani kolejności tworzenia legal documents.

Polylang ma obecnie publiczne wydanie 3.8.7 z 17 sierpnia 2026. Sam produkcyjny case był diagnozowany przy 3.8.6, dlatego nie twierdzę, że identyczny symptom został przeze mnie osobiście ponownie zreprodukowany na 3.8.7. Istotne jest natomiast to, że bieżąca dokumentacja developerska Polylang nadal opisuje ten sam mechanizm: przy The language is set from content język jest definiowany na wp z priority 5.

Oficjalna instrukcja Complianz dla Polylang nadal zakłada, że po utworzeniu powiązanej strony i dodaniu zsynchronizowanego legal-document blocka dokument zostanie przetłumaczony po publikacji. W tym konkretnym środowisku tak się nie stało, mimo obecnych pakietów tłumaczeń i prawidłowych locale.

Dlatego workaround traktuję jako wersjozależne rozwiązanie kompatybilnościowe, które należy wycofać, gdy upstream naprawi problem albo zmieni się architektura wewnętrzna Complianz.

Co z tego wynika

Najwięcej czasu w tym przypadku można było stracić na ponowne czyszczenie cache albo szukanie całej treści Cookie Policy w Polylang String translations. Najbardziej pomocny okazał się nietypowy symptom: główne akapity były po angielsku, ale niektóre późniejsze sekcje już po polsku.

To skierowało diagnostykę z „braku tłumaczenia” na moment, w którym tłumaczenie jest wykonywane.

Source audit potwierdził konflikt: Complianz tworzył główne document_elements na init, natomiast Polylang w content-based mode definiował język później, na wp/5. Wąski rebuild na wp/20 pozwolił zachować istniejącą strukturę URL, automatyczną synchronizację Complianz i nie dotykać angielskiej wersji bazowej.

Najważniejsze dla mnie było jednak nie samo „żeby działało”, lecz żeby fix dało się łatwo wycofać i żeby po zmianie upstreamu potrafił bezpiecznie nic nie zrobić. Dlatego finalny kod jest dłuższy niż jednorazowy snippet, ale dzięki temu ma jasno określony zakres, test regresji i prosty rollback.

Źródła i stan wersji

Do ustalenia root cause użyłem dokładnych plików z produkcyjnego Complianz 7.5.4: gutenberg/block.php, documents/class-document.php, config/class-config.php, config/documents/cookie-policy-eu.php i complianz-gpdr.php. Aktualny stan upstream został ponownie sprawdzony 1 września 2026.

• Polylang Developers — When Polylang does load the language?
• Complianz — Translate legal documents to multiple languages with Polylang
• Complianz — Editing Legal Documents
• Complianz — How to translate legal documents to your own language?
• WordPress.org — Complianz plugin / changelog
• WordPress.org — Polylang plugin / changelog

Najnowszy publiczny Complianz pozostawał w wersji 7.5.4, a Polylang w 3.8.7. Nie znalazłem w ich changelogach informacji o upstreamowym fixie tego konkretnego konfliktu kolejności init / wp.

Pomogła Ci ta instrukcja?
Jeśli zaoszczędziła Ci trochę czasu albo nerwów, możesz postawić mi kawę.