Dlaczego sklep internetowy nie działa po aktualizacji PHP? To pytanie słyszę najczęściej po weekendowych pracach serwisowych, gdy wszystko miało być “na chwilę”, a kończy się nerwowym poniedziałkiem. Aktualizacja PHP potrafi przynieść skok wydajności i bezpieczeństwa, ale bywa też momentem prawdy: wychodzi na jaw niekompatybilność wtyczek, motywów, rozszerzeń serwerowych i customowego kodu. Dobra wiadomość? W większości przypadków da się to szybko naprawić — pod warunkiem, że działamy metodycznie.

Najczęstsze powody: Dlaczego sklep internetowy nie działa po aktualizacji PHP?

Mapa typowych przyczyn awarii po podbiciu wersji PHP

• Niekompatybilna wersja silnika sklepu (np. WooCommerce, PrestaShop, Magento) lub motywu z nowym PHP
• Wtyczki porzucone przez autorów albo dawno nieaktualizowane
• Zmiany w samym PHP (deprecacje, ostrzejsze błędy w PHP 8.x)
• Braki w rozszerzeniach serwerowych (np. intl, gd, imagick, zip, sodium, ionCube) lub ich niekompatybilne wersje
• Zmiany w konfiguracji serwera/hostingodawcy (handler PHP, FPM, limity pamięci, wersje bibliotek)
• Konflikty cache (OPcache, Redis, Varnish) oraz stare pliki w pamięci podręcznej
• Błędy w kodzie własnym, który “jakoś działał” na starej wersji, a teraz sypie fatal error

Zmiany w PHP 8.x, które często psują kod

Najczęstsze “niespodzianki” po skoku z 7.4 do 8.x

Wraz z PHP 8 nadeszły zmiany, które dla starszego kodu bywają bezlitosne:

• Ostrzejsze traktowanie błędów: wiele ostrzeżeń z 7.4 stało się fatal errors
• Usunięte/deprecjonowane funkcje: m.in. silniejsze wymagania typów, dynamiczne właściwości obiektów są deprecjonowane (8.2)
• Zmienione zachowanie funkcji: różnice w zwracanych typach, wymagania dotyczące nulli
• ionCube: loader często nie nadąża za najnowszym PHP; jeżeli masz zaszyfrowane moduły, mogą przestać działać
• Ekosystem rozszerzeń: brak kompatybilnych wersji rozszerzeń serwerowych skutkuje nagłą awarią funkcji (np. braki intl wpływają na sortowanie i lokalizację, brak gd/imagick na generowanie miniatur)

Jeśli pracujesz z WooCommerce, sprawdź matrycę zgodności: WordPress + WooCommerce + PHP + wersja motywu muszą się zazębiać. W PrestaShop i Magento szczególnie ważne są też wersje MySQL/Elasticsearch oraz dostępność modułów PHP.

Niekompatybilność silnika sklepu i wtyczek

Gdy najnowszy PHP spotyka stary plugin — zwykle przegrywa plugin

• WooCommerce/WordPress: Skok na PHP 8.2/8.3 wymaga aktualnych wersji WordPressa, WooCommerce i motywów. Stare wtyczki (np. bramki płatności, integracje kurierskie) potrafią wywrócić checkout.
• PrestaShop: Liczy się konkretna gałąź. Część modułów payment/shipping nie jest testowana na nowszych PHP.
• Magento: Tu dochodzą zależności composera, wersje PHP 8.1/8.2 i zgodność modułów vendorowych. Jeden niekompatybilny pakiet w vendor/ potrafi zablokować całe wdrożenie.

W wielu sklepach kluczowe integracje (ERP, płatności, księgowość) są zamknięte lub szyfrowane. Jeśli autor nie dostarczył aktualizacji pod nowy PHP, masz wąskie gardło.

Braki lub konflikty rozszerzeń serwerowych

“Działało, bo było zainstalowane” — aż do czasu

Po zmianie PHP często zmienia się też zestaw rozszerzeń. Sprawdź:

