Najčešće WordPress greške i kako ih rešiti (beli ekran, 500…)

Beli ekran, „Internal Server Error“, „Error establishing database connection“, 404 na stranicama koje juče bile žive – sve ove greške imaju nešto zajedničko: izgledaju katastrofalno, a iza svake stoji jedan konkretan uzrok koji se može naći i popraviti. U ovom vodiču prolazimo najčešće WordPress greške sa uzrokom i rešenjem korak po korak, počevši od onih koje izgledaju najgore – a najlakše se rešavaju.

Pravila dijagnostike (pre bilo kakve popravke)

Pre nego što krenete po sekcijama ispod, tri pravila koja spasavaju vreme i nerve:

• Backup pre popravke – čak i kada je sajt već pokvaren, napravite kopiju trenutnog stanja (da ne pokvarite i ono što je ostalo, i da imate „pre“ verziju za analizu).
• Jedna izmena po meri – nikad ne menjajte tri stvari odjednom; ako greška nestane, morate znati koja od tri promene je bila uzrok.
• Privatni režim pregledača – keš pregledača često pokazuje staru verziju stranice; pre nego što zaključite da je nešto pokvareno, osvežite stranicu van keša (Cmd+Shift+R ili Privatni prozor).

Beli ekran (White Screen of Death)

Sajt učitava praznu belu stranicu – nema greške, nema sadržaja. Uzrok je uvek u PHP kodu koji se srušio pre nego što je išta poslato: najčešće plugin, zatim tema, a ređe iscrpljena memorija servera. Rešavanje po redosledu verovatnoće:

1. Uspostavite FTP vezu (FileZilla) i pređite u wp-content/plugins.
2. Preimenujte folder jednog plugin-a (npr. akismet → akismet-off) – time ga deaktivirate jer ga WordPress ne nalazi.
3. Osvežite sajt. Ako je proradio, uzrok je taj plugin – vratite mu ime, ažurirajte ga ili nađite alternativu. Ako nije, vratite ime i pređite na sledeći.
4. Ako nijedan plugin nije kriv, isto preimenujte temu u wp-content/themes – WordPress će privremeno preći na podrazumevanu temu.

Za brže traženje, uključite debug režim u wp-config.php (dodajte define('WP_DEBUG', true);) – greška će se umesto belog ekrana ispisati tekstualno, sa nazivom fajla i linijom. Ako se beli ekran pojavio neposredno posle ažuriranja (WordPress, tema, plugin), uzrok je skoro sigurno u tom ažuriranju – vratite prethodnu verziju preko FTP-a (stari fajl teme/plugin-a sa wordpress.org repozitorijuma) i sačekajte zakrpu pre ponovnog pokušaja.

HTTP greška 500 (Internal Server Error)

Greška 500 govori da je server pao na nekom koraku, ali ne precizira gde – zato se i rešava kao beli ekran (plugin po plugin, tema), uz dva dodatna krivca specifična za 500:

• .htaccess fajl – pokvaren ili sa greškom u sintaksi često pravi 500. Preimenujte ga (npr. .htaccess-off) i osvežite sajt; ako proradi, WordPress će regenerisati ispravan unos podešavanjem permalinkova (Podešavanja → Permalinki → Sačuvaj).
• PHP podešavanja – plugin koji traži više memorije nego hosting dozvoljava. Povećajte memory_limit u php.ini ili .user.ini (npr. na 256M), ako hosting dopušta.

Ako je cela administracija pala (ne radi ni wp-admin), logovi hostinga („Error Log“ u panelu) pokazuju poslednju liniju pre pada – to je obično direktan pokazatelj fajla koji pravi problem.

Error establishing database connection

„WordPress nije mogao da se poveže sa bazom“ – uzrok je u wp-config.php: netačan naziv baze, korisnik ili lozinka (obično posle migracije ili menjanja lozinke baze u panelu), ili baza na hostingu jednostavno ne radi. Provera:

1. Otvorite phpMyAdmin – ako se ni on ne otvara, baza je zaista pala; kontaktirajte podršku hostinga (ili sačekajte – privremene greške baze se dešavaju).
2. Ako phpMyAdmin radi, otvorite wp-config.php i uporedite četiri vrednosti (DB_NAME, DB_USER, DB_PASSWORD, DB_HOST) sa onim što hosting daje u panelu.
3. Uskladite i prefiks tabela ako je promenjen (posle migracije – $table_prefix).

Specifične greške koje se javljaju tek posle selidbe na novi hosting pokrivene su u tekstu kako migrirati WordPress na novi hosting.

Simptom: administrator ne može da se prijavi, ali sajt radi normalno za ostale. Skoro uvek je uzrok u bezbednosnom plugin-u koji je blokirao vašu IP adresu posle nekoliko neuspešnih pokušaja logina (zaboravljena lozinka, pa probanje). Proverite email obaveštenja (Wordfence i slični šalju „Vaša adresa je blokirana“) i odblokirajte se preko linka u poruci; alternativno, preimenujte bezbednosni plugin preko FTP-a da ga deaktivirate i vratite pristup, pa mu vratite ime i odblokirajte se pravilno.

404 greške na stranicama koje postoje

Naslovna radi, a članci vraćaju 404? Uzrok je skoro uvek permalink struktura – WordPress generiše .htaccess pravila koja se kvare posle migracije, menjanja hostinga ili ručnih izmena. Popravka traje 10 sekundi: Podešavanja → Permalinki, bez ikakve izmene kliknite Sačuvaj – WordPress regeneriše pravila. Ako ne pomogne, proverite da li .htaccess postoji u korenu i da li Apache čita njegove direktive (na nginx hostinzima umesto toga proverite „try_files“ konfiguraciju).

