Typowy trigger pilnej realizacji w WordPressie to nie „brzydki motyw”, tylko urwany checkout: błąd 500 po aktualizacji, podwójne naliczanie, webhook z ERP wiszący w kolejce albo bramka zwracająca timeout przy szczycie kampanii. Ten wpis opisuje jak naprawiać to inżyniersko — pod presją czasu, ale bez ryzykownego deployu na produkcję „w ciemno”.
Sklep WooCommerce to wiele warstw naraz: szablon, szereg hooków `woocommerce_*`, rozszerzenia od kuriera i podatków po loyalty i marketplace integracje. Gdy coś pęka przy skalowaniu ruchu, objaw bywa jeden (biały ekran lub „coś poszło nie tak”), ale przyczyn może być kilka — stąd konieczność triagingu zamiast zgadywania.
Pięć klas problemów, które najczęściej tną konwersję
- fatals PHP po aktualizacji Woo, motywu albo wtyczki modyfikującej checkout
- konflikt cache (page cache / CDN) z endpointami koszyka i sesją
- błędna konfiguracja bramki, kluczy API, trybu test vs live albo whitelista IP
- webhooki i kolejki (ERP, CRM, fulfillment) — timeout, retry storm, duplikaty zamówień
- regresja wydajności (INP/LCP) na mobile — użytkownik porzuca koszyk zanim zapisze się zamówienie
Diagnoza: pierwsza godzina (co zbierać w jednym miejscu)
- czy problem dotyczy całego ruchu, czy konkretnej metody płatności, waluty lub rynku (np. tylko Przelewy24 / tylko karta)
- logi PHP (fatal error, memory limit), log serwera WWW i ewentualnie log WooCommerce (Woo → Status → Logi)
- czy da się odtworzyć na stagingu z anonimizowanym zrzutem lub choć z kopią bazy i tym samym zestawem wtyczek
- ostatnie zmiany: deploy motywu, update Woo, nowa wtyczka „optymalizująca checkout”, zmiana w szablonie `checkout/form-checkout.php`
Szybka matryca: objaw → kierunek dociekań
| Objaw | Częste źródło | Pierwszy krok |
|---|---|---|
| Biały ekran / 500 na checkout | fatal PHP, konflikt wtyczki, limit pamięci | log PHP + wyłączenie ostatniej zmiany na stagingu |
| Podwójne obciążenie karty | podwójne submit, webhook, plugin „order bump” | logi bramki + reprodukcja jednej ścieżki płatności |
| Koszyk „opróżnia się” | sesja / cookie / cache | test bez CDN, tryb incognito, weryfikacja domeny ciasteczka |
| Zamówienie w „pending” bez końca | webhook nie wraca, bramka w sandboxie | panel bramki + log WooCommerce |
| Tylko mobile nie działa | JS third-party, heavy theme, payment redirect | profil mobile + wyłączenie zbędnych skryptów na checkout |
Konflikty wtyczek i kolejność izolacji
Zamiast wyłączać losowo pluginy na produkcji, budujesz krótką listę podejrzanych: ostatnie zmiany w repozytorium, wtyczki podpięte pod `woocommerce_checkout_*`, modyfikacje koszyka, mini-cartu albo „one-click checkout”. Na stagingu reprodukujesz scenariusz: gość → dodanie produktu → przejście do płatności → callback.
Jeśli nie masz kompletnego stagingu, używasz minimalnego środowiska z tym samym PHP co produkcja i kopią bazy (po anonimizacji danych osobowych). Test A/B wtyczek na żywym sklepie bez kontroli to proszenie się o podwójny przestój.
Izolacja to nie „wyłącz wszystko”. To świadome wyłączanie jednego warstwa naraz i mierzalny powrót do stanu stabilnego.
Sesja, koszyk i cache — najczęstszy „niewidzialny” winowajca
Pełna strona HTML cache’owana na checkout lub ajax koszyka obsłużony przez CDN bez wykluczeń potrafi tworzyć pozory losowych błędów. Sprawdzasz politykę cache dla `woocommerce`, endpointów `wc-ajax`, cookie sesyjnych oraz czy reverse proxy nie ucina nagłówków.
- wykluczenia URI dla koszyka, konta, płatności i „thank you”
- object cache (Redis): spójność sesji przy wielu instancjach PHP-FPM
- jeśli jesteś za load balancerem — sticky sessions albo wspólny storage sesji
Bramki płatności: tryb testowy, webhooki, zwroty
Każda bramka ma swój model: redirect (off-site), iframe, API na serwerze. Przy pilnym ratunku potrzebujesz numerów transakcji z panelu dostawcy, statusów „authorised / captured / failed” oraz historii webhooków. Typowy błąd wdrożeniowy to klucze testowe na produkcji albo zmiana URL sklepu bez aktualizacji webhooków.
- potwierdź środowisko (live vs test) i wersję API bramki
- sprawdź podpis webhooka i endpoint docelowy (czasem zmienia się po migracji domeny)
- zweryfikuj obsługę zwrotów i częściowych zwrotów jeśli masz marketplace lub split payout
Slice MVP: najpierw domknij ścieżkę pieniężną
Jeśli kampania jedzie pełną parą, pierwszy kamień milowy to przywrócenie minimalnej ścieżki: koszyk → dane → płatność → strona potwierdzenia z poprawnym measurement (GA4, ads, consent). Resztę można tymczasowo wyłączyć: cross-sell w koszyku, program lojalnościowy, dodatkowe pola checkout — to świadome cięcie zakresu znane z playbooku turnaround.
Minimalny zestaw testów akceptacji przed oznaczeniem „naprawione”
- jedna ścieżka gość + jedna zalogowany użytkownik
- co najmniej dwie metody płatności jeśli macie split rynkowy
- potwierdzenie maila transakcyjnego i statusu zamówienia w panelu
- szybki smoke na mobile z sieci komórkowej (nie tylko Wi‑Fi biura)
Wydajność checkoutu i Core Web Vitals
Wolny checkout nie zawsze kończy się błędem HTTP — częściej kończy się porzuceniem. Jeśli kampania podbija ruch, narasta czas interakcji (INP) przez ciężkie skrypty upsellu lub mapę punktów odbioru. Po stabilizacji funkcjonalnej warto zestawić metryki z artykułem o Core Web Vitals pod WordPress.
Komunikacja z supportem bramki i z zespołem biznesowym
Przy ticketach do PSP podajesz ID transakcji, timestamp (UTC), kwotę, walutę, user-agent i czy problem dotyczy jednej metody. Po stronie biznesowej ustalasz jawny komunikat dla klientów („przyjmujemy zamówienia telefonicznie”) jeśli naprawa przekracza okno — to chroni markę bardziej niż ciche 500.
Powiązane — WordPress, pilna realizacja, wydajność
- Usługi programistyczne WordPress
- Pilna realizacja projektów
- Playbook pilnej realizacji i SLA
- Zakres programistyczny WordPress
- Core Web Vitals w WordPressie
- Core Web Vitals — podstawy
FAQ
Najczęściej zadawane pytania
- Niekoniecznie — często to interakcja motywu, snippetów w functions.php i WooCommerce; izolacja zmian jest ważniejsza niż intuicja „ostatnio ruszałem tylko X”.
- Tylko w skrajnych przypadkach — standardem jest staging z anonimizowanym snapshotem lub feature flag; inaczej ryzykujesz podwójne obciążenie supportu i powtórzenie incydentu.
- Gdy deadline kampanii jest nieprzesuwalny albo utrzymanie przychodu zależy od godzin — dokładnie scenariusz z filaru pilnej realizacji.
- Sprawdź log płatności w Woo, status w panelu bramki i czy webhook nie został odrzucony przez firewall lub zmieniony URL — często to jedna linijka konfiguracji po migracji.
- Na czas diagnozy można wyłączyć page cache dla ścieżki checkout — docelowo potrzebujesz jednak precyzyjnych wykluczeń, bo sklep bez cache przy kampanii może padnąć pod obciążeniem.
- Idempotencja po stronie integracji, blokada podwójnego submit po JS, oraz monitorowanie webhooków — szczególnie przy retry dostawcy.