Sivusto toimi vielä hetki sitten, olit viimeistelemässä artikkelia tai määrittämässä WooCommercea, ja yhtäkkiä ei mitään. Valkoinen ruutu hallintapaneelin sijaan. Tai etusivu katosi, vaikka hallintapaneeli vielä aukeaakin. Kuulostaako tutulta? Tervetuloa kerhoon, olet kohdannut White Screen of Deathin eli WSOD:n eli "valkoisen kuolemanruudun" WordPress.

Panikointi on tässä kohtaa pahin vihollinen. WSOD ei lähes koskaan tarkoita, että sivusto on lopullisesti kuollut. Useimmiten syy on arkinen: lisäosan päivityksen aiheuttama ristiriita, huonosti lisätty koodi functions.php-tiedostossa tai yksinkertaisesti PHP-prosessin muistin loppuminen. Tässä oppaassa käydään läpi neljä toimivaksi todettua tapaa herättää sivusto henkiin ja viides, WordPressin ytimeen sisäänrakennettu keino, jonka kokeneetkin käyttäjät unohtavat.

💡 Pikaopas:

• Poista ongelmallinen lisäosa käytöstä FTP:n kautta (nimeä kansio uudelleen) tai massana nimeämällä plugins-hakemisto uudelleen
• Poista ristiriidan aiheuttava teema käytöstä samalla menetelmällä: themes-kansio → nimeä aktiivisen teeman hakemisto uudelleen
• Nosta PHP:n muistirajaa WP_MEMORY_LIMIT-rivillä wp-config.php-tiedostossa arvoon 128M tai 256M
• Ota WP_DEBUG ja WP_DEBUG_LOG käyttöön vianmääritystä varten, selvitä virheen tarkka syy debug.log-tiedostosta
• Käytä palautustilaa (WordPress 5.2+), sisäänrakennettua mekanismia, joka lähettää linkin hallintapaneeliin pääsemiseksi jopa kriittisen virheen aikana
• Palauta sivusto varmuuskopiosta, jos muut keinot eivät toimineet

1. Ongelmallisen lisäosan poistaminen käytöstä

Lisäosat ovat yleisin WSOD:n aiheuttaja. Päivitit juuri suosikkivälimuistilisäosasi, ja ruutu pimeni. Asensit uuden sliderin, ja sivusto lakkasi avautumasta. Mekaniikka on yksinkertainen: lisäosan PHP-koodi aiheuttaa kriittisen virheen, ja WordPress lopettaa koko sivun lataamisen.

Ongelmana on, ettet pääse kirjautumaan hallintapaneeliin ja klikkaamaan "Poista käytöstä", sillä hallintapaneelikin muuttuu valkoiseksi ruuduksi. Ratkaisu: poista lisäosa käytöstä suoraan tiedostojärjestelmän kautta.

Yhden lisäosan poistaminen käytöstä FTP:n kautta:

• Yhdistä palvelimelle FTP:llä (FileZilla, WinSCP) tai palveluntarjoajan tiedostonhallinnan kautta (cPanel → File Manager).
• Siirry WordPressin juurihakemistoon.
• Avaa wp-content/plugins.
• Etsi ongelmallisen lisäosan kansio, jonka nimi vastaa otsikkoa (esimerkiksi akismet, woocommerce tai elementor).
• Nimeä kansio uudelleen: lisää alaviiva tai pääte, esimerkiksi _akismet tai akismet_disabled. WordPress tulkitsee uudelleennimeämisen lisäosan puuttumiseksi ja poistaa sen käytöstä.

Avaa sivusto selaimessa heti uudelleennimeämisen jälkeen. Jos se toimii, syyllinen on löytynyt. Nyt voit palauttaa kansion alkuperäisen nimen ja kirjautumisen jälkeen joko päivittää lisäosan yhteensopivaan versioon tai poistaa sen ja etsiä vaihtoehdon.

