Rozwiązywanie problemów PrestaShop: puste strony, błędy i odzyskiwanie

Co byśmy zrobili

Wybralibyśmy sposób odzyskania działania na podstawie faktycznej konfiguracji twojego sklepu: dokładnych wersji PrestaShop i PHP, modułów, nadpisań motywu, danych katalogowych i zamówień, integracji oraz hostingu. Języki, waluty, grupy klientów i dostęp zespołu również wpływają na to, co można odtworzyć i bezpiecznie zmienić. Wada modułu wymaga udziału jego opiekuna; problem z instalacją lub konfiguracją wymaga sprawdzenia ustawień; awaria serwera wymaga udziału dostawcy hostingu lub osoby odpowiedzialnej za infrastrukturę.

Przy zmianie kodu, modułu, motywu lub środowiska wykonawczego użyj prywatnej kopii testowej z odpowiednią konfiguracją produkcyjną, odizolowanej od rzeczywistych płatności, emaili do klientów i eksportów do realizacji zamówień. Odtwórz usterkę, przećwicz odwracalną naprawę i uzgodnij dowody wymagane do ponownego otwarcia sklepu. Zastosuj przetestowaną zmianę w zaplanowanym oknie produkcyjnym, mając zapisane ustawienia, zgodne pakiety i wskazaną osobę, która potrafi ją cofnąć. Jeśli trzeba natychmiast ograniczyć skutki awarii, najpierw zabezpiecz dotknięty nią proces i ogranicz zakres zmian diagnostycznych.

W przypadku uzgodnionej instalacji i konfiguracji jednego istniejącego modułu usługa PrestaShop Module Installation & Configuration Service obejmuje jego ustawienia i weryfikację procesu użycia, a licencje i prace programistyczne są rozliczane osobno; nie jest to ogólna usługa awaryjnego przywracania działania.

Wybierz punkt wyjścia

Jeśli znajdziesz niewyjaśnione konto administratora, zmienionego odbiorcę płatności lub nieoczekiwany plik wykonywalny, zachowaj dowody i zaangażuj osobę odpowiedzialną za incydenty bezpieczeństwa. Zwykłe izolowanie modułów nie wystarczy, by potwierdzić, że sklep można bezpiecznie otworzyć.

Zarejestruj awarię i zabezpiecz bieżący stan

1. Wstrzymaj niezwiązane instalacje, aktualizacje, importy i wielokrotne czyszczenie pamięci podręcznej.
2. Zapisz dokładny czas, strefę czasową, URL lub czynność administracyjną, status HTTP, tekst odpowiedzi i błąd przeglądarki. Odnotuj, kogo dotyczy problem.
3. Wymień ostatnie zmiany rdzenia, modułów, motywu, PHP, hostingu, reguł proxy i zaplanowanych zadań.
4. Zachowaj logi i wykonaj kopię plików oraz bazy danych przed zmianami naprawczymi. Kopię sprzed incydentu przechowuj oddzielnie.
5. Ogranicz ruch publiczny lub użyj trybu konserwacji, gdy usterka dotyczy finalizacji zakupu, integralności danych lub publicznego wyświetlania błędów.
6. W miarę możliwości odtwórz problem w środowisku testowym, wyizoluj jedną przyczynę, przetestuj i zapisz wynik.

Pusta treść odpowiedzi jest objawem, a nie dowodem krytycznego błędu PHP. Pusty wynik, wcześniejsze zakończenie, odpowiedź proxy lub awaria usługi nadrzędnej również mogą ją powodować. Sprawdź faktyczny status i treść w narzędziach deweloperskich przeglądarki. „Błąd AJAX” wymaga nieudanego żądania z zakładki Network i jego odpowiedzi, a nie tylko komunikatu wyświetlanego przez interfejs.

Po każdej istotnej naprawie sprawdź stronę główną, kategorię, produkt, koszyk, finalizację zakupu i logowanie do panelu. W środowisku testowym używaj trybu sandbox płatności i weryfikuj sumy zamówień, stany magazynowe oraz wygenerowane potwierdzenia. Przed ponownym otwarciem finalizacji zakupu na produkcji potwierdź produkcyjne dane dostępowe, tryb operatora i punkt końcowy wywołań zwrotnych oraz, w odpowiednich przypadkach, uzgodnij kontrolowany test rzeczywistej płatności. Przetestuj też pierwotnie niedziałającą czynność.

Znajdź właściwy log i przeczytaj cały błąd

Zaawansowane > Logi zawiera zdarzenia zapisane przez mechanizm logowania PrestaShop do bazy danych, z uwzględnieniem filtrowania według ważności. Nie jest to pełny zapis błędów PHP, Symfony ani inicjalizacji.

Nie zmieniaj var/logs/ na var/log/ tylko dlatego, że sklep działa na PrestaShop 8 lub 9. Nie zakładaj, że każde środowisko używa dokładnie prod.log lub dev.log. Konfiguracja CLI PHP może również wskazywać inny log niż PHP obsługujące WWW.

# From the shop root, inspect available application logs.
ls -lt var/logs/
# Follow the configured file after confirming its name.
tail -n 100 -f var/logs/prod.log

Powiąż wpisy z czasem żądania, środowiskiem i identyfikatorem żądania, jeśli jest dostępny. Przeczytaj komunikat wyjątku, plik, linię i istotne ramki stosu. Ramka w module lub motywie jest wskazówką, a nie dowodem przyczyny źródłowej; w tym miejscu mogą zawieść błędne dane wejściowe lub wcześniejsza zależność.

