Preskoči na sadržaj
Pošaljite upit
WordPress / Troubleshooting / Critical Error

WordPress Critical Error – kako pronaći uzrok i popraviti kritičnu grešku

Poruka „There has been a critical error on this website“ ne govori šta je konkretno pokvareno. Ona samo znači da je WordPress naišao na ozbiljnu grešku zbog koje izvršavanje stranice nije moglo normalno da se završi. Pravi posao počinje tek kada pronađemo šta je grešku izazvalo.

DIAGNOSE FIRST PLUGIN / THEME / PHP LOG → ROOT CAUSE MINIMAL CHANGE

WordPress Critical Error najčešće znači da je nastala fatalna PHP greška. Uzrok može biti plugin, tema, prilagođeni kod, PHP kompatibilnost, nedostatak memorije ili druga serverska greška. Najbezbedniji pristup nije nasumično isključivanje svega, već pronalaženje konkretnog errora u Recovery Mode-u, PHP/server logu ili WordPress debug logu, a zatim ciljana intervencija na komponenti koja problem izaziva.

Šta zapravo znači „There has been a critical error on this website“?

Critical Error je opšta WordPress poruka koja se prikazuje kada ozbiljna PHP greška prekine normalno izvršavanje sajta. Sama poruka ne otkriva uzrok — za to su potrebni Recovery Mode ili logovi.

WordPress sadrži zaštitu od fatalnih grešaka kako posetiocima ne bi prikazivao sirovu PHP poruku sa detaljima sistema. Zato umesto tehničkog errora često vidite samo poruku da je na sajtu došlo do kritične greške.

U pozadini, međutim, obično postoji mnogo konkretniji trag: naziv PHP greške, fajl u kome se dogodila, broj linije i često putanja koja pokazuje ka određenom pluginu, temi ili delu prilagođenog koda.

Važno

„Critical Error“ je simptom, ne dijagnoza. Ako samo uklonimo poruku, a ne razumemo zbog čega se pojavila, problem može ostati u sistemu ili se vratiti pri sledećem učitavanju, update-u ili izvršavanju iste funkcije.

Šta prvo uraditi kada se pojavi WordPress Critical Error?

01

Zabeležite šta se poslednje promenilo

Da li je neposredno pre greške ažuriran plugin, tema ili WordPress? Da li je promenjena PHP verzija, dodat kod, instaliran novi plugin ili menjana konfiguracija servera?

02

Proverite administratorski email

WordPress u određenim slučajevima šalje administratoru Recovery Mode poruku sa informacijom o komponenti koja je izazvala fatalnu grešku i posebnim linkom za pristup administraciji.

03

Obezbedite mogućnost povratka

Pre izmene fajlova, plugina, teme ili baze treba imati upotrebljiv backup ili drugu pouzdanu tačku povratka, posebno kada je sajt produkcioni.

04

Pronađite konkretan error

PHP/server error log, WordPress debug.log ili Recovery Mode obično daju mnogo vredniju informaciju od same poruke koju vidite u browseru.

Nemojte menjati pet stvari odjednom

Ako istovremeno promenite PHP verziju, deaktivirate plugine, prebacite temu i vratite backup, možda ćete dobiti funkcionalan sajt — ali nećete znati šta je zaista rešilo problem niti šta je sledeći rizik.

Najčešći uzroci Critical Error greške

Veza između simptoma i uzroka nije uvek očigledna, ali kontekst u kome je problem nastao može pomoći da se dijagnostika usmeri na pravi sloj sistema.

Šta se dogodilo Šta prvo proveriti
Greška se pojavila odmah nakon update-a plugina Fatal error, kompatibilnost plugina, zavisnosti i konflikt sa drugim komponentama
Problem je počeo nakon promene PHP verzije Kompatibilnost teme, plugina i custom koda sa novom PHP verzijom
Critical Error postoji samo na određenoj stranici Kod ili plugin koji se izvršava samo na toj stranici, template, shortcode ili widget
Ne radi ni frontend ni wp-admin Komponenta koja se učitava globalno, tema, plugin, PHP ili core/runtime problem
Log sadrži „Allowed memory size exhausted“ Potrošnja memorije i proces koji je do limita doveo — ne samo povećanje limita
Problem se javlja povremeno Resursi, cron, AJAX, spoljni servis, cache ili funkcija koja se izvršava samo u određenim uslovima