Kaikkien lisäosien massapoisto käytöstä kerralla. Jos ei ole selvää, mikä tietty lisäosa aiheutti virheen, poista kaikki kerralla käytöstä. Nimeä wp-content/plugins-kansio itse uudelleen muotoon plugins_old ja luo sen viereen uusi tyhjä plugins-hakemisto. Kaikki lisäosat poistuvat käytöstä. Tuo ne sitten takaisin yksi kerrallaan: siirrä lisäosan kansio plugins_old-kansiosta takaisin plugins-kansioon, kirjaudu hallintapaneeliin, aktivoi se ja tarkista sivusto. Toista, kunnes löydät syyllisen.

Vaihtoehto WP-CLI:n käyttäjille. Yksi komento terminaalissa korvaa FTP-tanssin:

1
wp plugin deactivate --all

Ja aktivoi sitten yksi kerrallaan: wp plugin activate <slug>. Nopeaa, siistiä, ilman tiedostonhallintaa.

2. Ristiriidan aiheuttavan teeman poistaminen käytöstä

Toiseksi yleisin syyllinen on teema. Skenaariot ovat samat: päivitit teeman uuteen pääversioon, asensit teeman, jossa on huonosti kirjoitettu functions.php, tai lisäosa joutui ristiriitaan nykyisen teeman kanssa WordPress-päivityksen jälkeen.

Korjausmekanismi on lähes identtinen lisäosien kanssa:

• Kirjaudu FTP:llä kohteeseen wp-content/themes.
• Etsi aktiivisen teeman kansio (se, joka on tällä hetkellä asennettuna sivustolle).
• Nimeä se uudelleen, esimerkiksi lisäämällä _disabled nimen loppuun.

WordPress, joka ei löydä aktiivista teemaa, vaihtaa automaattisesti oletusteemaan Twenty Twenty-Five (tai Twenty Twenty-Four, WP-versiosta riippuen). Sivusto latautuu oletusulkoasulla, mutta kaikki sisältösi pysyy paikoillaan. Tärkeää: älä poista oletusteemaa, muuten ei ole mitään, mihin vaihtaa, ja saat uuden kierroksen WSOD:ta.

Huonosti koodatut teemat ja WordPress-päivitykset. Suuren WordPress-julkaisun jälkeen vanhat teemat, jotka käyttävät vanhentuneita funktioita tai koukkuja, voivat hajota. Laadukkaat teemat luotettavilta kehittäjiltä päivittyvät muutaman päivän sisällä ytimen julkaisusta. Jos teemaasi ei ole päivitetty kuuteen kuukauteen tai pidempään, se on hälytysmerkki: vaihda sellaiseen, jota ylläpidetään aktiivisesti.

functions.php-tiedoston ja muiden teematiedostojen muokkaaminen. Kirjoitusvirhe functions.php:ssä, ylimääräinen sulje, väärä koukkukutsu, ja sivusto kaatuu. Jos muokkasit teematiedostoja juuri ennen WSOD:n ilmestymistä, korvaa muutettu tiedosto alkuperäisellä versiolla varmuuskopiosta tai teeman jakelupaketista. Ilman varmuuskopiota lataa teema uudelleen lähteestä ja siirrä puhdas tiedosto palvelimelle.

3. PHP:n muistirajan ylittyminen

Sivusto kasvoi, lisäosat lisääntyivät, liikenne nousi, ja yhtäkkiä WSOD. Klassinen oire siitä, että PHP-prosessilta loppui RAM-muisti. Erityisen ajankohtaista halvalla hostingilla, jossa yksi palvelin palvelee satoja sivustoja ja asiakaskohtainen raja on leikattu minimiin.

WordPress suosittelee virallisesti vähintään 64 Mt muistia, mutta tämä suositus on peräisin PHP 5.6:n ja viiden lisäosan aikakaudelta. Vuonna 2026 realistinen minimi toimivalle sivustolle on 128 Mt, ja kokoonpanoille, joissa on Elementor, WooCommerce ja useita kymmeniä lisäosia, 256 Mt.

Muistirajan nostaminen:

