Aktualizacja PHP albo całego serwera potrafi przyspieszyć sklep, poprawić bezpieczeństwo i rozwiązać część problemów z wydajnością. Tyle teoria. W praktyce często wygląda to tak: po zmianie wersji PHP sklep zaczyna wyrzucać błąd 500, panel administracyjny przestaje się ładować, a koszyk działa „raz tak, raz nie”. Najbardziej frustrujące jest to, że czasem nie ma żadnego czytelnego komunikatu na ekranie.
Dobra wiadomość jest taka, że większość problemów po aktualizacji ma powtarzalne przyczyny. Zwykle chodzi o: niekompatybilny moduł, zbyt stare nadpisania (override), wyłączone rozszerzenie PHP, różnicę w konfiguracji serwera lub błąd w cache. Da się to poukładać w logiczną diagnostykę, zamiast klikać „na ślepo” i liczyć, że się naprawi.
W tym artykule dostaniesz konkretne kroki: gdzie zajrzeć, co sprawdzić w jakiej kolejności i jakie objawy prowadzą do jakiej przyczyny. Będzie też prosto wytłumaczone, co oznaczają błędy 500/503, jak czytać logi i jak bezpiecznie wytypować winny moduł bez rozwalenia całego sklepu.
Jeśli aktualizacja PHP była robiona „przy okazji” migracji albo zmiany hostingu, problemów może być więcej, bo zmieniło się kilka rzeczy naraz. Wtedy szczególnie ważne jest podejście etapami: najpierw stabilność i działający checkout, dopiero potem optymalizacje.
Jeżeli dopiero planujesz zmianę hostingu pod sklep, dobrze jest zacząć od zapoznania się z rankingiem hosting PrestaShop.
Co tak naprawdę zmienia aktualizacja PHP/serwera
Aktualizacja PHP to nie tylko „nowsza liczba w panelu”. Zmienia się zachowanie części funkcji, ostrzeżenia mogą zamieniać się w błędy, a niektóre stare elementy przestają działać całkiem. PrestaShop i moduły są na to wrażliwe, bo to system złożony z wielu kawałków: rdzeń sklepu, motyw, moduły, nadpisania, a do tego biblioteki od zewnętrznych dostawców.
Aktualizacja serwera (albo migracja na inny hosting) potrafi dołożyć kolejne zmienne: inne limity czasu, inna pamięć PHP, inne ustawienia uprawnień do plików, inna wersja bazy danych, czasem inny silnik cache. Efekt uboczny bywa taki, że sklep „wstaje”, ale zaczyna się dławić przy większych operacjach: import, generowanie miniaturek, przebudowa indeksów, masowa wysyłka maili.
Po czym poznasz, że to „problem po aktualizacji”, a nie przypadek? Zwykle: problem pojawił się natychmiast po zmianie wersji PHP/serwera, a wcześniej sklep był stabilny. Druga wskazówka: błędy dotyczą wielu miejsc naraz (front, panel, crony), a nie jednego konkretnego modułu używanego rzadko.
Jeśli masz sklep na hostingu współdzielonym i po aktualizacji zaczęły wyskakiwać błędy przy większym ruchu albo podczas importów, możliwe, że uderzyłeś w limity zasobów. Dobrze to rozjaśnia artykuł Limity hostingu współdzielonego: CPU, RAM, I/O – jak je czytać i co realnie spowalnia stronę?. To nie jest tekst tylko o „wydajności” — to instrukcja, jak rozpoznać, że problem nie leży w samym PrestaShop.
Błąd 500 po aktualizacji: jak znaleźć przyczynę
Błąd 500 to komunikat „serwer nie potrafi obsłużyć tego żądania”. Nic więcej. Dlatego pierwszy krok to zawsze dojście do konkretnego błędu w logach, bo bez tego będziesz tylko zgadywać. W PrestaShop najczęstsze scenariusze po aktualizacji PHP to: błąd składni lub niekompatybilny kod w module, brak rozszerzenia PHP, błąd w .htaccess, albo problem z uprawnieniami do zapisu (cache, logi, kompilacja).
Zacznij od odpowiedzi na proste pytanie: czy błąd 500 dotyczy całego sklepu, czy tylko panelu albo tylko jednej podstrony. Jeśli błąd jest „wszędzie”, winny jest zwykle element ładowany zawsze: autoloader, moduł uruchamiany globalnie, override, plik konfiguracyjny lub .htaccess. Jeśli błąd pojawia się tylko w panelu, często chodzi o moduł administracyjny, problem z sesją lub pamięcią.
Drugi krok: spróbuj odtworzyć problem w kontrolowany sposób. Wejdź na stronę w trybie incognito, a potem odśwież kilka razy. Jeżeli raz działa, raz nie, to często nie jest „błąd kodu”, tylko limit (CPU/RAM/I/O), timeout albo problem z cache. Jeżeli błąd jest zawsze, szukasz twardej przyczyny w logach.
Jeśli aktualizacja dotyczyła też serwera WWW (np. inny panel, inny mechanizm przepisywania adresów), .htaccess może być winny. Objawy: nagłe przekierowania, pętle, 404 w miejscach, które wcześniej działały, albo 500 po wejściu na produkt/kategorię. Wtedy najczęściej pomaga ponowne wygenerowanie .htaccess w panelu PrestaShop (bez ręcznych „dopisów” na start), a dopiero potem stopniowe przywracanie dodatkowych reguł, jeśli były.
W praktyce błąd 500 po aktualizacji najczęściej kończy się jednym z dwóch wniosków: moduł nie jest kompatybilny z nowym PHP albo brakuje rozszerzenia/zmieniła się konfiguracja. Kolejne sekcje prowadzą Cię przez oba scenariusze.
Kompatybilność modułów i motywu: jak szybko namierzyć winowajcę
Moduły są najczęstszym powodem problemów po aktualizacji PHP, bo to one najczęściej zawierają kod pisany „pod konkretną wersję” lub używają starych bibliotek. Motyw i override też potrafią namieszać, szczególnie jeśli sklep był przerabiany przez kilka lat i część zmian była robiona „na skróty”.
Najprostsza diagnostyka to sprawdzenie, czy problem znika po wyłączeniu modułu. Tylko że często nie wejdziesz do panelu, żeby go wyłączyć. Wtedy musisz działać „od zewnątrz”: tymczasowo zmienić nazwę katalogu modułu (żeby PrestaShop go nie załadował) albo odciąć override. To brzmi groźnie, ale w praktyce jest bezpieczne, jeśli robisz to krok po kroku i po każdym kroku sprawdzasz, czy sklep wrócił.
Skąd wiedzieć, które moduły podejrzewać jako pierwsze? Te, które:
- integrują płatności (często mają własne biblioteki i dużo kodu),
- robią cache i optymalizacje,
- ingerują w checkout, koszyk, ceny, waluty,
- są stare i dawno nie aktualizowane,
- mają integracje z zewnętrznymi API (kurierzy, marketplace).
Jeśli błąd pojawia się tylko na froncie (a panel działa), zacznij od modułów, które wpływają na widok sklepu: cache, SEO, dodatkowe skrypty, analityka, elementy koszyka. Jeśli błąd jest w panelu, zacznij od modułów typowo administracyjnych (faktury, magazyn, import, integracje).
Jeżeli po aktualizacji PHP pojawiły się błędy „na granicy wydajności” (np. panel ładuje się długo, a potem wywala), wróć do tematu zasobów i limitów oraz do tego, jaki hosting masz pod sklep. W praktyce PrestaShop częściej „wybacza” drobne błędy na blogu, ale nie wybacza ich w e-commerce. Dobre tło daje tekst PrestaShop: hosting współdzielony vs hosting VPS, bo pokazuje, gdzie kończą się możliwości współdzielonego i dlaczego sklep potrafi nagle przestać działać po zmianie warunków.
Konfiguracja PHP i rozszerzenia: brakujące „klocki”, które blokują sklep
Po aktualizacji PHP może się okazać, że część rozszerzeń jest wyłączona, a wcześniej była dostępna. Na ekranie zwykle widzisz wtedy 500 albo białą stronę, bo aplikacja próbuje użyć czegoś, czego PHP już nie ma. Czasem dostajesz bardziej czytelny błąd w logach, np. o braku konkretnej klasy albo funkcji.
Najczęstsze „klocki”, które bolą w PrestaShop po zmianie środowiska, to rozszerzenia związane z: przetwarzaniem obrazów, komunikacją sieciową, obsługą znaków, a czasem z kompresją i archiwami. Objawy bywają mylące: sklep działa, ale nie da się wgrać zdjęć, generowanie miniatur kończy się błędem, moduł płatności nie łączy się z API, a import CSV wywala się bez sensownego komunikatu.
Warto też sprawdzić limity PHP, bo po aktualizacji mogą wrócić do domyślnych wartości. Jeśli nagle nie możesz zapisać zmian w panelu, importy przerywają się, a koszyk „kręci” i wraca do początku, przyczyną bywa zbyt niski limit pamięci albo za krótki czas wykonywania skryptów. Tu ważne: to nie jest „bug PrestaShop”, tylko warunki uruchomienia.
Jeżeli aktualizacja serwera dotknęła też technologii typu OPcache lub ustawień przyspieszających, mogą pojawić się błędy, które wyglądają jak losowe. Sklep raz ładuje się poprawnie, raz sypie ostrzeżeniami. Wtedy ważne jest czyszczenie cache (o tym niżej) oraz upewnienie się, że konfiguracja nie jest „agresywna” w miejscach typu checkout.
Jeśli chcesz zrozumieć, które elementy hostingu faktycznie przyspieszają stronę (a które tylko ładnie wyglądają w marketingu), pomocny jest wpis: PHP 8.x, OPcache i HTTP/3 – które technologie hostingu faktycznie przyspieszają WWW?. W kontekście diagnozy po aktualizacji to się przydaje, bo pozwala odróżnić „zmianę, która pomaga” od „zmiany, która miesza”.
Baza danych i wydajność po zmianie serwera: kiedy problem wygląda jak błąd aplikacji
Po aktualizacji serwera czasem problem nie jest w PHP, tylko w tym, że baza danych zaczęła działać inaczej. Może być wolniej, może mieć inne limity, a może po prostu sklep urósł i dotarł do momentu, w którym każda większa operacja dusi hosting. Objawy są podobne do błędów aplikacji: długie ładowanie, wywalanie 500/503, problemy w panelu przy listach zamówień lub produktów.
Najbardziej zdradliwe są sytuacje, gdy sklep działa, ale w określonych momentach „przysiada”: przy wyszukiwaniu w panelu, przy wejściu w zamówienia, przy masowych zmianach cen, przy przebudowie indeksów. To są miejsca, gdzie baza dostaje mocno po głowie. Po aktualizacji serwera (lub zmianie wersji bazy) te same zapytania mogą mieć inny czas wykonania, a wtedy zaczynasz widzieć timeouty.
Jeżeli masz duży katalog produktów, dużo kombinacji i rosnące logi, temat bazy potrafi stać się głównym hamulcem. Wtedy warto zajrzeć do tekstu Baza danych PrestaShop: indeksy, rozmiar, logi – jak ograniczyć spowolnienia przy rosnącym katalogu. To nie jest „optymalizacja dla sportu” – to często różnica między stabilnym panelem a panelem, który co chwilę wyrzuca błędy.
Jeśli po aktualizacji serwera pojawia się błąd 503 (a nie 500), to często znak, że serwer jest przeciążony albo procesy PHP są ubijane przez limity. Wtedy logi i statystyki zasobów (CPU/RAM/I/O) są ważniejsze niż grzebanie w kodzie. Dobrą bazę do rozpoznania takich sytuacji daje wspomniany już artykuł o limitach: Limity hostingu współdzielonego: CPU, RAM, I/O – jak je czytać i co realnie spowalnia stronę?.
Cache i pliki tymczasowe
Po aktualizacji PHP/serwera bardzo częsty problem to cache. Sklep potrafi zachowywać się tak, jakby część plików była „stara”, mimo że aktualizacja już jest. Albo odwrotnie: nagle coś znika z frontu, a po odświeżeniu wraca. To efekt tego, że PrestaShop i serwer trzymają w pamięci skompilowane elementy i pliki tymczasowe.
Po czym poznasz, że to cache? Błąd jest trudny do powtórzenia albo zależy od przeglądarki/trybu incognito. Czasem widzisz różne rzeczy jako zalogowany administrator i jako zwykły klient. Czasem problem znika po wyczyszczeniu pamięci podręcznej przeglądarki, ale wraca po chwili.
Zacznij od podstaw: wyczyść cache PrestaShop w panelu (jeśli masz dostęp), a jeśli nie masz – usuń katalogi cache zgodnie z wersją PrestaShop (tu ważne: nie kasuj plików w ciemno, tylko to, co jest cache, bo można sobie narobić szkód). Po czyszczeniu cache sprawdź krytyczne miejsca: strona produktu, koszyk, checkout, logowanie do panelu.
Jeśli masz rozwiązania przyspieszające po stronie serwera (cache serwera WWW, wtyczki cache, CDN), na czas diagnozy ogranicz je, przynajmniej dla koszyka i checkout. Inaczej możesz „naprawić” problem tylko dlatego, że cache przykrywa błąd, a potem w losowym momencie błąd wróci.
Jeżeli po aktualizacji planujesz dodatkowo wdrażać CDN, rób to dopiero po przywróceniu stabilności. CDN ma sens, ale w złym momencie utrudnia diagnozę. Jeżeli chcesz podejść do tego spokojnie, masz rozpisane plusy i minusy w: CDN w hostingu: kiedy ma sens, ile kosztuje i jak wpływa na TTFB oraz Core Web Vitals.
Płatności, maile i crony po aktualizacji: testy, które ratują przed wpadką
Po aktualizacji PHP/serwera potrafi być tak, że sklep „wygląda, że działa”, ale nie działa to, co najważniejsze: checkout, maile transakcyjne, zadania cykliczne. To są obszary, które często zależą od zewnętrznych połączeń (API), konfiguracji serwera (SSL, DNS, firewall) i cronów, więc zmiana środowiska ma realny wpływ.
Test płatności powinien być obowiązkowy. Nie chodzi o to, żeby „kupić u siebie”, tylko żeby przejść cały proces do momentu przekierowania do bramki i powrotu, oraz sprawdzić, czy status zamówienia ustawia się poprawnie. Jeśli po aktualizacji klienci utkną na płatności, straty są natychmiastowe.
Maile transakcyjne testuj praktycznie: zamówienie → czy przyszedł mail do klienta i do administracji. Jeśli maile nie dochodzą, sprawdź, czy sklep korzysta z SMTP i czy dane są poprawne. Przy zmianach serwera bywa też tak, że dostarczalność siada przez konfigurację domeny. Jeżeli chcesz ogarnąć temat stricte pocztowy, masz to uporządkowane we wpisie: Poczta na hostingu: SPF, DKIM, DMARC – jak poprawić dostarczalność maili z domeny.
Crony to trzeci filar. Jeśli po aktualizacji przestaną działać, skutki często wychodzą dopiero po godzinach lub dniach: feedy nie odświeżają stanów, automaty nie wysyłają danych, integracje nie synchronizują statusów. Dlatego po aktualizacji sprawdź, czy crony są włączone i czy wykonują się bez błędów. Jeśli chcesz mieć punkt odniesienia, wróć do: Cron w PrestaShop: wysyłki, feedy, aktualizacje stanów – jak ustawić?.
Jak czytać logi PrestaShop i serwera: gdzie kliknąć i co oznaczają wpisy
Logi to jedyne miejsce, gdzie znajdziesz prawdę o błędzie 500. Na ekranie widzisz tylko skutki. W logach widzisz przyczynę: plik, linijkę i komunikat. Dlatego, jeśli po aktualizacji coś nie działa, Twoim celem jest dotarcie do pierwszego sensownego błędu (nie do setki kolejnych, które są efektem domina).
W PrestaShop część błędów zobaczysz w logach panelu (jeśli panel działa), ale przy błędach krytycznych i tak ważniejsze są logi serwera (error log). Tam najczęściej pojawiają się komunikaty o brakujących klasach, niekompatybilnych funkcjach, błędach składni w module albo problemach z uprawnieniami do plików.
Jak czytać wpisy? Szukaj trzech elementów: czasu, typu błędu i miejsca (plik/linia). Jeśli widzisz, że błąd wskazuje na katalog modules/…, masz podejrzanego. Jeśli wskazuje na override/…, podejrzane są nadpisania. Jeśli wskazuje na pliki rdzenia, a błąd dotyczy braku funkcji lub klasy, to często brak rozszerzenia PHP albo konflikt wersji.
Zwróć uwagę na błędy, które pojawiają się tuż po aktualizacji, a wcześniej ich nie było. Jeśli logi są „głośne” (mnóstwo wpisów), zawęź zakres: odtwórz błąd, zanotuj godzinę/minutę i filtruj log po tym czasie. W praktyce jedno dobre odtworzenie błędu jest więcej warte niż godzina czytania losowych wpisów.
Jeśli Twoja aktualizacja była częścią przenosin hostingu, pamiętaj też, że mogą dojść błędy typowe dla migracji: niepełny transfer plików, problem z .htaccess, brakujące crony. W takim scenariuszu pomocny kontekst daje wpis Migracja PrestaShop na inny hosting: checklista, bo wiele objawów po aktualizacji i po migracji wygląda podobnie, a różni się źródło.
FAQ – Najczęściej zadawane pytania
Nie zawsze. To sygnał „coś poszło nie tak po stronie serwera”, a przyczyną może być kod, brak rozszerzenia PHP, .htaccess, uprawnienia do plików albo limit zasobów. Kluczowe jest znalezienie konkretnego błędu w logach, bo na ekranie tego nie zobaczysz.
Jeśli błąd jest „wszędzie”, podejrzewaj elementy ładowane globalnie (moduł, override, konfiguracja). Jeśli błąd jest tylko w jednym miejscu, szukaj modułu lub funkcji używanej w tym scenariuszu.
Biała strona zwykle oznacza błąd krytyczny, którego nie widać na froncie. Najszybciej dojdziesz do przyczyny przez logi serwera (error log). Jeśli masz dostęp do panelu, sprawdź też logi PrestaShop, ale przy krytycznych problemach często zobaczysz je tylko w logach serwera.
Jeżeli log wskazuje na konkretny moduł, zacznij od jego odłączenia i dopiero potem szukaj aktualizacji lub zamiennika.
Tak. Płatności często zależą od bibliotek i połączeń z zewnętrznym API, a moduły potrafią być wrażliwe na wersję PHP i konfigurację SSL. Sklep może działać „na oko”, ale checkout zatrzyma się w kluczowym momencie albo nie wróci ze strony bramki.
Dlatego po aktualizacji zawsze rób test przejścia przez checkout i sprawdź, czy zamówienie dostaje prawidłowy status.
Jeśli wolniej jest „wszędzie” i pojawiają się błędy 503, często problemem są limity (CPU/RAM/I/O) albo konfiguracja serwera, a nie samo PHP. Jeśli wolniej jest tylko w konkretnych miejscach (np. zamówienia w panelu), podejrzewaj bazę danych lub ciężkie zapytania.
W diagnozie pomoże Ci podejście z artykułu Limity hostingu współdzielonego: CPU, RAM, I/O – jak je czytać i co realnie spowalnia stronę?, bo pokazuje typowe objawy „to nie bug, to limit”.
Tak, bo po aktualizacji mogą zostać skompilowane elementy lub pliki tymczasowe, które nie pasują do nowego środowiska. Objawy problemów z cache są często losowe: raz działa, raz nie, inne zachowanie w incognito, różnice między klientem a adminem.
Po czyszczeniu cache od razu testuj koszyk i checkout, bo tam cache potrafi zrobić najwięcej szkód.
30-letnia pasjonatka informatyki, która świat serwerów i hostingów zna od podszewki. Wierzy, że technologia powinna ułatwiać życie, a nie je komplikować. Żyje w ciągłym ruchu – jeśli akurat nie konfiguruje nowej usługi, prawdopodobnie pakuje plecak na kolejną wyprawę w nieznane.
Dodaj komentarz