• intl (formatowanie, sortowanie, translacje)
• gd/imagick (grafika, miniatury)
• zip (rozpakowywanie motywów, paczek)
• sodium/openssl (szyfrowanie, podpisy, płatności)
• curl (integracje z API, bramki płatności)
• ionCube (jeśli używasz zaszyfrowanych wtyczek/modułów)

Brak któregoś z nich może oznaczać puste strony, 500, albo subtelne błędy — np. brak miniaturek, problemy z koszykiem, niekończący się checkout.

Zmiany w konfiguracji serwera i cache

Nowa wersja PHP = inne limity i inny handler

• memory_limit, max_execution_time, upload_max_filesize, post_max_size — czasem spadają do domyślnych, zbyt niskich wartości
• OPcache — stara pamięć lub agresywne ustawienia mogą serwować “duchy” plików
• PHP-FPM/handler — inny user, inne uprawnienia, inne ścieżki do socketów
• .htaccess/NGINX rules — dyrektywy dla starego handlera przestają działać
• Redis/Varnish/pełnostronicowy cache — po aktualizacji trzeba wyczyścić i przebudować

Objawy? Losowe 500, częściowo ładujący się frontend, nieprzechodzący checkout, problem z logowaniem do panelu.

Błędy w motywie i kodzie własnym

“Działało od lat” nie znaczy “będzie działać na 8.2”

• Stare motywy potrafią używać funkcji wycofanych w PHP 8.x
• Customowy kod z pominięciem typów dziś sypie fatalami
• Przestarzałe hooki/filtry w WooCommerce po aktualizacji mogą nie wywoływać się poprawnie
• W Magento i PrestaShop stare override’y łamią logikę po aktualizacji

Jeżeli widzisz biały ekran (WSOD), sprawa zwykle rozbija się o jeden plik: fatal error zatrzymuje cały rendering.

Jak szybko przywrócić działanie sklepu

Plan awaryjny na “tu i teraz”

1. Przywróć poprzednią wersję PHP na chwilę, jeśli to możliwe w panelu hostingu. Ustal, czy sklep wraca do życia — to ważna wskazówka diagnostyczna.
2. Wyczyść cache: OPcache, Redis, Varnish, cache wtyczek (LiteSpeed Cache, WP Rocket, itp.).
3. Wyłącz podejrzane wtyczki (najpierw płatności, wysyłka, integracje), a następnie aktywuj je po jednej, sprawdzając sklep.
4. Przełącz motyw na domyślny (np. Storefront dla WooCommerce) i sprawdź, czy błąd znika.
5. Zaktualizuj rdzeń, wtyczki i motyw do wersji kompatybilnych z nowym PHP.
6. Włącz logowanie błędów i sprawdź error_log — to Twój najlepszy trop.
7. Skontaktuj się z hostingiem, by doinstalować brakujące rozszerzenia albo podnieść limity.

Na produkcji staraj się minimalizować ryzyko. Jeśli masz staging — diagnozuj na stagingu, wdrażaj dopiero po potwierdzeniu.

Diagnostyka krok po kroku

Jak znaleźć źródło awarii bez zgadywania

• Logi błędów: włącz display_errors w stagingu, na produkcji trzymaj wyłączone, ale zapisuj do pliku. W WordPress: define(‘WP_DEBUG’, true), define(‘WP_DEBUG_LOG’, true).
• phpinfo(): sprawdź wersję PHP, dostępne rozszerzenia, wartości limitów, ścieżki.
• Health Check (WP): tryb rozwiązywania problemów pozwala wyłączyć pluginy tylko dla Twojej sesji.
• Composer diagnose (Magento/Shopware): wykrywa konflikty pakietów i platform-check.
• Zależności: sprawdź matryce zgodności (WooCommerce/WordPress/PHP, PrestaShop/PHP, Magento/PHP/Elasticsearch).
• Cache warstwa po warstwie: OPcache, Redis, wtyczki cache, CDN. Usuń, przebuduj, przetestuj.
• Uprawnienia plików: po zmianach FPM bywa, że user nie ma praw do zapisu w cache/uploads.

W logach szukaj słów-kluczy: “Fatal error”, “Uncaught”, “Call to undefined function”, “Class not found”, “Deprecated”. Nawet jeden błąd potrafi zatrzymać cały rendering.