Jeśli nie pojawia się pasujący błąd, sprawdź konfigurację logowania, prawa zapisu, rotację i dostępne miejsce. Wyświetlanie i logowanie błędów PHP konfiguruje się oddzielnie, więc ukryta treść nie gwarantuje zapisania logu. Usuń dane uwierzytelniające, tokeny i dane osobowe przed udostępnieniem logów.

Połącz dane z przeglądarki, proxy i aplikacji

Traktuj każde przekierowanie i każde żądanie w tle jako osobne żądanie. Działająca strona produktu może nadal zawierać niedziałające żądanie dotyczące stanu magazynowego, koszyka lub konfiguracji. Jeśli infrastruktura udostępnia już identyfikator żądania, uwzględnij go w zgłoszeniu do pomocy technicznej; w przeciwnym razie powiąż zapisy za pomocą znacznika czasu, metody i dokładnej ścieżki. Uwzględnij różne strefy czasowe logów i opóźnione zadanie uruchamiane po odpowiedzi dla przeglądarki.

Jeśli warstwa brzegowa rejestruje błąd, lecz serwer źródłowy nie ma pasującego żądania, przed edycją PHP sprawdź drogę przez proxy lub hosting. Jeśli serwer źródłowy rejestruje poprawną odpowiedź, ale przeglądarka otrzymuje inną treść, zbadaj pośrednie buforowanie lub przepisywanie odpowiedzi. Żadna z tych obserwacji sama nie wskazuje wadliwego komponentu.

Używaj trybu debugowania i profilowania do różnych zadań

Użyj Zaawansowane > Wydajność > Tryb debugowania, jeśli jest dostępny. Przełącznik rdzenia to _PS_MODE_DEV_ w config/defines.inc.php. Zmień jego istniejącą deklarację na czas chronionej sesji diagnostycznej, a następnie ją przywróć:

define('_PS_MODE_DEV_', true);
// Restore production mode after collecting the error:
define('_PS_MODE_DEV_', false);

To alternatywne stany, a nie dwie deklaracje do wklejenia razem. Tryb debugowania wpływa na wyświetlanie błędów i wybór środowiska aplikacji. Nie wyłącza buforowania Smarty we wszystkich przypadkach. Domyślna maska debugowania pomija ostrzeżenia o przestarzałych elementach, chyba że włączono ustawienie ostrzeżeń dotyczących zgodności.

Używaj mechanizmów PrestaShop, zamiast zakładać, że zastępują je ogólne zmienne APP_ENV lub APP_DEBUG. Jądro aplikacji używa stałych środowiska i debugowania PrestaShop. Wywołania ini_set() podczas działania nie omijają późniejszej konfiguracji rdzenia i nie ujawnią błędu parsowania, który uniemożliwia uruchomienie tego samego skryptu wejściowego. Błędy uruchamiania diagnozuj przez konfigurację PHP/serwera i logi.

Profiler Symfony jest dostępny tylko dla kwalifikujących się żądań Symfony po skonfigurowaniu. Nie jest automatycznie dołączany do każdego żądania frontu, starszego mechanizmu, AJAX ani żądania zakończonego błędem. Oddzielny starszy profiler czasu i zapytań używa _PS_DEBUG_PROFILING_ w config/defines.inc.php. Włącz profilowanie na krótko w chronionym środowisku testowym i porównaj reprezentatywne żądania.

Publiczne komunikaty debugowania mogą ujawnić ścieżki, SQL, tokeny i wrażliwą konfigurację. Wyłącz je po zarejestrowaniu błędu. Dla wywołań zwrotnych płatności preferuj logowanie serwerowe zamiast wyświetlania wyjątków.

Performance Revolution może wystawić pracowniczy plik cookie debugowania po uwierzytelnieniu pracownika panelu; jego wczesna inicjalizacja akceptuje posiadanie tego tokena, a odnawiany czterogodzinny termin ważności w przeglądarce nie jest sesją serwerową ani kontrolą bezczynności. Traktuj go jako dane dostępu do debugowania i korzystaj ze strony pomocy modułu przy konfiguracji i unieważnianiu.

Diagnozuj puste strony i błędy HTTP według statusu

Sprawdzaj składnię ostatnio edytowanych plików PHP. Na przykład:

php -l config/defines.inc.php
php -v
php --ini

Używaj pliku wykonywalnego PHP przeznaczonego dla sklepu. Powodzenie w CLI nie dowodzi, że środowisko WWW ma tę samą wersję, rozszerzenia, uprawnienia i konfigurację.

Przepisywanie adresów i .htaccess

W Apache sprawdź dokładną dyrektywę powodującą błąd i to, czy host wirtualny dopuszcza wymagane reguły przepisywania. Nieobsługiwane dyrektywy Options lub php_value mogą powodować błędy. Nginx nie odczytuje .htaccess; zamiast tego sprawdź konfigurację serwera.

Zachowaj kopię przed zmianą .htaccess. Jeśli tymczasowo go izolujesz, rób to przy kontrolowanym dostępie, ponieważ może zawierać także reguły bezpieczeństwa. Zapisanie ustawień Set up URLs w sekcji Preferencje > Ruch & SEO odtwarza .htaccess, jeśli pozwalają na to uprawnienia. Generowanie robots.txt jest osobną czynnością.