Ova tabela je početna orijentacija, ne konačna dijagnoza. Na primer, ako se greška pojavila odmah nakon update-a jednog plugina, taj update jeste važan trag — ali uzrok može biti i konflikt između tog plugina, teme, drugog dodatka ili PHP verzije.

Kako pronaći stvarni uzrok Critical Error greške

SIMPTOM→ LOG→ KOMPONENTA→ ROOT CAUSE→ FIX→ VERIFY

1. WordPress Recovery Mode

WordPress Recovery Mode je ugrađeni mehanizam koji se aktivira kod određenih fatalnih PHP grešaka. Kada je dostupan, administrator dobija poseban link kojim može da se prijavi u WordPress i pristupi administraciji dok je problematična tema ili plugin pauziran za tu administratorsku sesiju.

Recovery Mode često odmah daje važan trag o komponenti koja je izazvala problem. To ne znači nužno da je dovoljno trajno deaktivirati taj plugin ili temu — cilj je utvrditi zašto je fatalna greška nastala i koje je održivo rešenje.

Ako email nije stigao, proverite Spam/Junk folder i da li je administratorska email adresa ispravna. Nedolazak poruke ne znači da Recovery Mode ili fatal error nisu postojali; WordPress email može biti blokiran ili neuspešno isporučen na nivou servera.

2. PHP i server error log

Kada postoji pristup hostingu ili serveru, PHP/error log je često najbrži put do konkretnog uzroka. Umesto poruke „Critical Error“, u logu možemo dobiti nešto nalik ovom:

PHP Fatal error: Uncaught Error: Call to undefined function ... in /wp-content/plugins/example-plugin/includes/example.php on line 147

Za početnu dijagnostiku posebno su važne informacije poput PHP Fatal error, putanje fajla, naziva plugina ili teme i vremena kada je greška nastala.

Sama činjenica da se putanja završava unutar nekog plugina ipak nije uvek dovoljan dokaz da je taj plugin jedini krivac. Stack trace i okolnosti greške mogu pokazati da je problem nastao kroz interakciju više komponenti.

3. WordPress WP_DEBUG i debug.log

Ako nema dovoljno informacija u dostupnim logovima, WordPress ima sopstveni debugging mehanizam. U wp-config.php se privremeno mogu uključiti debug i zapisivanje grešaka u log:

define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false );

Kada je konfiguracija standardna, WordPress može zapisivati poruke u /wp-content/debug.log. Podešavanje WP_DEBUG_DISPLAY na false sprečava prikaz tehničkih grešaka posetiocima dok se informacije beleže u log.

Debug nije trajno produkciono podešavanje

Debugging treba uključiti ciljano i privremeno. Nakon dijagnostike treba vratiti odgovarajuću produkcionu konfiguraciju i proveriti da tehničke informacije nisu javno dostupne.

Kako se WordPress Critical Error rešava?

Rešenje zavisi od konkretnog errora. Najbezbednije je prvo identifikovati komponentu koja izaziva fatalnu grešku, zatim napraviti najmanju potrebnu izmenu i posle toga proveriti ostatak sajta.

Ako je uzrok WordPress plugin

Problematičan plugin se može privremeno deaktivirati kroz WordPress administraciju, Recovery Mode ili, kada wp-admin nije dostupan, kroz File Manager/FTP promenom naziva njegovog direktorijuma.

Nakon što sajt ponovo postane dostupan, treba proveriti zašto je greška nastala: da li postoji novija ispravka, konflikt sa drugim pluginom, nekompatibilnost sa PHP verzijom, problem sa custom kodom ili druga zavisnost.