Przykłady typowych usterek i rozwiązań

Z życia wdrożeń

• Po aktualizacji na PHP 8.2 checkout w WooCommerce przestaje działać: winny stary moduł bramki płatności. Rozwiązanie: tymczasowo powrót do poprzedniej wersji PHP, aktualizacja modułu do wersji z obsługą 8.2, test na stagingu, wdrożenie.
• PrestaShop gubi miniatury: brak imagick po migracji na nowy serwer. Rozwiązanie: instalacja imagick/gd, regeneracja miniaturek.
• Magento wypluwa błędy kompozytora: constrainty pakietów blokują PHP 8.2. Rozwiązanie: aktualizacja pakietów, dostosowanie wersji modułów vendorowych, sprawdzenie zgodności Elasticsearch.

Dobre praktyki na przyszłość

Jak aktualizować bez stresu

• Staging zawsze przed produkcją: kopia bazy i plików, identyczne wersje rozszerzeń i cache.
• Matryca zgodności: przed podbiciem PHP sprawdź, czy rdzeń, motyw i wtyczki mają wersje kompatybilne.
• Zastępuj porzucone wtyczki: jeśli autor od lat nie aktualizuje, szukaj alternatywy.
• Lock wersji: w środowiskach composera trzymaj spójne wersje (composer.lock), testuj aktualizacje w cyklu.
• Monitoring: New Relic, logi serwera, alerty uptime — szybciej złapiesz regresję.
• Backupy: zanim podbijesz PHP, zrób pełną kopię. Najlepiej z szybkim rollbackiem.
• Dokumentacja zmian: notuj, co było aktualizowane, jakie wersje, jakie poprawki wprowadzono.

FAQ: najczęstsze pytania

Krótko i na temat, gdy czas nagli

• Czy mogę po prostu cofnąć PHP i temat zamknięty?
  — Tymczasowo tak, ale traktuj to jako plaster, nie leczenie. Znajdź przyczynę i zaktualizuj elementy niekompatybilne.

• Ile trwa naprawa?
  — Od kilkunastu minut (brak rozszerzenia) do kilku godzin/dni (porzucone moduły, duża liczba zależności). Najwięcej czasu pochłania testowanie.

• Co najczęściej jest winne?
  — Porzucone wtyczki, stare motywy, brak rozszerzeń serwerowych oraz zbyt niskie limity po zmianie konfiguracji.

• Czy warto aktualizować do najnowszego PHP?
  — Tak, ze względu na wydajność i bezpieczeństwo, ale z zachowaniem procedury staging/testy/backup.

Checklist: co sprawdzić po aktualizacji PHP

Jedna lista, wiele uratowanych poniedziałków

• Wersja PHP zgodna z wymaganiami silnika sklepu i wtyczek
• Zainstalowane i aktywne rozszerzenia: intl, gd/imagick, zip, curl, sodium, openssl, ionCube (jeśli potrzebny)
• Limity: memory_limit, max_execution_time, upload/post size — podniesione do realnych potrzeb sklepu
• OPcache/Redis/Varnish/CDN — cache wyczyszczony
• Logi błędów — brak fatal errors i ostrzeżeń z krytycznych funkcji
• Rdzeń, motyw, wtyczki — aktualne, wspierane, przetestowane na stagingu
• Bramki płatności i wysyłka — przeprowadzony test transakcji i generacji etykiet
• Uprawnienia do katalogów cache, uploads, var — poprawne dla nowego FPM/handlera
• Kompozytor (jeśli dotyczy) — brak konfliktów, udane composer install/update
• Monitoring — włączony, alerty działają

Na koniec najważniejsze: aktualizacja PHP to nie pojedynczy klik, tylko proces. Jeśli przejdziesz go świadomie — z checklistą, stagingiem i planem awaryjnym — zyskasz szybszy, bezpieczniejszy sklep, a przy okazji spokój w krytycznych momentach sprzedażowych. Jeśli już dziś coś się sypie, zacznij od logów i rozszerzeń serwerowych, wyłącz stary plugin płatności, a potem metodycznie przejdź przez powyższe kroki. W 9 na 10 przypadków to wystarczy, by Twój sklep znów zarabiał.