Sprawdź właściciela i faktycznego użytkownika wykonującego PHP przed zmianą uprawnień. Przyznawaj tylko wymagany przez sklep zapis do konkretnych katalogów, w tym odpowiednich pamięci podręcznych, logów, obrazów, plików przesyłanych lub generowanych przez moduły. Uniwersalna recepta z rekurencyjnym chmod może odebrać wymagany dostęp lub ujawnić pliki.

Izoluj konflikty modułów i brak treści na froncie

W środowisku testowym najpierw sprawdź ostatnią zmianę. Jeśli kilka modułów wchodzi w interakcję, porównaj oba włączone, każdy osobno i oba wyłączone. Dla większych zbiorów zawężaj kontrolowane grupy i ponownie testuj zależności. Ostatnio włączony moduł może ujawnić interakcję, nie ponosząc za nią wyłącznej odpowiedzialności.

Preferuj akcję Wyłącz w Menedżerze modułów. Działająca konsola może użyć obsługiwanego polecenia modułu; sprawdź pomoc przed wyborem technicznej nazwy modułu i kontekstu sklepu:

php bin/console help prestashop:module

Polecenie obsługuje między innymi akcje disable, enable, install, upgrade i uninstall. Mają one różne skutki. Zmiana samego module.active w SQL nie odtwarza zwykłego wyłączenia, które obsługuje również powiązania sklepów i zachowanie modułu. Unikaj zbiorczej aktualizacji wszystkich rekordów modułów zewnętrznych.

Jeśli nie uruchamia się ani panel, ani konsola, tymczasowe przeniesienie katalogu podejrzanego modułu poza ścieżkę skanowania modułów może odizolować pliki. Zapisz dokładną pierwotną lokalizację, zachowaj go prywatnie i zaplanuj przywrócenie. Nie usuwa to zainstalowanych nadpisań, nie cofa migracji ani nie gwarantuje odzyskania działania przy odwołaniach do skompilowanych usług.

Przy diagnozowaniu nadpisań używaj opcji Disable all overrides w sekcji Wydajność, powiązanej z PS_DISABLE_OVERRIDES, i odtwórz indeks klas. _PS_ALLOW_OVERRIDES_ i _PS_DISABLE_OVERRIDES_ nie są poprawnymi przełącznikami. Ręczne przeniesienie katalogu również wymaga obsługi indeksu.

Rdzeń może łączyć różne metody nadpisujące w jednej klasie, ale pokrywające się metody lub właściwości mogą powodować jawny konflikt. Uzgodnij poprawkę zgodności z jednym odpowiedzialnym podmiotem i planem instalacji/aktualizacji. Nie zakładaj, że wklejenie dwóch implementacji razem pozwoli obu instalatorom zakończyć się powodzeniem.

Jeśli zainstalowany moduł wyświetlający nic nie pokazuje, sprawdź konfigurację, aktywny sklep, zakres stron/produktów i to, czy motyw renderuje obsługiwany hook. W Wygląd > Pozycje sprawdź obsługiwane umiejscowienia i kolejność. Nie podpinaj modułu do dowolnego hooka, którego nie implementuje. Następnie sprawdź kopie szablonów, błędy przeglądarki i pamięci podręczne.

Odróżnij wadę od nieukończonej konfiguracji

Porównaj niedziałającą konfigurację z instrukcją zainstalowanej wersji: wymaganymi ustawieniami konta, powiązaniami sklepów, hookami i ukończonymi migracjami. Dane dostępowe API odrzucone przez dostawcę to inny przypadek dla pomocy technicznej niż wyjątek przy prawidłowych danych. Przekaż opiekunowi minimalny sposób odtworzenia problemu w obsługiwanej konfiguracji i zapisz każdy fragment własnego kodu potrzebny do jego wywołania. Ponowna instalacja lub odinstalowanie jako skrót diagnostyczny mogą usunąć konfigurację albo dane i utrudnić takie porównanie.

Wyczyść pamięć podręczną odpowiednią do zmiany i sprawdź automatyczne ładowanie

Akcja Wyczyść pamięć podręczną w panelu uruchamia szerszy łańcuch mechanizmów czyszczenia, nie tylko Smarty. Nadal nie gwarantuje wyczyszczenia każdej pamięci hostingu, proxy, modułu czy przeglądarki.

Preferuj akcję panelu lub skoordynowane czyszczenie konsolą z katalogu głównego sklepu:

php bin/console cache:clear --env=prod

Używaj właściwego pliku wykonywalnego PHP i uruchamiaj polecenia jako właściciel plików. Jeśli uszkodzona inicjalizacja wymaga naprawy przez system plików, zatrzymaj ruch przychodzący i procesy robocze, zachowaj logi, potwierdź dokładne ścieżki generowanej pamięci i odbuduj ją z właściwym właścicielem. Usuwanie pamięci podręcznej nie jest z natury zabronione w PrestaShop 9; ryzyko tworzą nieskoordynowane żądania i nieudane odbudowy. Nie usuwaj plików aplikacji ani nieudokumentowanych danych modułu jako „pamięci podręcznej”.

CLI opcache_reset() nie resetuje niezależnej webowej puli OPcache. Użyj odpowiednio kontrolowanego procesu przeładowania/unieważniania FPM lub Apache u dostawcy hostingu. Nie pozostawiaj publicznego endpointu resetowania w sklepie.

Nie znaleziono klasy lub przestrzeni nazw

