Sait töötas hetk tagasi, sa lõpetasid artiklit või seadistasid WooCommerce'i ja järsku ei midagi. Valge ekraan administraatori paneeli asemel. Või avaleht kadus, kuigi juhtpaneel ikka avaneb. Tundub tuttav? Tere tulemast klubisse, oled kohanud valget surmaekraani, tuntud ka kui WSOD, mida nimetatakse ka „valgeks surmaekraaniks" WordPressis.

Paanika on siin esimene vaenlane. WSOD ei tähenda peaaegu kunagi, et sait on lõplikult surnud. Enamasti on põhjus igapäevane: plugin konflikt pärast uuendust, halvasti sisestatud kood failis functions.php või lihtsalt PHP protsessi mälupuudus. Selles juhendis on neli tõestatud viisi saidi ellu äratamiseks ja viies, mis on WordPressi tuuma sisse ehitatud ja mille isegi kogenud kasutajad unustavad.

💡 Kiire ülevaade:

• Keela probleemne plugin FTP kaudu (nimeta kaust ümber) või hulgi, nimetades ümber plugins kataloogi
• Keela konfliktne teema sama meetodiga: themes kaust → nimeta aktiivse teema kataloog ümber
• Tõsta PHP mälulimiiti reaga WP_MEMORY_LIMIT failis wp-config.php väärtuseni 128M või 256M
• Luba WP_DEBUG ja WP_DEBUG_LOG diagnostikaks, selgita vea täpne põhjus failist debug.log
• Kasuta taastamisrežiimi (WordPress 5.2+), sisseehitatud mehhanismi, mis saadab lingi administraatori paneelile ligipääsuks isegi fataalse vea korral
• Taasta sait varukoopiast, kui teised meetodid ei toiminud

1. Probleemse plugina keelamine

Pluginad on WSOD kõige sagedasem põhjus. Sa just uuendasid oma lemmik vahemällu pluginat, ekraan läks mustaks. Sa paigaldasid uue slaidiseansi, sait lakkas avanemast. Mehaanika on lihtne: plugina PHP kood põhjustab fataalse vea ja WordPress lõpetab kogu lehe laadimise.

Probleem on selles, et sa ei saa administraatori paneeli sisse logida ja vajutada „Deaktiveeri", administraatori paneel muutub samamoodi valgeks ekraaniks. Lahendus: keela plugin otse failisüsteemi kaudu.

Kuidas ühte pluginat FTP kaudu keelata:

• Ühendu serveriga FTP (FileZilla, WinSCP) või hostingu failihalduri kaudu (cPanel → File Manager).
• Liigu WordPressi juurkataloogi.
• Ava wp-content/plugins.
• Leia probleemse plugina kaust, nimi ühtib pealkirjaga (näiteks akismet, woocommerce või elementor).
• Nimeta kaust ümber: lisa alakriips või sufiks, _akismet või akismet_disabled. WordPress tajub ümbernimetamist plugina puudumisena ja deaktiveerib selle.

Kohe pärast ümbernimetamist ava sait oma brauseris. See töötab, süüdlane on leitud. Nüüd saad taastada kausta algse nime ja pärast administraatori paneeli sisselogimist kas uuendada plugina ühilduvale versioonile või eemaldada selle ja leida alternatiivi.

Kõigi pluginatega korraga deaktiveerimine. Kui pole selge, milline konkreetne plugin tõrke põhjustas, keela kõik korraga. Nimeta wp-content/plugins kaust ise ümber plugins_old ja loo selle kõrvale uus tühi plugins kataloog. Kõik pluginad on deaktiveeritud. Seejärel too need ükshaaval tagasi: liiguta plugina kaust plugins_old kaustast tagasi plugins kausta, logi administraatori paneeli sisse, aktiveeri see ja kontrolli saiti. Korda, kuni leiad süüdlase.

Alternatiiv neile, kellel on WP-CLI. Üks käsk terminalis asendab FTP tantsu trummiga:

1
wp plugin deactivate --all

Ja seejärel aktiveeri ükshaaval: wp plugin activate <slug>. Kiire, puhas, ilma failihaldurita.

2. Konfliktse teema keelamine

Sageduselt teine süüdlane on teema. Stsenaariumid on samad: uuendasid teema uuele suurele versioonile, paigaldasid teema halvasti kirjutatud functions.php failiga või plugin sattus pärast WordPressi uuendust konflikti praeguse teemaga.

Paranduse mehhanism on peaaegu identne plugina omaga:

• Logi FTP kaudu sisse wp-content/themes kausta.
• Leia aktiivse teema kaust (see, mis on saidil hetkel paigaldatud).
• Nimeta see ümber, näiteks lisa nime lõppu _disabled.