Avaa wp-config.php-tiedosto (sijaitsee WordPressin asennuksen juuressa) ja lisää rivi ennen kommenttia /* That's all, stop editing! */:

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

Jos palveluntarjoaja rajoittaa PHP:n muistia tiukasti palvelintasolla, tämä direktiivi ei toimi, ja silloin on vain yksi keino: vaihda sopimusta tai hostingia. Hallituissa WordPress-hostingeissa (SiteGround, WP Engine, Kinsta) rajat on määritetty riittäviksi suoraan paketista, eikä muistiongelmaa käytännössä koskaan esiinny.

4. Vianmääritys WP_DEBUGin avulla

Joskus syy ei ole lisäosissa, teemassa eikä muistissa, vaan WSOD:n aiheuttaja pysyy piilossa. Silloin sinun on saatava WordPress kertomaan, mikä tarkalleen meni pieleen.

WordPressissä on ollut sisäänrakennettu debuggeri WP_DEBUG vuosikymmeniä. Oletuksena se on pois käytöstä (valkoinen ruutu virheiden sijaan, ajatuksena on olla paljastamatta sivuston sisäistä toimintaa vierailijoille). Mutta ylläpitäjälle tämä tila on korvaamaton.

Lisää tiedostoon wp-config.php:

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

Mitä tapahtuu:

• WP_DEBUG ottaa debug-tilan käyttöön;
• WP_DEBUG_LOG kirjoittaa virheet tiedostoon wp-content/debug.log, jota on kätevä lukea näyttämättä niitä vierailijoille;
• WP_DEBUG_DISPLAY arvolla false piilottaa virheet ruudulta (näet valkoisen ruudun, mutta lokit kirjoitetaan).

Käyttöönoton jälkeen avaa sivusto, toista ongelma ja katso tiedostoa wp-content/debug.log. Siellä on rivi, jossa on tiedosto, rivinumero ja virhetyyppi, esimerkiksi Fatal error: Call to undefined function ... in /wp-content/plugins/some-plugin/file.php:42. Tämä on ongelman tarkka osoite.

Tärkeää: älä jätä WP_DEBUG-tilaa päälle tuotantoon vianmäärityksen jälkeen, lokit kasvavat nopeasti ja voivat täyttää levytilan.

5. Palautustila, WordPress 5.2+:n sisäänrakennettu pelastaja

Versiosta 5.2 lähtien WordPress osaa havaita kriittiset virheet itse ja tarjota varareitin. Palautustila (Recovery Mode) on ominaisuus, jota monet ylläpitäjät eivät vieläkään käytä, koska he eivät yksinkertaisesti tiedä siitä.

Miten se toimii. Kun lisäosan tai teeman PHP-koodi aiheuttaa kriittisen virheen, WordPress sieppaa sen, pysäyttää ongelmallisen laajennuksen ja lähettää sähköpostia ylläpitäjän sähköpostiosoitteeseen. Sähköposti sisältää linkin, joka avaa pääsyn hallintapaneeliin ongelmallisen koodin ohi. Kirjaudut sisään, näet kaatuneen lisäosan, joka on merkitty "aiheutti virheen", poistat sen käytöstä, ja sivusto on taas elossa. Ei FTP:tä, ei kansioiden uudelleennimeämistä.

Palautustilan rajoitukset:

• Linkki on voimassa rajoitetun ajan (noin vuorokauden) ja on sidottu IP-osoitteeseen;
• Edellyttää sähköpostin lähetyksen määritystä sivustolta (SMTP-lisäosa tai hostingin sähköposti);
• Ei pelasta palvelintason virheiltä (muistin puute, rikkinäinen .htaccess).

Ja silti, jos sähköposti saapui, säästät tusinan verran hermoja ja FTP-liikkeitä.

Katso lyhyt opas WSOD:n korjaamisesta, kaikki kuvatut menetelmät live-esittelyllä:

⁉️🤔 Usein kysytyt kysymykset

Miksi valkoinen ruutu ilmestyy vain hallintapaneelissa, mutta sivusto avautuu normaalisti?