1. Zapisz dokładną brakującą klasę i oczekiwaną przestrzeń nazw.
2. Sprawdź obecność kompletnego pakietu wydania, w tym vendor/autoload.php modułu i plików zależności, jeśli są dostarczane.
3. Sprawdź wielkość liter w nazwach plików i przestrzeni nazw na systemie plików rozróżniającym wielkość liter, prawa odczytu i wymagania PHP pakietu.
4. Przywróć czysty pakiet, zamiast mieszać pliki z różnych wydań. Oddzielnie zachowaj udokumentowane pliki przesyłane lub eksporty.
5. Odbuduj odpowiedni kontener i indeks klas, a następnie skoordynuj webowy OPcache.

Generuj autoload Composera tylko w ramach właściwego procesu źródłowego/wdrożeniowego, z poprawnymi zależnościami i plikiem blokady. Nie odtworzy to brakujących bibliotek. Odbudowa indeksu klas nie naprawia brakującej zależności Composera z przestrzenią nazw. Unikaj usuwania rekordów modułów lub hooków w bazie tylko dlatego, że brakuje klasy.

Rozwiąż problemy z wyczerpaniem pamięci i niepełnym zapisem formularzy

Allowed memory size exhausted oznacza, że żądanie przekroczyło faktyczny limit pamięci PHP. Miejsce ostatniej alokacji wskazane przez błąd krytyczny nie jest automatycznie źródłem wzrostu. Mogą się do niego przyczyniać duże importy, wymiary obrazów, formularze z wieloma kombinacjami, odczyty całych tabel, rekurencja i logowanie dużych obiektów.

Sprawdź wartość dla WWW w sekcji Informacje, jeśli jest udostępniona, oraz w aktywnej konfiguracji FPM. Oszacuj dostępną pamięć RAM i współbieżność procesów roboczych przed podniesieniem limitów. Na przykład memory_limit = 512M może być odpowiednie dla danego obciążenia, ale nie jest gwarantowaną poprawką ani progiem, którego musi używać każda strona.

Podziel nadmierne importy na kontrolowane partie, przetwarzaj obrazy oddzielnie tam, gdzie jest to obsługiwane, i profiluj nieograniczone wyniki. Powtarzająca się awaria nie dowodzi wycieku pamięci. Zachowuj wymagane integracje aktywne, chyba że przetestowano skutki ich wyłączenia.

Ustawienia lub produkty zapisują się tylko częściowo

1. Otwórz Console i Network w przeglądarce. Sprawdź, czy wysłano POST, jego rozmiar, odpowiedź i przekierowanie.
2. Ponownie otwórz ekran konfiguracji z nowego linku administracyjnego, aby otrzymać aktualny token. Wyklucz panel z publicznego buforowania.
3. Sprawdź uprawnienia pracownika do konfiguracji i bieżący kontekst sklepu.
4. Sprawdź limity danych wejściowych/treści PHP oraz limity proxy lub serwera WWW.
5. Sprawdź pasującą regułę WAF, zamiast szeroko wyłączać zaporę.
6. Sprawdź wymagane tabele modułu, ukończone migracje i udokumentowane ścieżki zapisywalne.

max_input_vars ogranicza liczbę parsowanych zmiennych wejściowych. Przekroczenie obcina dane i generuje E_WARNING; ostrzeżenie może nie pojawić się w panelu. Wiele kombinacji i języków może tworzyć duży formularz, ale nie dowodzi, że przyczyną jest ten limit. Ustal faktyczną wartość dla WWW przez konfigurację hostingu lub chronioną diagnostykę; nie każda strona Informacje ją podaje.

Skonfiguruj limit przed parsowaniem żądania. Na podniesienie go w kodzie obsługi formularza jest już za późno. Przykład oparty na pomiarze dużego formularza może wyglądać tak:

max_input_vars = 5000
post_max_size = 64M
upload_max_filesize = 48M
max_execution_time = 300
memory_limit = 512M

To przykładowe limity, a nie uniwersalne wymagania. Utrzymuj limit rozmiaru POST powyżej dozwolonego rozmiaru przesyłanego pliku wraz z narzutem i zapewnij czas na rozpakowanie lub przetwarzanie. Użyj php.ini, obsługiwanego .user.ini, konfiguracji FPM lub panelu hostingu; dyrektywy Apache mod_php nie są ogólnym rozwiązaniem dla FPM. Potwierdź faktyczne wartości po przeładowaniu u dostawcy lub upływie opóźnienia pamięci konfiguracji.

Przy bardzo dużych zbiorach kombinacji rozważ natywny import CSV lub Webservice zamiast ogromnego formularza. Ich ograniczenia parsowania i zasobów są inne; nadal mają limity przesyłania, treści żądania, wykonania i pamięci. Zobacz dokumentację limitów wejściowych PHP.

Przykład: rozbudowany produkt traci tłumaczenia pól

Załóżmy, że mały produkt zapisuje się poprawnie, ale produkt z wieloma kombinacjami i językami traci wartości po ponownym otwarciu. Taki wzorzec sugeruje limit rozmiaru lub liczby pól, lecz dane żądania muszą pozwolić odróżnić go od walidacji aplikacji, odrzuconego żądania lub późniejszego zapisu.