WordPress, leidmata aktiivset teemat, lülitub automaatselt vaikimisi Twenty Twenty-Five teemale (või Twenty Twenty-Four, sõltuvalt WP versioonist). Sait laadib vaikimisi kujundusega, kuid kogu sinu sisu jääb paigale. Oluline: ära kustuta vaiketeemat, muidu pole millelegi üle lülituda ja saad uue ringi WSOD-d.

Halvasti kodeeritud teemad ja WordPressi uuendused. Pärast suurt WordPressi väljalaset võivad vanad teemad, mis kasutavad aegunud funktsioone või konkse, katki minna. Kvaliteetsed teemad kontrollitud arendajatelt uuendatakse mõne päeva jooksul pärast tuuma väljalaset. Kui sinu teemat pole kuus kuud või kauem uuendatud, on see punane lipp: vaheta aktiivselt hooldatava vastu.

functions.php ja teiste teemafailide muutmine. Kirjaviga failis functions.php, üleliigne sulg, vale konksu väljakutse ja sait läheb maas. Kui muutsid teemafaile vahetult enne WSOD ilmumist, asenda muudetud fail varukoopia või teema distributsiooni originaalversiooniga. Ilma varukoopiata laadi teema allikast uuesti alla ja laadi puhas fail üles.

3. PHP mälulimiidi ületamine

Sait kasvas, pluginad paljunesid, külastatavus tõusis ja järsku WSOD. Klassikaline sümptom, et PHP protsessil sai RAM otsa. Eriti asjakohane odavatel hostinguplaanidel, kus üks server teenindab sadu saite ja limiit kliendi kohta on viidud miinimumini.

WordPress soovitab ametlikult minimaalselt 64 MB mälu, kuid see soovitus pärineb PHP 5.6 ajastust ja viiest pluginast saidi kohta. Aastal 2026 on realistlik miinimum töötavale saidile 128 MB ja Elementori, WooCommerce'i ja mitmekümne pluginaga lahenduste puhul 256 MB.

Kuidas mälulimiiti suurendada:

Ava fail wp-config.php (asub WordPressi installatsiooni juurkataloogis) ja lisa rida enne kommentaari /* That's all, stop editing! */:

1
define('WP_MEMORY_LIMIT', '256M');

Kui teenusepakkuja piirab PHP mälu rangelt serveri tasemel, siis see direktiiv ei toimi, sel juhul on ainult üks väljapääs: vaheta paketti või hostingu pakkujat. Hallatud WordPressi hosting (SiteGround, WP Engine, Kinsta) seadistab limiidid vaikimisi adekvaatselt ja mäluprobleemi seal praktiliselt ei kohta.

4. Diagnostika WP_DEBUG abil

Mõnikord pole süüdi ei pluginad, teema ega mälu, WSOD põhjus jääb tabamatuks. Siis pead panema WordPressi ütlema, mis täpselt valesti läks.

WordPress on aastakümneid kandnud endas sisseehitatud silurit WP_DEBUG. Vaikimisi on see keelatud (valge ekraan vigade asemel, mõte on mitte paljastada saidi sisemust külastajatele). Kuid administraatori jaoks on see režiim hindamatu.

Lisa faili wp-config.php:

1
define('WP_DEBUG', true);
2
define('WP_DEBUG_LOG', true);
3
define('WP_DEBUG_DISPLAY', false);

Mis juhtub:

• WP_DEBUG lubab silumisrežiimi;
• WP_DEBUG_LOG kirjutab vead faili wp-content/debug.log, mugav lugeda ilma külastajatele näitamata;
• WP_DEBUG_DISPLAY väärtusega false peidab vead ekraanilt (sa näed valget ekraani, kuid logid kirjutatakse).

Pärast lubamist ava sait, tekita probleem uuesti ja vaata faili wp-content/debug.log. Seal on rida faili, reanumbri ja vea tüübiga, näiteks Fatal error: Call to undefined function ... in /wp-content/plugins/some-plugin/file.php:42. See on probleemi täpne aadress.

Oluline: ära jäta WP_DEBUG toodangus pärast diagnostikat sisse lülitatuks, logid kasvavad kiiresti ja võivad kettaruumi täita.

5. Taastamisrežiim, WordPress 5.2+ sisseehitatud päästja

Alates versioonist 5.2 suudab WordPress ise fataalseid vigu tuvastada ja pakkuda varuteed. Taastamisrežiim on funktsioon, mida paljud administraatorid endiselt ei kasuta lihtsalt seetõttu, et nad ei tea sellest.