Ako je uzrok tema

Fatalna greška može nastati u samoj temi, child temi ili prilagođenom kodu dodatom kroz functions.php. Privremeni prelazak na poznatu ispravnu temu može pomoći u izolaciji problema, ali nije cilj sam po sebi — posebno na produkcionom sajtu gde promena teme može ozbiljno promeniti prikaz i funkcionalnost.

Ako je problem PHP kompatibilnost

Promena PHP verzije može otkriti zastareo ili nekompatibilan kod u pluginu, temi ili custom funkciji. U tom slučaju nije dovoljno samo nasumično spuštati ili podizati PHP verziju dok sajt ne proradi.

Treba utvrditi koja komponenta ne podržava trenutnu verziju i odlučiti da li se ona ažurira, menja, popravlja ili se privremeno koristi druga podržana PHP konfiguracija.

Ako log prijavljuje nedostatak memorije

Poruka Allowed memory size exhausted znači da je proces dostigao raspoloživi PHP memory limit. Povećanje limita ponekad jeste legitimno rešenje, ali prvo treba proveriti zašto je do potrošnje došlo.

Plugin koji pravi beskonačnu petlju ili izvršava izuzetno skup proces neće postati „zdrav“ samo zato što mu je dozvoljeno da potroši još memorije.

Ako je update ostao nepotpun

Prekinuto ažuriranje, nepotpuno kopirani fajlovi, neuspešna instalacija ili problem sa dozvolama mogu ostaviti WordPress komponentu u nekonzistentnom stanju. U takvoj situaciji može biti potrebno ponovno postavljanje ispravne verzije fajlova ili kontrolisani rollback.

Šta ne treba raditi kada WordPress prijavi Critical Error

  • Ne ažurirajte sve ostale plugine i temu „za svaki slučaj“ dok ne znate šta je problem.
  • Ne brišite problematičan plugin pre nego što proverite da li sadrži podatke ili konfiguraciju koju treba sačuvati.
  • Ne vraćajte veoma star backup bez provere šta ćete tim restore-om izgubiti.
  • Ne menjajte istovremeno PHP, temu, plugine, cache i server konfiguraciju.
  • Ne ostavljajte debug informacije javno prikazane na produkcionom sajtu.
  • Ne pretpostavljajte da je poslednja ažurirana komponenta automatski i jedini uzrok.
  • Ne proglašavajte problem rešenim samo zato što početna stranica ponovo može da se otvori.

Critical Error je nestao. Da li je problem stvarno rešen?

Ne nužno. Nakon popravke treba ponoviti scenario koji je izazivao grešku i proveriti funkcije koje su mogle biti pogođene intervencijom.

Ako je, na primer, Critical Error nestao nakon deaktivacije WooCommerce dodatka, činjenica da se početna ponovo otvara nije dovoljna. Potrebno je proveriti prodavnicu, proizvod, korpu, checkout i funkciju koju je taj dodatak obavljao.

Isto važi za poslovne sajtove: kontakt forma, administratorski deo, višejezičnost, rezervacije, login korisnika ili druge kritične funkcije mogu biti pogođene iako frontend na prvi pogled izgleda normalno.

Dobar završetak intervencije

Problem može ponovo da se testira, uzrok je dovoljno jasno identifikovan, promena je ograničena na ono što je potrebno, a ključne funkcije sajta rade i nakon popravke.

Kada Critical Error više nije dobar DIY problem?

Ako imate pouzdan backup, pristup fajlovima i jasan error koji pokazuje na jednostavan problem, intervencija često može biti relativno kratka.

Stručna dijagnostika ima više smisla kada:

  • nemate pristup wp-admin delu;
  • Recovery Mode email ne stiže;
  • ne znate gde se nalaze server/PHP logovi;
  • greška se vraća i nakon privremenog rešenja;
  • problem postoji samo povremeno ili samo na određenim stranicama;
  • u logu postoji više različitih fatalnih grešaka;
  • sajt ima WooCommerce, rezervacije, članstvo ili druge poslovno kritične funkcije;
  • nije jasno šta je promenjeno neposredno pre kvara.