1. Zachowaj kopię zamierzonych wartości i odtwórz problem na tym samym produkcie w środowisku testowym. Porównaj udane wysłanie małego formularza z nieudanym.
2. Sprawdź, czy brakujące pola znajdowały się w danych wysłanych przez przeglądarkę. Jeśli ich tam nie było, przed zwiększeniem limitów serwera sprawdź formularz i JavaScript.
3. Jeśli pola zostały wysłane, sprawdź Content-Type żądania, odpowiedź oraz pasujące ostrzeżenie PHP lub błąd aplikacji. Ustawienie PHP max_input_vars ogranicza automatycznie parsowane zmienne formularza; nie ogranicza kluczy dekodowanych z treści JSON przez kod aplikacji. Korzystając z faktycznej konfiguracji środowiska WWW, przetestuj konkretny limit danych wejściowych lub treści żądania, na który wskazują dowody.
4. Po zmianie ponownie otwórz produkt w tym samym sklepie i języku, a następnie w innym języku dotkniętym problemem. Potwierdź zachowanie istniejących kombinacji i niezwiązanych pól.

Jeśli wartości zapisują się poprawnie, a później wracają do poprzedniego stanu, powiąż późniejszy zapis z importami, zaplanowaną synchronizacją i edycjami innych pracowników. Zwiększenie limitu parsowania nie zapobiegnie nadpisaniu przez integrację wcześniej poprawnie zapisanego wyniku.

Dopasuj PHP do dokładnej wersji PrestaShop

Sprawdzaj PHP dla WWW i CLI oddzielnie. Potwierdź wymagane rozszerzenia i każdy ważny moduł, zależność, motyw i nadpisanie przed zmianą środowiska wykonawczego. Kontrola składni jest przydatna, ale nie dowodzi zgodności podczas działania.

Te zakresy zgodności aplikacji nie oznaczają, że stare gałęzie PHP nadal otrzymują poprawki bezpieczeństwa. Sprawdź historyczną macierz, macierz PrestaShop 8 i macierz PrestaShop 9 dla dokładnie używanej wersji. Sprawdź wymagania i zależności właściwe dla wersji 9.2, zamiast zakładać, że obejmuje ją starszy test 9.x.

Przy błędach PHP sprawdzaj konkretny element języka i wersję. W trybie z konwersją typów przekazywanie null do parametru skalarnego niedopuszczającego null w wielu funkcjach wewnętrznych stało się przestarzałe w PHP 8.1; ścisłe typowanie i inne błędy argumentów zachowują się inaczej. Zobacz wdrożony RFC PHP. Tworzenie właściwości dynamicznych stało się przestarzałe w PHP 8.2, z wyjątkami. Ostrzeżenia o przestarzałości nie stają się powszechnie błędami krytycznymi w następnym wydaniu; aktualizuj kod według harmonogramu migracji każdego elementu języka.

Zbadaj błędy bazy danych i nieudane aktualizacje rdzenia

Po nieudanej aktualizacji zachowaj raport i logi Update Assistant. Potwierdź dokładne wersje źródłową i docelową, kompletność plików, zależności, środowisko PHP i stan migracji. Nie zakładaj, że zastąpienie plików zakończyło aktualizację bazy danych.

Dla „Unknown column” sprawdź rzeczywistą definicję tabeli i migrację, która powinna ją utworzyć. Porównaj z czystą instalacją tej samej wersji docelowej, uwzględniając prefiks, moduły i historię sklepu. Nie wklejaj zgadywanej instrukcji ALTER ani nie zakładaj, że jeden historyczny katalog install-dev/upgrade/sql/ jest aktualnym źródłem migracji.

SHOW CREATE TABLE ps_product;
SHOW FULL PROCESSLIST;
SHOW ENGINE INNODB STATUS;

To przykłady diagnostyczne z ps_; użyj rzeczywistego prefiksu i odpowiednich uprawnień bazy danych. Ustal blokującą transakcję, wywołujący proces i operację biznesową przed anulowaniem zapytania. Zmiany schematu i duże odbudowy mogą blokować lub obciążać sklep i wymagają zaplanowanego okna.

„Duplicate entry for key” oznacza naruszenie ograniczenia unikalności. Ustal wskazany indeks i rzeczywistą wartość. Nie zakładaj, że kody referencyjne produktów są unikalne ani że ponowne uruchomienie instalatora naprawi częściowo ukończoną migrację.

Przy podejrzeniu uszkodzenia zachowaj kopie zapasowe i sprawdź logi błędów silnika. Polecenia naprawcze MyISAM nie są ogólnymi poleceniami odzyskiwania InnoDB. Odbudowa tabeli przez ALTER TABLE ... ENGINE=InnoDB nie jest niezawodną metodą naprawy fizycznego uszkodzenia. Użyj procesu odzyskiwania oraz zrzutu/przywracania właściwego dla silnika; wskazówki MySQL dotyczące odzyskiwania InnoDB opisują awaryjne mechanizmy odzyskiwania.

Jeśli kodu i schematu po aktualizacji nie można bezpiecznie uzgodnić, przywróć pasujące pliki i bazę danych z kopii sprzed aktualizacji przy kontrolowanym dostępie. Uwzględnij zamówienia, płatności i zmiany stanów od czasu tej kopii przed nadpisaniem stanu produkcyjnego.

Sprawdź szablony, motywy potomne i brakujące zasoby

Gdy szablonu nie można załadować, sprawdź żądaną ścieżkę modułu, dostarczony z modułem szablon i każdą kopię w motywie pod themes/your-theme/modules/. Nadpisania szablonów w motywie mogą przesłaniać nowszy szablon modułu. Wielkość liter nazw plików i katalogów ma znaczenie w systemie Linux.

