Zaznamenajte presný prejav a poslednú zmenu, vytvorte zálohu a pozrite PHP, WordPress a serverové logy v rovnakom čase. Chyby nezobrazujte verejne. Izolujte podozrivý komponent na stagingu alebo cez recovery mode, opravte koreňovú príčinu a po nasadení logovanie znovu zabezpečte.
Kritická chyba WordPressu môže zobraziť všeobecnú správu, bielu stránku alebo iba nefunkčnú administráciu. Viditeľný prejav nehovorí, či príčinou je PHP chyba v plugine, vyčerpaná pamäť, nekompatibilná verzia, poškodený súbor alebo zlyhanie databázy. Náhodné vypínanie a prepisovanie súborov na produkcii môže stratiť dôkazy a vytvoriť ďalšie rozdiely.
Bezpečná diagnostika najprv obmedzí dopad, zachová aktuálny stav a zhromaždí presný čas, URL, rolu a poslednú zmenu. Logovanie sa zapne tak, aby návštevník nevidel technické detaily. Následne sa chyba reprodukuje na stagingu alebo kontrolovaným krokom a oprava sa overí proti pôvodnému scenáru aj ďalším kritickým funkciám.
Najprv stabilizujte a zaznamenajte incident
Overte rozsah: celý web, iba konkrétna URL, administrácia, prihlásený používateľ alebo určitá akcia. Zapíšte čas s časovým pásmom, prehliadač, HTTP stav a kroky reprodukcie. Skontrolujte monitoring a posledné nasadenie, aktualizáciu, import či zmenu hostingu. Rovnaká chyba po jednej akcii je hodnotnejšia stopa než všeobecné „web nejde“.
Pred zásahom vytvorte dostupnú zálohu databázy a súborov alebo snapshot podľa možností hostingu. Ak web spôsobuje škodu, obmedzte kritickú funkciu primeraným servisným stavom, no nezakrývajte administráciu potrebnú na opravu. Pri e-shope myslite na nové objednávky a externé callbacky. Nemažte logy ani podozrivé súbory bez kópie.
Získajte chybu bez zverejnenia detailov
Produkcia nemá posielať návštevníkovi stack trace, cesty servera alebo databázové údaje. WordPress debug log možno dočasne nasmerovať do chráneného súboru a verejné zobrazovanie vypnúť. Hosting môže poskytovať PHP error log, webserver log a aplikačný panel. Časy zosúlaďte, pretože server môže používať iné pásmo než administrácia.
Hľadajte prvú relevantnú fatálnu chybu, typ výnimky, súbor, riadok a call stack. Neskoršie varovania môžu byť iba následok. Rovnaký názov pluginu v ceste ešte nedokazuje vinu; mohol volať chybnú funkciu inej závislosti. Citlivý výpis pred odoslaním podpore redigujte, ale ponechajte technický kontext a korelačné ID.
- Čas a presná URL
- Prvá fatálna chyba v logu
- Súbor, riadok a call stack
- Verejné zobrazenie chýb vypnuté
Použite recovery mode a bezpečnú izoláciu
WordPress môže pri vybraných fatálnych chybách poslať správcovi odkaz do recovery mode, ktorý dočasne pozastaví problémový komponent pre danú reláciu. Overte pravosť správy a prístup k administrátorskému e-mailu. Recovery mode slúži na diagnostiku a opravu, nie ako trvalá prevádzka s neaktuálnym pluginom.
Ak administrácia nie je dostupná, správca môže cez hosting dočasne deaktivovať konkrétny plugin premenovaním jeho adresára alebo použiť CLI. Zásah dokumentujte a nerobte plošne, ak log ukazuje presný komponent. Téma sa prepína opatrne, pretože náhradná nemusí podporovať šablóny. Databázové zmeny robte až po zálohe a dôkaze.
Reprodukujte chybu na porovnateľnom prostredí
Obnovte kópiu na staging s rovnakou verziou PHP, WordPressu, témy, pluginov a relevantných dát. Externé platby a e-maily prepnite do testu. Zopakujte presný scenár a potom meňte jednu premennú: verziu, komponent alebo vstup. Binárne vypínanie skupín pluginov môže urýchliť izoláciu, no výsledok potvrďte konkrétnou interakciou.
Ak chyba závisí od objemu alebo súbehu, malá prázdna inštalácia ju nemusí ukázať. Použite anonymizovanú reprezentatívnu vzorku a profilovanie pamäte či dotazov. Dočasné zvýšenie limitu môže potvrdiť vyčerpanie, ale nie je koreňovou opravou nekonečnej slučky. Pri chybe tretej strany pripravte minimálny reprodukčný príklad a presné verzie.
- Rovnaké verzie a konfigurácia
- Jedna zmena na test
- Externé služby v testovacom režime
- Reprezentatívny objem dát
Opravte, nasaďte a uzavrite príčinu
Aktualizujte alebo opravte konkrétny komponent, prípadne vráťte poslednú zmenu cez pripravený postup. Staršiu zraniteľnú verziu neponechávajte bez plánu. Pred produkciou spustite pôvodný scenár, editor, formuláre, prihlásenie a ďalšie kritické cesty. Nasadzujte mimo špičky a sledujte log v reálnom čase s možnosťou rýchleho návratu.
Po stabilizácii odstráňte dočasné debug nastavenia, testovacie účty a verejné diagnostické súbory. Zapíšte koreňovú príčinu, detekciu, opravu a preventívnu zmenu, napríklad kompatibilitný test alebo monitoring konkrétnej udalosti. Ak sa incident týkal bezpečnosti či dát, zapojte zodpovedné osoby podľa reálneho rozsahu. Uzavretie nie je iba zmiznutá chybová obrazovka.
Časté otázky
Mám zapnúť WP_DEBUG na produkčnom webe?
Pri diagnostike možno dočasne bezpečne zapisovať chyby do chráneného logu, ale nezobrazovať ich návštevníkom. Nastavenie, umiestnenie logu a prístup musí spravovať technická osoba a po vyriešení ho treba vrátiť.
Čo ak kritická chyba zablokovala aj administráciu?
Použite recovery mode, hostingový správca súborov alebo CLI na cielenú deaktiváciu komponentu uvedeného v logu. Najprv zachovajte zálohu a stav. Náhodné premenovanie všetkých pluginov komplikuje diagnostiku a funkcie.
Stačí obnoviť web zo zálohy?
Obnova môže rýchlo vrátiť prevádzku, no bez určenia príčiny sa chyba zopakuje pri ďalšej aktualizácii alebo rovnakom vstupe. Po obnove porovnajte zmeny, opravte koreňový problém a monitorujte výsledok.
Zdroje a ďalšie čítanie
Web developer zo Spišskej Novej Vsi. Venuje sa WordPressu, WooCommerce, vlastným pluginom, API integráciám, webovým aplikáciám a praktickým AI automatizáciám.
