{
„@context”: „https://schema.org”,
„@type”: „Article”,
„articleSection”: „Case Study”,
„name”: „PrestaShop White Screen of Death – naprawa awaryjna”,
„description”: „Przywrócenie sklepu PrestaShop po krytycznym błędzie WSOD. Diagnoza i naprawa w 45 minut.”,
„publisher”: {
„@type”: „Organization”,
„name”: „HelpGuru.eu”,
„url”: „https://helpguru.eu”
},
„author”: {
„@type”: „Person”,
„name”: „Adrian Szewalski”,
„url”: „https://helpguru.eu/news/author/aszewalski/”
},
„about”: {
„@type”: „Thing”,
„name”: „PrestaShop 8.x”
},
„mainEntity”: {
„@type”: „ItemList”,
„name”: „Wyniki Case Study”,
„itemListElement”: [
{
„@type”: „ListItem”,
„position”: 1,
„name”: „Przed”,
„description”: „Biały ekran, brak dostępu do admina, sklep offline”
},
{
„@type”: „ListItem”,
„position”: 2,
„name”: „Po”,
„description”: „Sklep online, zabezpieczenia wdrożone, BackupGuard aktywny”
},
{
„@type”: „ListItem”,
„position”: 3,
„name”: „Czas realizacji”,
„description”: „45 minut”
}
]
}
}

Godzina 10:22 – biały ekran zamiast sklepu

„Próbowałem zainstalować darmowy moduł dla faktur. Teraz widzę tylko biały ekran. Panel admina też nie działa. Mam dziś 3 wysyłki do realizacji.”

White Screen of Death (WSOD) w PrestaShop to jeden z najbardziej stresujących problemów – brak komunikatu błędu, żadnej wskazówki. Tylko biała strona.

Pierwsze działanie: SSH na serwer i logi PHP:

PHP Fatal error: Cannot redeclare _PS_VERSION_
in /modules/fakturowniapl/fakturowniapl.php on line 3
PHP Fatal error: Allowed memory size of 134217728 bytes exhausted

Dwa problemy naraz. Klasyczny scenariusz złego modułu.

Diagnoza

Problem 1: Duplikat definicji stałej

Darmowy moduł z zewnętrznego marketplace zawierał na początku pliku:

define('_PS_VERSION_', '1.7.0.0');

PrestaShop sam definiuje tę stałą podczas bootstrapu w defines.inc.php. Próba ponownego zdefiniowania kończy się krytycznym błędem PHP – i białym ekranem całego sklepu.

Problem 2: Przepełnienie pamięci RAM podczas instalacji

Moduł próbował podczas instalacji wygenerować faktury dla wszystkich historycznych zamówień (800+). Limit pamięci: 128 MB. Operacja wymagała 340 MB. PHP zabił proces w połowie – zostawiając częściowo zainicjalizowane dane w bazie.

Naprawa krok po kroku

Krok 1: Wyłączenie modułu przez FTP (5 minut)

Bez dostępu do panelu admina: bezpośrednia interwencja na plikach. Zmiana nazwy katalogu modułu z .disabled na końcu. PrestaShop załadował się poprawnie. Biały ekran zniknął.

Krok 2: Czyszczenie uszkodzonych danych sesji (10 minut)

TRUNCATE TABLE ps_smarty_cache;
TRUNCATE TABLE ps_smarty_lazy_cache;
DELETE FROM ps_module WHERE name = 'fakturowniapl';

Krok 3: Weryfikacja integralności bazy (20 minut)

mysqlcheck z opcją –check dla wszystkich tabel. Trzy tabele wymagały REPAIR TABLE. Żadna z tabel zamówień, produktów ani klientów nie była uszkodzona.

Krok 4: Zabezpieczenie na przyszłość (10 minut)

• Zwiększenie limitu pamięci PHP do 512 MB
• Tryb maintenance z białą listą IP admina przed każdą instalacją modułu
• BackupGuard – automatyczny backup przed każdą aktualizacją

Wyniki

• ✅ Sklep przywrócony: 45 minut od zgłoszenia
• ✅ Brak utraty danych: 100% zamówień i klientów zachowanych
• ✅ Backupy: cotygodniowy + przed każdą zmianą
• ✅ Monitoring: Uptime Robot z alertem SMS w 1 minutę od awarii

Każdy niezweryfikowany moduł to ryzyko

Darmowy moduł bez review PrestaShop Addons może zawierać błędy jak ten – albo znacznie gorsze (backdoor, kradzież danych klientów). Zawsze instaluj moduły ze sprawdzonych źródeł i miej aktualny backup. Czas przywrócenia ze skompresowanego backupu: 8 minut. Bez backupu: niemożliwe.