Przy błędach kompilacji Smarty sprawdź wskazany szablon źródłowy, domknięcie bloków {if} i {foreach} oraz kolidujące delimitery. Nie wszystkie literały obiektowe JavaScript wymagają bloku literal: Smarty 3 obsługuje delimitery otoczone białymi znakami w udokumentowanych przypadkach. Stosuj escapowanie lub {literal} tylko tam, gdzie to potrzebne, pamiętając, że wyrażenia szablonu wewnątrz bloku literal nie są wykonywane. Zobacz dokumentację Smarty.

Sprawdź kodowanie i niezamierzony wynik, w tym BOM, bez zakładania, że każdy BOM powoduje błąd kompilatora. Przy błędach zasobów sprawdź rzeczywisty URL w Network, status, typ odpowiedzi i komunikat konsoli. Przejrzyj konfigurację motywu, zarejestrowane zasoby, wynik CCC, wersjonowanie wdrożenia i ścieżkę źródłową CDN.

Motyw potomny wymaga motywu nadrzędnego i zgodnej konfiguracji. Porównaj nadpisane szablony ze zaktualizowaną wersją motywu nadrzędnego lub modułu. W środowisku testowym znany zgodny motyw domyślny może pomóc wyizolować problem, ale przełączenie motywu jest rzeczywistą zmianą konfiguracji i należy ją zapisać oraz cofnąć po teście.

Proces utrzymania opisują motywy potomne.

Rozwiąż pętle logowania, problemy z tokenami i utratę koszyków

W narzędziach Storage lub Application przeglądarki sprawdź domenę, ścieżkę, Secure, HttpOnly, SameSite i rozmiar pliku cookie. Sprawdź komunikaty o odrzuconych plikach cookie i faktyczny łańcuch przekierowań. Porównaj host kanoniczny, rekordy shop_url, ustawienia SSL i konfigurację przekazywania przez proxy. Nie przełączaj się między adresami z www i bez www ani między HTTP i HTTPS podczas finalizacji zakupu.

1. Wypróbuj czysty profil przeglądarki lub okno prywatne, aby wyizolować zapisany stan.
2. Sprawdź, czy odpowiedzi panelu i treść uwierzytelniona omijają publiczną pamięć podręczną.
3. Sprawdź zakres pliku cookie i to, czy przeglądarka wysyła go w nieudanym żądaniu.
4. Potwierdź, że wdrożenie nie zastąpiło niezamierzenie oczekiwanych kluczy plików cookie/szyfrowania.
5. Przy wielu węzłach aplikacji sprawdź zgodność kluczy i magazyn sesji używany przez każdy odpowiedni komponent.
6. Ponownie przetestuj cały proces logowania lub powrotu z płatności, w tym POST między witrynami lub etapy 3-D Secure.

Nie zmieniaj globalnie SameSite na None na próbę. Niektóre procesy między witrynami potrzebują innej polityki, a współczesne przeglądarki wymagają Secure dla None, ale najpierw ustal, który plik cookie i żądanie tracą stan. Obecny rdzeń ogranicza też łączny rozmiar nazwy/wartości pliku cookie do 4096 bajtów; unikaj umieszczania w nim dużych tablic i danych debugowania.

Błąd nieprawidłowego tokena może wynikać z wygasłego stanu, starego formularza, zmiany hosta, zablokowanych plików cookie, zachowania proxy lub innych niezgodności żądania. Otwórz stronę ponownie przez aktualny link administracyjny i sprawdź żądanie. Zwiększenie session.gc_maxlifetime nie jest uniwersalnym rozwiązaniem.

Pliki cookie ściśle niezbędne do żądanej usługi koszyka lub uwierzytelniania mogą podlegać innym zasadom zgody niż analityka czy reklama. Oceń faktyczny cel i sprawdź, czy integracja zgody kontroluje tagi inne niż niezbędne. Zobacz sesje i pliki cookie oraz GDPR i zgodę.

Sprawdzaj dostarczanie emaili i stan serwera oddzielnie

Email

Użyj Zaawansowane > E-mail do wysłania kontrolowanego testu, a następnie sprawdź skonfigurowany endpoint SMTP, dane uwierzytelniające, szyfrowanie i zdarzenia dostawcy. Rekord w logu poczty nie jest dowodem dostarczenia do skrzynki odbiorczej. Oddzielnie prześledź przyjęcie, odrzucenie, zwrot i trafienie do spamu.

Sprawdź z dostawcą poczty uwierzytelnianie i zgodność domeny nadawcy przez SPF, DKIM i DMARC. Nie zakładaj, że wybrany port lub przejście z poczty lokalnej na SMTP gwarantuje dostarczanie. Jeśli jeden email zamówienia nie działa, sprawdź jego szablon, język, odbiorcę, zdarzenie wyzwalające i ścieżkę kolejki lub modułu przed ponownym wysłaniem. Zobacz dostarczalność emaili.

Nagłe spowolnienie

Mierz czas odpowiedzi serwera oddzielnie od wolnych zasobów przeglądarki. Sprawdź wolne bajty, wolne i-węzły, pamięć, obciążenie, oczekiwanie bazy danych, wykorzystanie procesów PHP i zaplanowane zadania:

df -h
df -i
uptime
free -m

Nie ma uniwersalnego procentu zajętości dysku, przy którym sklep przestaje działać. Logi, pliki tymczasowe, zapisy bazy danych i odbudowy pamięci podręcznej potrzebują wystarczającej faktycznej przestrzeni. Awaria pamięci masowej może również uniemożliwić zapis logu diagnostycznego.

