Zaznamenejte přesný projev a poslední změnu, vytvořte zálohu a projděte logy PHP, WordPressu a serveru ze stejného času. Chyby nezobrazujte veřejně. Izolujte podezřelou komponentu na stagingu nebo přes recovery mode, opravte kořenovou příčinu a po nasazení logování znovu zabezpečte.
Kritická chyba WordPressu se může projevit obecnou zprávou, bílou stránkou nebo pouze nefunkční administrací. Viditelný projev neprozradí, zda je příčinou chyba PHP v pluginu, vyčerpaná paměť, nekompatibilní verze, poškozený soubor nebo selhání databáze. Nahodilé vypínání a přepisování souborů na produkci může zničit důkazy a vytvořit další rozdíly.
Bezpečná diagnostika nejprve omezí dopad, zachová aktuální stav a shromáždí přesný čas, URL, roli a poslední změnu. Logování se zapne tak, aby návštěvník neviděl technické detaily. Následně se chyba reprodukuje na stagingu nebo kontrolovaným krokem a oprava se ověří proti původnímu scénáři i dalším kritickým funkcím.
Nejprve stabilizujte a zaznamenejte incident
Ověřte rozsah: celý web, pouze konkrétní URL, administrace, přihlášený uživatel nebo určitá akce. Zapište čas s časovým pásmem, prohlížeč, HTTP stav a kroky reprodukce. Zkontrolujte monitoring a poslední nasazení, aktualizaci, import či změnu hostingu. Stejná chyba po jedné akci je hodnotnější stopou než obecné „web nejde“.
Před zásahem vytvořte dostupnou zálohu databáze a souborů nebo snapshot podle možností hostingu. Pokud web způsobuje škodu, omezte kritickou funkci přiměřeným servisním stavem, ale neznepřístupňujte administraci potřebnou k opravě. U e-shopu myslete na nové objednávky a externí callbacky. Nemažte logy ani podezřelé soubory bez kopie.
Získejte chybu bez zveřejnění detailů
Produkce nemá návštěvníkovi posílat stack trace, cesty serveru ani databázové údaje. WordPress debug log lze dočasně nasměrovat do chráněného souboru a veřejné zobrazování vypnout. Hosting může poskytovat PHP error log, log webserveru a aplikační panel. Časy sjednoťte, protože server může používat jiné pásmo než administrace.
Hledejte první relevantní fatální chybu, typ výjimky, soubor, řádek a call stack. Pozdější varování mohou být jen důsledkem. Stejný název pluginu v cestě ještě nedokazuje vinu; mohl volat chybnou funkci jiné závislosti. Citlivý výpis před odesláním podpoře redigujte, ale ponechte technický kontext a korelační ID.
- Čas a přesná URL
- První fatální chyba v logu
- Soubor, řádek a call stack
- Veřejné zobrazení chyb vypnuto
Použijte recovery mode a bezpečnou izolaci
WordPress může při vybraných fatálních chybách poslat správci odkaz do recovery mode, který dočasně pozastaví problémovou komponentu pro danou relaci. Ověřte pravost zprávy a přístup k administrátorskému e-mailu. Recovery mode slouží k diagnostice a opravě, nikoli k trvalému provozu s neaktuálním pluginem.
Pokud administrace není dostupná, správce může přes hosting dočasně deaktivovat konkrétní plugin přejmenováním jeho adresáře nebo použít CLI. Zásah dokumentujte a neprovádějte ho plošně, pokud log ukazuje přesnou komponentu. Šablonu přepínejte opatrně, protože náhradní nemusí podporovat potřebné šablony stránek. Databázové změny provádějte až po záloze a doložení příčiny.
Reprodukujte chybu ve srovnatelném prostředí
Obnovte kopii na staging se stejnou verzí PHP, WordPressu, šablony, pluginů a relevantních dat. Externí platby a e-maily přepněte do testovacího režimu. Zopakujte přesný scénář a poté měňte jednu proměnnou: verzi, komponentu nebo vstup. Binární vypínání skupin pluginů může urychlit izolaci, ale výsledek potvrďte konkrétní interakcí.
Pokud chyba závisí na objemu nebo souběhu, malá prázdná instalace ji nemusí ukázat. Použijte anonymizovaný reprezentativní vzorek a profilování paměti či dotazů. Dočasné zvýšení limitu může potvrdit vyčerpání, ale není kořenovou opravou nekonečné smyčky. U chyby třetí strany připravte minimální reprodukční příklad a přesné verze.
- Stejné verze a konfigurace
- Jedna změna na test
- Externí služby v testovacím režimu
- Reprezentativní objem dat
Opravte, nasaďte a uzavřete příčinu
Aktualizujte nebo opravte konkrétní komponentu, případně vraťte poslední změnu pomocí připraveného postupu. Starší zranitelnou verzi neponechávejte bez plánu. Před produkcí spusťte původní scénář, editor, formuláře, přihlášení a další kritické cesty. Nasazujte mimo špičku a sledujte log v reálném čase s možností rychlého návratu.
Po stabilizaci odstraňte dočasná debug nastavení, testovací účty a veřejné diagnostické soubory. Zapište kořenovou příčinu, detekci, opravu a preventivní změnu, například test kompatibility nebo monitoring konkrétní události. Pokud se incident týkal bezpečnosti či dat, zapojte odpovědné osoby podle skutečného rozsahu. Uzavření neznamená jen to, že zmizela chybová obrazovka.
Časté dotazy
Mám zapnout WP_DEBUG na produkčním webu?
Při diagnostice lze dočasně bezpečně zapisovat chyby do chráněného logu, ale nezobrazovat je návštěvníkům. Nastavení, umístění logu a přístup musí spravovat technická osoba a po vyřešení je třeba ho vrátit.
Co když kritická chyba zablokovala i administraci?
Použijte recovery mode, hostingový správce souborů nebo CLI k cílené deaktivaci komponenty uvedené v logu. Nejprve zachovejte zálohu a aktuální stav. Náhodné přejmenování všech pluginů komplikuje diagnostiku i funkce.
Stačí obnovit web ze zálohy?
Obnova může rychle vrátit provoz, ale bez určení příčiny se chyba zopakuje při další aktualizaci nebo stejném vstupu. Po obnově porovnejte změny, opravte kořenový problém a monitorujte výsledek.
Zdroje a další čtení
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