403 Forbidden

„Pristup zabranjen“ na celom sajtu ili delu administracije: uzroci su (1) permisije fajlova – folderi treba da budu 755, fajlovi 644 (FileZilla → desni klik → File Permissions); (2) .htaccess pravilo koje ste ili vi ili hosting dodali; (3) bezbednosni plugin koji je blokirao vašu IP adresu posle nekoliko loših pokušaja logina (proverite poštansko sanduče, stiže obaveštenje sa dugmetom za odblokiranje). Retko, ali se dešava: hosting firewall – tada je kontakt podrške najkraći put.

Vredi znati i da se ove greške najčešće javljaju u parovima: 403 na celom sajtu posle instalacije bezbednosnog plugin-a, 404 posle menjanja hostinga, „database connection“ posle ručne izmene wp-config.php-a. Zato uvek imajte na umu šta ste poslednje radili – u praksi je to pola odgovora, a druga polovina je neki od koraka iznad.

Sajt radi, ali sporo

Spor sajt nema ni poruku ni upozorenje – to je „greška bez greške“: nema vidljivog simptoma, ali posetilac odlazi. Najčešći uzorci, po učestalosti: (1) slike bez optimizacije – fotografije sa telefona u punoj veličini, neretko po nekoliko MB; (2) nema keš plugin-a – svaka poseta sklapa stranicu iz baze; (3) teška tema sa ugrađenim builder-om koji vuče desetine fajlova; (4) previše plugin-ova koji se učitavaju na svakoj stranici. Merenje je prvi korak (PageSpeed Insights), a redosled popravke: keš → slike → uklanjanje nekorišćenog. Ako ni posle toga nije brže, hosting je sledeći osumnjičeni – razlika između VPS-a i shared hostinga objašnjava zašto deljeno okruženje ima plafon brzine. Kada osnovne mere budu na mestu, sledeći sloj su lazy loading slika i CDN, ali to već spada u napredniju optimizaciju – redosled je bitan: nema smisla podešavati pre nego što su slike kompresovane i keš uključen.

Gde tražiti uzrok (kada poruka ne govori ništa)

Kad su simptomi nejasni, tri mesta uvek vode ka odgovoru:

• Debug log – WP_DEBUG_LOG u wp-config.php upisuje greške u wp-content/debug.log; poslednje linije obično imenuju plugin ili temu koji puca.
• Error log hostinga – u kontrol panelu („Error Logs“); pokazuje PHP greške na nivou servera, korisno za 500 i 403.
• Test izolacije – Privatni režim (isključuje ekstenzije pregledača), pa plugin po plugin. Dijagnostika je uvek ista: suziti, suziti, suziti – dok uzrok ne ostane sam.

Kad popravka ne uspe: proces, ne panika

Ponekad koraci iznad ne daju rezultat – najčešće zato što je uzrok u bazi (pokvaren red u tabeli) ili u kombinaciji nekoliko stvari. U tom slučaju, po redosledu:

1. Vratite poslednji backup pre nego što je problem nastao (postupak u tekstu kako napraviti backup WordPress sajta). Ako se posle povratka sve proradi, uzrok je bio u poslednjim izmenama – i onda ih vraćate pojedinačno.
2. Testirajte lokalno – kopiju sajta instalirate na lokalni WordPress i tamo reprodukujete grešku bez pritiska (niko ne gleda, niko ne paniči).
3. Kontakt hostinga – ako sve ukazuje na server (baza ne radi, logovi su puni grešaka koje ne zavise od vašeg koda), podrška je jedina adresa koja može nešto da uradi na njihovoj strani. Ako hosting reaguje satima i ovo se ponavlja, to je znak da je vreme za selidbu – kako instalirati WordPress na VPS ili shared hosting pokriva prvi korak novog početka.

Česta pitanja

Da li je beli ekran uvek uzrokovan plugin-om?

U najvećem broju slučajeva da – procenat je oko 80% po iskustvima podrški hostinga. Ali ne isključujte temu i PHP memoriju; zato je redosled (plugin → tema → memorija) zapravo redosled verovatnoće, ne pravilo.

Kako da sprečim da se ove greške ponove?

Tri stvari pokrivaju većinu: redovno ažuriranje (rupe u starim verzijama su najčešći uzrok 500 posle napada), backup pre svake izmene (oporavak traje min umesto sati) i keš + optimizacija slika (sporost se ne javlja iznenada, nego se gomila). Ako vam je sve ovo previše mehaničke brige, SaaS platforme nose održavanje u paketu – poređenje pristupa je u tekstu platforme za izradu sajta bez muke.

Šta kada se greška pojavi samo na telefonu?

Tada je uzrok najčešće u temi ili kešu, ne u serveru: telefonski keš plugin-a često čuva zastarelu verziju. Očistite keš („Purge All“) i proverite ponovo. Ako se greška i dalje pojavljuje samo na mobilnim uređajima, uključite mobilni keš nezavisno od desktop verzije u keš plugin-u.

Zaključak

WordPress greške imaju obrazac: simptom je uvek glasniji od uzroka. Beli ekran i 500 skoro uvek vode na plugin ili temu, „database connection“ na wp-config.php, 404 na permalink pravila, a sporost na slike i keš. Sa tri pravila dijagnostike – backup, jedna izmena po meri, Privatni režim – nijedna od ovih greška ne traži više od pola sata vašeg vremena. A sledeći put kada se pojavi, nećete ni pokušati na Google pre nego što otvorite FTP.