Sprawdź, czy debugowanie lub profilowanie nie pozostało włączone. Profiluj kosztowne zapytania i hooki w kontrolowanych warunkach. Zbadaj nakładające się importy lub zadania cron, blokady, nieograniczone zapytania i rosnące dane połączeń, logów, koszyków lub gości. Przed czyszczeniem zastosuj politykę retencji; zachowaj wymagane zamówienia i dokumentację.

Nie traktuj modułu pamięci podręcznej jako lekarstwa na każdy błąd 500 lub 503. Skorzystaj z poradnika wydajności, gdy ustalisz wąskie gardło żądania i serwera.

Przykład: płatność się udaje, a finalizacja zakupu pozornie nie

Klient zgłasza obciążenie po zatrzymaniu wskaźnika ładowania podczas finalizacji zakupu, ale pracownicy nie mogą znaleźć zamówienia. Najpierw ustal, czy operator pokazuje autoryzację, pobraną płatność czy nieudaną próbę. Zrzut ekranu klienta i błąd finalizacji zakupu nie określają ostatecznego stanu finansowego.

1. Zachowaj identyfikator koszyka, identyfikator płatności, konto i tryb testowy lub produkcyjny, kwotę, walutę oraz czas. Wyszukaj każde zamówienie utworzone z tego koszyka, także wynik opóźniony lub podzielony na kilka zamówień.
2. Sprawdź nieudane żądanie przeglądarki oddzielnie od dostarczenia powiadomienia przez operatora i przetwarzania w aplikacji. Powiadomienie zablokowane przez tryb konserwacji lub dodatkową weryfikację dostępu wymaga innej naprawy niż procedura obsługi, która je odbiera i zawodzi podczas tworzenia zamówienia.
3. Po potwierdzeniu stanu u operatora zastosuj obsługiwaną przez integrację procedurę uzgadniania lub ponownego przetwarzania. Zleć jej opiekunowi sprawdzenie, czy ponowienie może zduplikować zamówienie, płatność, email lub ruch magazynowy.
4. Przećwicz niedziałającą ścieżkę w środowisku testowym za pomocą narzędzi testowych operatora, także dla klienta zamykającego przeglądarkę przed powrotem. Potwierdź powstałe zamówienie, identyfikator transakcji i stan dalszej realizacji.

Nie proś klienta o ponowną zapłatę ani nie oznaczaj ręcznie zamówienia jako opłaconego, dopóki pierwotna próba nie zostanie wyjaśniona. Uzgodnij działania z osobą obsługującą eksporty do magazynu lub ERP, aby opóźnione odzyskanie działania nie skierowało tego samego zakupu do realizacji dwa razy. Naprawa po stronie przeglądarki sama w sobie nie potwierdza przywrócenia serwerowego procesu płatności.

Odzyskaj dostęp, świadomie przywróć dane i zweryfikuj sklep

Najpierw użyj zwykłej procedury resetowania hasła pracownika. Jeśli odzyskiwanie przez email jest niedostępne, zleć programiście użycie usługi haszującej zainstalowanej wersji w prywatnej procedurze odzyskiwania CLI dla konkretnego pracownika. Współczesny PrestaShop używa usługi Hashing; starszy 1.6 używa starszego mechanizmu opartego na kluczu pliku cookie. Nie pozostawiaj nieuwierzytelnionego publicznego skryptu resetowania hasła ani stałego hasła w katalogu głównym WWW.

Jeśli utracono dostęp administracyjny, kontroluj ruch na hostingu lub proxy podczas naprawy. Tryb konserwacji zwykle znajduje się w Preferencje > Ogólny > Przerwa techniczna. Każda awaryjna zmiana konfiguracji musi używać rzeczywistego prefiksu i zakresu sklepu, zachowując stare wartości i ustawienia listy dozwolonych adresów. Zbiorcza aktualizacja każdego rekordu PS_SHOP_ENABLE może dotknąć inne sklepy.

1. Wybierz pasujące pliki i bazę danych ze znanego punktu odzyskiwania. Zachowaj stan awarii do analizy.
2. Zatrzymaj publiczne zapisy i zadania, a następnie przywróć dane lub zastosuj ściśle określoną poprawkę.
3. Uzgodnij transakcje wykonane po punkcie odzyskiwania, w tym rekordy operatorów płatności.
4. Odbuduj tylko właściwe pamięci podręczne z poprawnym właścicielem oraz skoordynuj webowy OPcache i pamięci zewnętrzne.
5. Przetestuj pierwotny objaw, dostęp administracyjny, katalog, koszyk, testową finalizację zakupu, emaile i zadania w tle.
6. Sprawdź czystą przeglądarkę i drugą przeglądarkę. Potwierdź usunięcie komunikatów debugowania i tymczasowych narzędzi.
7. Zapisz przyczynę źródłową, zmienione pliki/ustawienia, punkt odzyskiwania i wyniki testów przed pełnym otwarciem.

Po odzyskaniu działania nadal monitoruj logi błędów, dostępność, wolne miejsce i nieudane zadania. Testuj kopie zapasowe przez przywracanie do środowiska testowego. W zgłoszeniu MPR przekaż dokładne wersje, znacznik czasu, kroki odtworzenia, zakres problemu, ostatnie zmiany i logi z usuniętymi danymi wrażliwymi przez kontakt z pomocą. Przy problemach z zapisem lub AJAX dołącz odpowiedź nieudanego żądania z Network.