Virhe on paikallinen koodissa, joka suoritetaan vain hallintapaneelissa: lisäosan metabox, teeman asetussivu, mukautettu admin-widget. Poista äskettäin asennetut lisäosat käytöstä yksi kerrallaan, syyllinen löytyy nopeasti. Jos se ei auta, ota WP_DEBUG_LOG käyttöön ja tarkista loki yritettyäsi kirjautua hallintapaneeliin.

Valkoinen ruutu vain yhdellä artikkelilla tai kirjoitussivulla, mistä on kyse?

Todennäköisimmin ongelma on kyseisen kirjoituksen sisällössä: olemattoman lisäosan shortcode, rikkinäinen HTML tekstissä, ristiriita mukautettujen kenttien kanssa. Avaa kirjoitus Pikamuokkauksen kautta hallintapaneelissa ja vaihda tila väliaikaisesti "Luonnokseksi". Latautuuko sivu? Silloin syy on sisällössä.

Voiko WSOD:n välttää kokonaan tulevaisuudessa?

Täysin sitä ei voi poistaa, mutta riskin minimointi on realistista. Kolme sääntöä: (1) testaa lisäosien ja teemojen päivitykset aina sivuston staging-kopiolla ennen tuotantoon vientiä; (2) pidä päivittäiset varmuuskopiot tiedostoista ja tietokannasta; (3) älä asenna lisäosia ja teemoja epäilyttävistä lähteistä, etenkään nullattuja versioita.

Palautustila ei lähettänyt sähköpostia, mitä tehdä?

Sähköpostin lähetys WordPress-sivustolta ilman määritettyä SMTP-lisäosaa toimii epävakaasti. Määritä SMTP (Post SMTP, FluentSMTP tai WP Mail SMTP) ennaltaehkäisevästi. Jos sähköposti ei jo saapunut, palaa osion 1 FTP-menetelmään, se toimii aina.

Kuinka kauan palautustilan linkki on voimassa?

Linkki on voimassa 24 tuntia (tarkemmin sanottuna, kunnes nonce-token vanhenee). Sen jälkeen sinun on toistettava virhe uudelleen, WordPress lähettää sähköpostin uudestaan.

Mitä tehdä, jos mikään ei auttanut?

Jos edellä mainitut neljä menetelmää ja palautustila eivät palauttaneet sivustoa, ongelma on syvemmällä. Ehkä .htaccess-tiedosto on vaurioitunut (nimeä se uudelleen ja kirjaudu hallintapaneeliin, WordPress luo uuden kohdasta "Asetukset → Osoiterakenteet → Tallenna"). Tai PHP-version yhteensopimattomuus: moderni WordPress vaatii PHP 7.4+:n, mutta palvelimella saattaa yhä olla PHP 5.6.

Toinen vianmääritystyökalu on WordPress.org-tiimin Health Check & Troubleshooting -lisäosa. Se voi käynnistää vikasietotilaistunnon: poistaa kaikki lisäosat käytöstä ja vaihtaa oletusteemaan, mutta vain sinun selaimesi osalta (vierailijat näkevät normaalin sivuston). Sen avulla voit turvallisesti ottaa lisäosia käyttöön yksi kerrallaan ja napata syyllisen koskematta tuotantoon.

Ei aikaa tutkimukselle, mutta sivuston on oltava pystyssä heti? Palauta varmuuskopio. Jos varmuuskopiota ei ole, oppitunti tulevaisuuteen: päivittäiset automaattiset varmuuskopiot maksavat muutaman dollarin kuukaudessa ja maksavat itsensä takaisin katastrofin ensimmäisenä päivänä. Käytännössä jokainen hosting tarjoaa tämän ominaisuuden hallintapaneelissa.

Ja mikä tärkeintä, älä pelkää WSOD:ta. Se on epämiellyttävä, mutta ratkaistavissa. Nyt sinulla on vaiheittainen toiminta-algoritmi, ei paniikkia ja tyhjää ruutua.