Chyba 500 nebo 522 v PrestaShopu: jaké údaje připravit pro diagnostiku?

Zapište přesnou adresu, čas s časovým pásmem a činnost, po které se chyba objevila. Tyto tři informace umožňují hledat stejnou událost v logách. Samotné číslo 500 nebo 522 ještě neukazuje na modul, který je třeba změnit.

Tento návod pomáhá připravit hlášení pro diagnostiku. Nepopisuje opravu konkrétního obchodu ani nepředstavuje příkladné příčiny jako potvrzený výsledek.

Co si zapsat během výpadku?

1. Adresa a činnost: např. otevření produktu, uložení nastavení v administraci nebo přechod z košíku k dopravě. Nezapisujte do veřejného hlášení tokeny z adresy administrace.
2. Čas: datum, hodina a pásmo, např. 2026-09-26 14:32 Europe/Warsaw. Pokud se problém vrací, zapište si dva nebo tři konkrétní výskyty.
3. Odpověď: HTTP kód, viditelná zpráva a identifikátor požadavku, pokud ho chybová stránka uvádí. Snímek obrazovky doplňte textem zprávy.
4. Rozsah: jedna adresa nebo celý obchod, frontend nebo administrace, přihlášený uživatel nebo host, jedna síť nebo také druhá.
5. Poslední změna: aktualizace, instalace modulu, import, změna nastavení hostingu. Uveďte datum; samotné pořadí událostí ještě nedokazuje příčinu.

Chyba 500 a chyba 522 vyžadují jiné výchozí body

Popis 522 a doporučení pro spojení s původním serverem: dokumentace Cloudflare. Obecný význam statusu 500: HTTP Semantics, RFC 9110.

Jak připravit jednoduchý pokus o reprodukci?

Ukázkový příklad hlášení: „Ve 14:32 otevírám kartu produktu jako host. Dokument má status 500. Domovská stránka ve stejném prohlížeči funguje. Ve 14:35 tentýž produkt funguje z druhé sítě.“ Takový záznam nediagnostikuje příčinu, ale ukazuje konkrétní požadavky k porovnání.

Při každém opakování měňte jednu podmínku a zapisujte výsledek. Pokud současně vymažete cache, změníte PHP a vypnete několik modulů, bude obtížné určit, která změna ovlivnila chování obchodu.

Jaké logy předat osobě provádějící diagnostiku?

Požádejte o kontrolu krátkého časového úseku kolem události: logu aplikace, chyb PHP a webového serveru, a při prostřední vrstvě také jejích událostí. Místo uložení logů závisí na verzi obchodu a konfiguraci hostingu. Místo předpokládání cesty uveďte administrátorovi přesný čas, adresu a metodu požadavku, pokud ji znáte.

Úryvky logů mohou obsahovat e-mailové adresy, identifikátory relací a údaje o objednávkách. Předávejte potřebný výřez dohodnutým kanálem a odstraňte tajné údaje. Také celý soubor HAR může obsahovat takové informace; nezveřejňujte ho jako běžnou přílohu na fóru.

Jak porovnávat vrstvy bez změny ochrany celého obchodu?

Porovnání odpovědi přes CDN a přímo ze serveru by měl připravit administrátor, který zná konfiguraci domény, TLS a přístupu k originu. Rozdíl mezi odpověďmi je vodítkem pro další testy, nikoli automatickým důkazem viny WAF nebo PrestaShopu.

Režim ladění používejte na pracovní kopii nebo v kontrolovaném přístupu. Globální vypnutí ochrany nebo zobrazení podrobných výjimek všem návštěvníkům není potřeba k vytvoření užitečného hlášení.

Hotová šablona hlášení ke stažení

Stáhnout formulář popisu výpadku — TXT. Vyplňte pole a chybějící informaci označte „neověřeno“. Formulář nevyžaduje hesla ani API klíče.

Co zkontrolovat po opravě?

Zopakujte zapsané kroky za stejných podmínek, zkontrolujte výsledek fungování a nové záznamy v logách. U občasného problému jedno správné otevření stránky potvrzuje pouze tento pokus. Domluvte se s realizátorem na době sledování, rozsahu testů a signálu pro opětovné nahlášení.

Pokud se problém objevil při změně verze, využijte také seznam přípravy aktualizace PrestaShopu. Samostatný návod vysvětluje roli bezpečnostních HTTP hlaviček.