Wdróż sprawdzoną poprawkę bez zastępowania nowszych danych biznesowych

Prowadź rejestr zmiany wskazujący pakiet lub pliki, wartości konfiguracji, migracje i operacje pamięci podręcznej potrzebne do naprawy. Wdróż tę określoną zmianę zamiast kopiować cały sklep testowy na produkcję. Baza testowa utworzona przed dzisiejszymi zamówieniami nie jest aktualnym zamiennikiem bazy produkcyjnej.

Przed oknem produkcyjnym uzgodnij przesłanki cofnięcia zmiany i ustal, czy zapisała ona dane, których starszy kod nie potrafi odczytać. Sama wymiana plików może nie cofnąć migracji ani działania zewnętrznego API. Kontroluj integracje przychodzące i zadania w kolejce, a następnie uzgodnij wstrzymane zdarzenia przed wznowieniem normalnego przetwarzania. Skorzystaj z poradnika tworzenia kopii zapasowych i odzyskiwania, gdy wybrany sposób działania wymaga pełnego przywrócenia.

O co zapytać programistę lub agencję

• Jakie dowody wskazują przyczynę i jakie obserwacje by ją wykluczyły? Poproś o nieudane żądanie i pasujący błąd zamiast listy zmienionych ustawień.
• Które elementy środowiska produkcyjnego odtworzono i jakie różnice pozostały? Uwzględnij PHP obsługujące WWW, wersje modułów, kopie motywu, reguły proxy i integracje istotne dla awarii.
• Jaka jest najmniejsza jasno określona zmiana, kto odpowiada za ewentualną poprawkę zgodności modułu i jak zostanie ona zachowana przy kolejnej aktualizacji?
• Czy zmianę można cofnąć po zapisaniu przez nią danych lub wywołaniu usługi zewnętrznej? Zapytaj, jak zostaną uzgodnione zamówienia i płatności powstałe podczas incydentu.
• Jakie wyniki odbioru otrzymasz dla objętych problemem rynków, grup klientów i procesu pracy personelu oraz kto sprawdzi produkcję po ponownym otwarciu?

Wyznacz jedną osobę do koordynacji zmian między hostingiem, dostawcą modułu i programistą sklepu. Prowadź wspólny rejestr incydentu, aby jeden zespół nie przywracał starego pakietu, gdy drugi testuje jego zamiennik. Zakończ przekazanie prac potwierdzoną przyczyną, ostateczną zmianą i listą pozostałych działań.

Pytania właścicieli sklepów

Co zrobić, jeśli usterka nie występuje w środowisku testowym?

Porównaj żądanie i istotne różnice środowisk, zanim uznasz, że problem zniknął. Ruch produkcyjny, stan pamięci podręcznej, zewnętrzne dane dostępowe lub zaplanowane zadanie mogą współtworzyć warunki wyzwalające usterkę. Uzgodnij z programistą logowanie o wąskim zakresie na produkcji, gdy bezpieczne odtworzenie tych warunków nie jest możliwe.

Co zrobić, jeśli błąd pojawia się tylko sporadycznie?

Prowadź dziennik incydentów z objętymi problemem ścieżkami i czynnościami biznesowymi, a przy kolejnym wystąpieniu zbierz pasujące dane z serwera. Uzgodnij z programistą ukierunkowany okres obserwacji lub warunek jej uruchomienia. Wielokrotne zmienianie ustawień między wystąpieniami utrudnia ustalenie sporadycznej przyczyny.

Dlaczego problem dotyczy tylko jednego kraju lub grupy klientów?

Odtwórz problem z tym samym językiem, walutą, grupą, adresem, przewoźnikiem i dostępnością metod płatności. Porównaj ten kontekst z działającym, zmieniając za każdym razem tylko jeden istotny wybór. Podatki, ograniczenia lub odpowiedzi integracji właściwe dla kraju mogą kierować klientów przez różne ścieżki kodu.

Czy tryb konserwacji zatrzymuje wszystkie zmiany danych sklepu?

Nie zakładaj, że zatrzymuje zadania cron, procesy robocze, klientów API lub wywołania zwrotne płatności. Ustal, które procesy zapisują dane w twoim sklepie, i przed przywróceniem kopii uzgodnij ich wstrzymanie, kolejkowanie lub późniejsze uzgodnienie danych. Zapytaj opiekuna integracji płatności, jak w tym oknie zachowują się powiadomienia.

Czy mogę wysłać pomocy technicznej eksport z Network przeglądarki?

Eksport HAR może zawierać pliki cookie, nagłówki autoryzacji, tokeny, wysłane dane formularzy i dane klientów. Przed przekazaniem go prywatnym kanałem pomocy technicznej przejrzyj plik i usuń dane wrażliwe, zachowując kolejność żądań i błąd potrzebne do diagnozy. Dane dostępowe przekaż osobno uzgodnioną bezpieczną metodą.

Co pracownicy powinni mówić klientom dotkniętym problemem?

Zapisz, którego procesu dotyczy problem i jakie następne działanie pracownicy mogą bezpiecznie podjąć. Do czasu uzgodnienia płatności opisuj jej stan jako niewyjaśniony i zapewnij zespołowi jedno miejsce do zapisywania identyfikatorów spraw klientów i dalszych działań. Obiecuj termin przywrócenia działania tylko po potwierdzeniu przez osobę obsługującą incydent.