Kako WP Podrška pristupa ovakvom problemu

Ne gasimo nasumično pola sajta i ne zovemo to dijagnostikom. Cilj je da problem može da se reprodukuje, izoluje i objasni, a tek zatim da se napravi ciljana promena.

01 / REPRODUCE

Potvrđujemo simptom

Utvrđujemo kada se greška pojavljuje, gde i šta joj je prethodilo.

02 / ISOLATE

Sužavamo problem

Plugin, tema, PHP, server, custom kod ili drugi sloj sistema.

03 / ROOT CAUSE

Tražimo stvarni uzrok

Logovi i ponašanje sistema treba da objasne zašto je greška nastala.

04 / FIX

Menjamo samo ono što treba

Bez nepotrebnog refaktorisanja delova sajta koji nisu povezani sa problemom.

05 / VERIFY

Ponovo testiramo

Nestanak poruke nije dovoljan — proveravamo simptom i ključne funkcije.

06 / NEXT STEP

Odvajamo incident od budućeg rada

Ako postoji širi tehnički dug, tretiramo ga odvojeno od hitne popravke.

Povezane WordPress usluge i vodiči

Najčešća pitanja o WordPress Critical Error grešci

Šta znači Critical Error u WordPressu?

Critical Error znači da je WordPress tokom izvršavanja naišao na ozbiljnu grešku, najčešće PHP fatal error, zbog koje stranica ili deo sistema ne može normalno da nastavi rad. Pravi uzrok treba pronaći kroz Recovery Mode ili odgovarajuće logove.

Zašto nisam dobio WordPress Recovery Mode email?

Poruka može završiti u spam folderu, administratorska email adresa može biti pogrešna ili server možda ne uspeva pouzdano da isporuči WordPress email. Ako email nije stigao, uzrok greške se i dalje može tražiti kroz server/PHP log ili WordPress debugging.

Kako deaktivirati plugin ako wp-admin ne radi?

Kada imate pristup hosting File Manager-u ili FTP-u, određeni plugin se može privremeno deaktivirati promenom naziva njegovog direktorijuma unutar /wp-content/plugins/. Ovo treba raditi ciljano kada postoji razlog da se sumnja baš na tu komponentu.

Može li promena PHP verzije izazvati Critical Error?

Da. Tema, plugin ili prilagođeni kod mogu koristiti funkcije ili sintaksu koje nisu kompatibilne sa novom PHP verzijom. U tom slučaju log obično daje konkretnu PHP grešku koja pokazuje gde je izvršavanje prekinuto.

Da li treba odmah vratiti backup?

Ne automatski. Backup je važna zaštitna mreža, ali restore može vratiti i stare probleme ili ukloniti novije porudžbine, sadržaj i druge podatke. Kada je moguće, prvo treba utvrditi šta se pokvarilo i da li postoji manje invazivno rešenje.

Da li Critical Error znači da je WordPress sajt hakovan?

Ne. Critical Error sam po sebi nije dokaz kompromitacije. Mnogo češći uzroci su greška u pluginu ili temi, PHP kompatibilnost, custom kod ili nedostatak resursa. Ako postoje i drugi indikatori kompromitacije, bezbednosna provera se radi kao poseban deo dijagnostike.

Za tehničke procedure korišćena je zvanična WordPress dokumentacija: Recovery Mode i Debugging in WordPress .
CRITICAL ERROR / WORDPRESS SUPPORT

Critical Error i dalje nije rešen?

Ako ne možete da otvorite wp-admin, nemate pristup logovima ili nije jasno koja komponenta izaziva fatalnu grešku, nema potrebe da dalje menjate sajt metodom pokušaja i greške. Pošaljite adresu sajta, poruku koju vidite i, ako znate, napišite šta se poslednje menjalo. Od toga kreće dijagnostika.

Opišite problem →