# WordPress kritična greška: kako vratiti sajt posle ažuriranja

[Izvor](https://nijefila.rs/blog/wordpress-kriticna-greska-posle-azuriranja) · [Nikola Filić](https://nijefila.rs/o-nama#nikola-filic)

Objavljeno: 2026-10-13 · Poslednja tehnička provera: 2026-10-13

Kliknete na Ažuriraj, sačekate nekoliko sekundi, pa umesto sajta dobijete poruku da je došlo do kritične greške. Pokušate da otvorite administraciju, a ista poruka dočeka vas i tamo. U tom trenutku je lako krenuti sa brisanjem dodataka ili vraćanjem celog sajta iz jučerašnje kopije. Pre toga vredi pogledati šta je tačno stalo. Sadržaj sajta često je i dalje u bazi, dok jedna greška sprečava WordPress da prikaže stranicu.

## Šta prvo uraditi kada WordPress prijavi kritičnu grešku

Proverite administratorski email za WordPress Recovery Mode link. Ako ga nema, potražite PHP error log u hostingu ili zatražite pomoć podrške. Kada poruka greške upućuje na konkretan dodatak, privremeno ga isključite kroz administraciju ili preimenovanjem njegovog foldera. Pre vraćanja stare baze sačuvajte trenutno stanje, posebno ako sajt prima porudžbine ili upite.

Poruka `There has been a critical error on this website`, odnosno njen prevod, obično znači da je PHP izvršavanje prekinula fatalna greška. Sam tekst ne otkriva uzrok. To može biti dodatak, tema, izmenjen kod ili nedostatak memorije. [WordPress vodič kroz česte greške](https://developer.wordpress.org/advanced-administration/wordpress/common-errors/) opisuje ove različite slučajeve. Ako pregledač umesto toga kaže da ne može da pronađe server ili da sertifikat nije važeći, počnite od [vodiča za sajt koji ne radi](/blog/sajt-ne-radi).

Zapišite kada je problem počeo i šta je poslednje menjano: naziv i verziju dodatka, temu, WordPress ili PHP verziju. Proverite da li greška pogađa ceo sajt, samo administraciju ili jednu stranicu. Nemojte istovremeno menjati PHP, gasiti pet dodataka i vraćati backup. Posle takve intervencije teško je saznati šta je pomoglo.

## Recovery Mode: pristup administraciji kroz email

WordPress za određene fatalne greške šalje poruku na administratorsku email adresu sajta, sa informacijama o problemu i posebnim linkom za prijavu. To je adresa iz opštih podešavanja sajta, koja ne mora biti ista kao adresa vašeg korisničkog naloga. Proverite i spam folder. U [zvaničnom uputstvu za Recovery Mode](https://wordpress.org/documentation/article/recovery-mode/) opisan je ovaj način povratka u administraciju.

Otvorite link iz poruke koju ste očekivali zbog ovog problema, proverite da vodi na vaš sajt i prijavite se svojim nalogom. U administraciji pročitajte obaveštenje o dodatku ili temi koja je izazvala grešku. Ako je problem u dodatku, otvorite `Plugins → Installed Plugins` odnosno `Dodaci` i deaktivirajte baš taj dodatak. Kod teme, prelazak na već instaliranu kompatibilnu temu dogovorite sa osobom koja održava sajt, jer menja izgled i može uticati na njegove funkcije.

Recovery Mode može da pauzira problematičnu komponentu samo za vašu sesiju. Zato uspešna prijava ne dokazuje da posetioci ponovo vide sajt. Tu razliku objašnjava i [WordPress Core opis mehanizma oporavka](https://make.wordpress.org/core/2019/04/16/fatal-error-recovery-mode-in-5-2/). Posle intervencije izađite iz ovog režima i otvorite sajt u privatnom prozoru, bez administratorske prijave.

Ako email ne stiže, nemojte čekati da se pojavi. Greška može nastati pre nego što se učita dodatak koji inače upravlja slanjem. U tom slučaju čak ni prethodno ispravan SMTP ne garantuje dostavu poruke za oporavak. Način slanja proverite kada vratite pristup, prema [vodiču za WordPress email](/blog/wordpress-ne-salje-email-kontakt-forma).

## Kako isključiti problematičan dodatak bez wp-admin pristupa

Ako iz emaila ili loga znate koji dodatak pravi problem, možete privremeno promeniti naziv njegovog foldera kroz upravljač fajlova u hosting panelu ili SFTP. WordPress tada neće pronaći dodatak na očekivanom mestu. Sačuvajte kopiju foldera i zabeležite njegovo prvobitno ime. Preimenovanje koristite za oporavak pristupa; nemojte brisati fajlove.

Prvo otvorite folder tačne WordPress instalacije. Ako na nalogu imate više sajtova, proverite u kom ste direktorijumu. Prepoznaćete ga po `wp-config.php`, `wp-admin`, `wp-includes` i `wp-content`. Put do dodatka u ovom primeru je izmišljen:

```text
Pre izmene:
wp-content/plugins/primer-dodatka/

Privremeno preimenujte samo taj folder:
wp-content/plugins/primer-dodatka-iskljucen/
```

- Ponovo otvorite administraciju. Ako uspete da se prijavite, otvorite stranicu `Dodaci`, odnosno `/wp-admin/plugins.php`, da WordPress evidentira nedostajući dodatak kao deaktiviran.
- Vratite folderu prvobitno ime. U administraciji proverite da dodatak ostaje neaktivan i ostavite ga tako dok ne rešite grešku.
- Otvorite javni sajt i proverite šta bez tog dodatka više ne radi. Deaktivacija dodatka za forme, prodavnicu ili plaćanje može da vrati stranicu, a da ta funkcija i dalje nedostaje.

WordPress opisuje preimenovanje foldera u [uputstvu za pristup kada dodaci blokiraju administraciju](https://wordpress.org/documentation/article/faq-troubleshooting/). Njihov postupak može da isključi sve dodatke; kada imate trag o konkretnom uzroku, počnite samo od njega. Ako isključenje ne promeni ništa, sačuvajte rezultat probe i nastavite sa logom ili podrškom. Ovaj postupak se odnosi na obične dodatke u `wp-content/plugins`, ne na sve vrste dodatnog koda koji sajt može da učitava.

## Šta tražiti u error logu

U hosting panelu potražite PHP error log za taj sajt. Naziv i mesto zavise od podešavanja servera, pa podršci pošaljite vreme kada ste otvorili stranicu i dobili grešku. Tražite zapis koji se poklapa sa tom probom. Starije upozorenje u logu može da nema nikakve veze sa današnjim padom.

Ovakav skraćeni zapis je primer, ne log stvarnog klijenta:

```text
PHP Fatal error: Uncaught Error:
Call to undefined function primer_funkcije()
in .../wp-content/plugins/primer-dodatka/includes/start.php:42
```

Naziv dodatka u putanji daje početni trag. Poslednja linija nije uvek dokaz da je baš taj dodatak samostalno kriv: može zavisiti od drugog dodatka, biblioteke ili PHP funkcije. Sačuvajte celu poruku i relevantni deo niza poziva, odnosno stack trace-a, za autora dodatka ili osobu koja održava sajt. Nemojte menjati liniju 42 samo zato što je navedena u grešci.

Ako postojeći log nema potreban zapis, [WordPress dokumentacija za debugging](https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/) omogućava uključivanje logovanja kroz `WP_DEBUG` i `WP_DEBUG_LOG`, uz isključen `WP_DEBUG_DISPLAY`. Na aktivnom sajtu zatražite da log ide u privatnu, upisivu putanju van javnog web direktorijuma. Podrazumevani `wp-content/debug.log` može biti dostupan preko weba ako server ne blokira pristup. Ne prikazujte PHP greške posetiocima; logovanje isključite po završetku dijagnostike i uklonite ili zaštitite nastali fajl.

## PHP verzija i memorija: dva različita uzroka

Ako je problem počeo odmah posle promene PHP verzije, zabeležite obe verzije i privremeno vratite prethodnu ako je dostupna u panelu. Ako se sajt ponovo otvara, proverite koji dodatak ili tema ne podržava novu verziju i ispravite ili zamenite taj kod pre narednog prelaska. Detaljan postupak imate u [vodiču za PHP verziju WordPress-a](/blog/php-verzija-wordpress).

Poruka `Allowed memory size exhausted` govori da je PHP zahtev dostigao dozvoljenu memoriju. Prema [PHP dokumentaciji](https://www.php.net/manual/en/ini.core.php), `memory_limit` ograničava memoriju koju skripta može da zauzme. To nije isto što i pun disk ili ukupna količina RAM-a u hosting paketu.

Proverite pri kojoj radnji greška nastaje: otvaranju obične stranice, radu u vizuelnom editoru, uvozu proizvoda ili pravljenju rezervne kopije. Podrška može da proveri efektivni PHP limit i mogućnosti naloga. Povećanje limita ima smisla ako zadatak zahteva više memorije i hosting to dozvoljava, ali ne rešava kod koji memoriju troši bez kontrole. Nemojte naslepo upisati veliki broj u `wp-config.php` i pretpostaviti da je server prihvatio promenu.

## Kada vratiti backup, a kada sačuvati novu bazu

Backup pomaže kada nema brze ispravke, ali prvo pogledajte njegov datum i šta ćete vratiti. Kopija fajlova vraća kod, temu i dodatke. Kopija baze vraća i sadržaj, podešavanja i poslovne podatke na ranije stanje. Ako je problem u jednom dodatku, vraćanje cele baze može da napravi veći gubitak nego što je potreban.

Primer: backup je napravljen u 02:00, sajt je primao porudžbine do podneva, a ažuriranje ga je oborilo u 12:15. Vraćanje baze iz 02:00 može da ukloni porudžbine nastale između ta dva trenutka. [WooCommerce dokumentacija o vraćanju kopija](https://woocommerce.com/document/subscriptions/restore-backup-subscriptions/) izričito upozorava na nedostajuće porudžbine i korisničke podatke iz tog perioda. Prodavnica koja radi sa pretplatama ima i dodatne rizike pri ponovnom pokretanju zakazanih naplata.

Pre restore-a sačuvajte trenutne fajlove i bazu, čak i kada se sajt ne otvara. Sa osobom koja održava prodavnicu dogovorite šta sme da se prepiše. Vraćanje samo starijih fajlova može da pomogne, ali nije bezbedno pretpostaviti da će oni raditi sa bazom koju je novija verzija dodatka već izmenila. Kada postoje promene strukture baze, plan oporavka mora da obuhvati i njih. O pripremi kopija pišemo u [vodiču za WordPress backup](/blog/backup-wordpress-sajta).

## Posle oporavka proverite formu i porudžbine

Kada pronađete uzrok, ispravku uzmite od zvaničnog autora dodatka ili teme. Ako popravka još ne postoji, procenite može li problematična funkcija privremeno da ostane isključena ili joj treba zamena. Vraćanje stare verzije tretirajte kao privremenu odluku, uz proveru bezbednosti i kompatibilnosti. Pre sledećeg ažuriranja isprobajte promenu na [staging kopiji sajta](/blog/sta-je-staging-sajt).

Početna strana može da radi i kada forma ne prima upite ili naplata ne prolazi. Otvorite sajt bez prijave, proverite administraciju i funkciju koju ste privremeno isključili. Za poslovni sajt pošaljite probni upit i proverite dostavu. Za prodavnicu prođite korpu i probnu porudžbinu prema postojećem postupku, uz proveru email obaveštenja. Potom pogledajte da li se nova fatalna greška pojavila u logu.

Ako ne možete sami da završite oporavak, podršci pošaljite URL sajta, vreme nastanka problema, poslednju izmenu, PHP verziju, naziv i verziju sumnjivog dodatka i redigovan zapis greške. Navedite šta ste već probali i da li imate nove porudžbine koje backup ne sme da prepiše. Sa tim podacima podrška može da uporedi vašu probu sa serverskim logom.

[Otvorite tiket za svoj sajt](https://billing.nijefila.rs/submitticket.php)
Ako koristite NIJEFILA hosting, pošaljite ove podatke kroz korisnički portal. Proverićemo serverske logove i dogovoriti sledeći korak; izmena koda dodatka može zahtevati njegovog autora ili vašeg programera.

## Česta pitanja

### Da li kritična greška znači da su tekstovi i porudžbine obrisani?

Sama poruka to ne znači. Fatalna greška može sprečiti prikaz stranice dok podaci i dalje postoje u bazi. Pre reinstalacije ili vraćanja kopije sačuvajte trenutno stanje i proverite uzrok.

### Zašto sajt radi u Recovery Mode-u, a posetiocima i dalje prikazuje grešku?

Recovery Mode može da pauzira problematičan dodatak ili temu samo u vašoj sesiji. Potrebno je stvarno rešiti uzrok ili deaktivirati komponentu, izaći iz režima oporavka i proveriti sajt bez prijave.

### Da li treba da obrišem dodatak koji je napravio grešku?

Za početak ga deaktivirajte ili privremeno preimenujte njegov folder. Brisanje nije potrebno za ovu proveru i kod nekih dodataka pokreće uklanjanje podataka. Sačuvajte kopiju i proverite šta ostatak sajta radi bez tog dodatka.

### Da li kupovina većeg hosting paketa rešava kritičnu grešku?

Samo ako je uzrok zaista odgovarajući limit resursa i novi paket ga menja. Grešku u kodu, nekompatibilan dodatak ili pogrešnu PHP verziju veći paket ne ispravlja. Odluku donesite na osnovu loga i efektivnih limita naloga.

## Izvori

- [WordPress — Recovery Mode](https://wordpress.org/documentation/article/recovery-mode/)

- [WordPress Core — kako radi oporavak od fatalnih grešaka](https://make.wordpress.org/core/2019/04/16/fatal-error-recovery-mode-in-5-2/)

- [WordPress — pristup administraciji i deaktivacija dodataka](https://wordpress.org/documentation/article/faq-troubleshooting/)

- [WordPress — česte greške](https://developer.wordpress.org/advanced-administration/wordpress/common-errors/)

- [WordPress — bezbedno logovanje pri dijagnostici](https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/)

- [WordPress — instalacija, deaktivacija i brisanje dodataka](https://wordpress.org/documentation/article/plugins-screen/)

- [WordPress — šta dodatak može ukloniti pri brisanju](https://developer.wordpress.org/plugins/plugin-basics/uninstall-methods/)

- [PHP — memory_limit](https://www.php.net/manual/en/ini.core.php)

- [WooCommerce — rizici vraćanja backup-a kod prodavnice i pretplata](https://woocommerce.com/document/subscriptions/restore-backup-subscriptions/)