Kuidas see töötab. Kui PHP kood pluginas või teemas põhjustab fataalse vea, püüab WordPress selle kinni, peatab probleemse laienduse ja saadab administraatori e-posti aadressile kirja. Kiri sisaldab linki, mis avab juurdepääsu administraatori paneelile probleemsest koodist mööda minnes. Sa logid sisse, näed kokku jooksnud pluginat märkega „põhjustas vea", deaktiveerid selle ja sait on jälle elus. Pole FTP-d, pole kaustade ümbernimetamist.

Taastamisrežiimi piirangud:

• Link kehtib piiratud aja (umbes ööpäev) ja on seotud IP-aadressiga;
• Nõuab saidilt seadistatud kirjade saatmist (SMTP plugin või hostingu meil);
• Ei päästa serveritaseme vigadest (mälupuudus, katkine .htaccess).

Ja ometi, kui kiri saabus, hoiad sa kokku tosin minutit närve ja FTP liigutusi.

Vaata lühikest juhendit WSOD parandamise kohta, kõik kirjeldatud meetodid koos live demonstratsiooniga:

⁉️🤔 Korduma kippuvad küsimused

Miks ilmub valge ekraan ainult administraatori paneelis, aga sait avaneb normaalselt?

Viga on lokaliseeritud koodis, mis käivitatakse ainult juhtpaneelis: plugina metakast, teema seadete leht, kohandatud administraatori vidin. Keela hiljuti paigaldatud pluginad ükshaaval, süüdlane leitakse kiiresti. Kui see ei aita, luba WP_DEBUG_LOG ja kontrolli logi pärast administraatori paneeli sisselogimise katset.

Valge ekraan ainult ühel postitusel või sissekande lehel, milles asi?

Tõenäoliselt on probleem konkreetse sissekande sisus: olematu plugina lühikood, katkine HTML tekstis, konflikt kohandatud väljadega. Ava sissekanne administraatori paneelis Quick Edit kaudu ja muuda ajutiselt staatus „Mustandiks". Kas leht laadib? Siis kaeva sisu sees.

Kas WSOD-d saab tulevikus üldse vältida?

Täielikult kõrvaldada ei saa, kuid riski minimeerimine on realistlik. Kolm reeglit: (1) testi pluginate ja teemade uuendusi alati saidi staadiumikoopial enne toodangusse rakendamist; (2) hoia igapäevaseid varukoopiaid failidest ja andmebaasist; (3) ära paigalda pluginaid ja teemasid kahtlastest allikatest, eriti nullitud versioone.

Taastamisrežiim ei saatnud e-kirja, mida teha?

WordPressi saidilt tulev meil töötab ilma seadistatud SMTP pluginata ebastabiilselt. Seadista SMTP (Post SMTP, FluentSMTP või WP Mail SMTP) ennetava meetmena. Kui kiri juba ei saabunud, mine tagasi 1. jaotise FTP meetodi juurde, see töötab alati.

Kui kaua taastamisrežiimi link kehtib?

Link kehtib 24 tundi (täpsemalt, kuni nonce token aegub). Pärast seda pead vea uuesti tekitama, WordPress saadab kirja uuesti.

Mida teha, kui miski ei aidanud?

Kui neli ülaltoodud meetodit ja taastamisrežiim ei toonud saiti tagasi, on probleem sügavamal. Võib-olla on .htaccess fail kahjustatud (nimeta see ümber ja logi administraatori paneeli sisse, WordPress loob uue läbi „Seaded → Püsilinkide → Salvesta"). Või PHP versiooni mitteühilduvus: kaasaegne WordPress nõuab PHP 7.4+, kuid hostil võib endiselt olla PHP 5.6.

Teine diagnostikavahend on WordPress.org meeskonna Health Check & Troubleshooting plugin. See võib käivitada turvarežiimi sessiooni: keelab kõik pluginad ja lülitub vaiketeemale, kuid ainult sinu brauseri jaoks (külastajad näevad tavalist saiti). Sellega saad ohutult pluginaid ükshaaval lubada ja süüdlase püüda ilma toodangut puudutamata.

Pole aega uurimiseks, kuid sait peab kohe töötama? Taasta varukoopia. Kui varukoopiat pole, on see õppetund tulevikuks: igapäevased automaatsed varukoopiad maksavad paar dollarit kuus ja tasuvad end ära juba katastroofi esimesel päeval. Praktiliselt iga hosting pakub seda funktsiooni juhtpaneelis.

Ja mis kõige tähtsam, ära karda WSOD-d. See on ebameeldiv, kuid lahendatav. Nüüd on sul samm-sammuline tegevusalgoritm, mitte paanika ja tühi ekraan.