Een kapper in Leeuwarden zag het op maandagochtend: de website was wit. Geen foutmelding, geen logo, geen tekst. Gewoon een leeg scherm, op de telefoon en op de computer. Het beheer laadde wel, maar de site zelf niet. Ze had niets veranderd, zei ze. Dat bleek later niet helemaal te kloppen, maar dat is bijna altijd zo.

Een wit scherm in WordPress, in vaktaal het “white screen of death”, is vervelender dan een melding, juist omdat er niets staat. Sinds een aantal jaren vangt WordPress de meeste fatale fouten op met een zichtbare melding; die situatie bespreken we in dit artikel over de critical error. Een écht wit scherm betekent dat zelfs die vangnet niet werkte, of dat het probleem ergens anders zit. Dit artikel is een zoekroute, in de volgorde die in de praktijk het snelst tot de oorzaak leidt.

Eerst: waar is het wit?

Voordat u iets doet, stelt u drie vragen. Het antwoord bepaalt waar u moet zoeken.

  • Is de hele site wit, of alleen bepaalde pagina’s? Alleen de homepage of alleen productpagina’s wijst op een sjabloon in het thema of een plugin die op die pagina actief is.
  • Is het beheer ook wit? Werkt /wp-admin wel, dan is de kern in orde en zit het vrijwel zeker in het thema. Is het beheer ook wit, dan is het eerder een plugin, het geheugen of de server.
  • Is het bij iedereen wit, of alleen bij u? Vraag iemand anders, of open de site in een privévenster. Soms is het uw eigen browsercache.

De zoekroute bij een WordPress wit scherm

Stap 1: leeg de cache

Klinkt te simpel, lost het toch regelmatig op. Een cacheplugin of servercache kan een lege pagina hebben opgeslagen op het moment dat er even iets mis was, en die vervolgens aan iedereen tonen. Leeg de cache via de plugin als u in het beheer komt, of via het hostingpaneel. Gebruikt u een dienst als Cloudflare, leeg dan ook daar de cache.

Stap 2: maak de fout zichtbaar

Een wit scherm betekent meestal dat de server een fout heeft, maar hem niet toont omdat foutweergave uitstaat. Dat is goed voor de beveiliging en slecht voor het zoeken. Er zijn twee manieren om de fout alsnog te lezen: het foutenlog van de hosting openen, of tijdelijk de debug-modus inschakelen in wp-config.php. In beide gevallen zoekt u naar de laatste regel met “Fatal error” en het bestandspad erachter. Dat pad wijst naar de plugin of het thema.

Belangrijk: zet de debug-modus na afloop weer uit. Een site die foutmeldingen aan bezoekers toont, geeft ook informatie aan mensen met minder goede bedoelingen.

Stap 3: controleer het geheugen

Een van de klassieke oorzaken van een wit scherm zonder melding is dat PHP geen geheugen meer heeft, zo vroeg in het proces dat WordPress zijn eigen foutafhandeling nog niet heeft kunnen laden. Staat in het log iets als “Allowed memory size of 41943040 bytes exhausted”, dan is dit het. De oplossing is de limiet verhogen; hoe dat werkt en waarom het soms niet helpt, leest u in dit artikel over de geheugenlimiet.

Stap 4: schakel het thema uit

Werkt het beheer wel en de site niet, dan is het thema de eerste verdachte. Ga in het beheer naar Weergave, Thema’s en activeer tijdelijk een standaardthema van WordPress. Komt de site terug, dan zit de fout in uw thema. Vaak is dat een functions.php waar recent iets in geplakt is, een thema-update die niet samengaat met de PHP-versie, of een child-thema waarvan het bovenliggende thema is verwijderd.

Komt u niet in het beheer, hernoem dan via FTP de themamap in wp-content/themes. WordPress valt dan terug op een standaardthema, mits dat nog geïnstalleerd is.

Stap 5: schakel de plugins uit

Is het thema onschuldig, dan zijn de plugins aan de beurt. Via FTP hernoemt u de map wp-content/plugins naar bijvoorbeeld plugins-uit. Laadt de site nu, dan zit het in een plugin. Zet de naam terug en hernoem daarna de mappen van de afzonderlijke plugins één voor één, te beginnen met de plugin die het meest recent is bijgewerkt of geïnstalleerd. Bij de kapper uit de inleiding bleek dat een plugin voor online reserveringen te zijn die de avond ervoor automatisch was bijgewerkt. “Niets veranderd” gold voor haar, niet voor de site.

Stap 6: kijk naar .htaccess en de bestandsrechten

Op Apache-servers stuurt het bestand .htaccess de verzoeken naar de juiste plek. Een beschadigd of verkeerd aangepast .htaccess-bestand kan een wit scherm geven, vooral als het door een beveiligings- of cacheplugin is herschreven. Hernoem het tijdelijk en laat WordPress een nieuwe aanmaken via Instellingen, Permalinks. Controleer ook of bestanden nog de gebruikelijke rechten hebben: 644 voor bestanden, 755 voor mappen. Een verkeerd gezette 000 of 777 geeft soms een leeg scherm.

Stap 7: sluit de server uit

Een wit scherm kan ook buiten uw site liggen: een hostingpartij die een PHP-versie heeft uitgezet, een volle schijf, een server die overbelast is. Kijk in het hostingpaneel naar meldingen, controleer de schijfruimte en probeer of een simpel testbestand met alleen de tekst “test” wel laadt. Zo niet, dan ligt het bij de hosting en helpt geen enkele aanpassing aan WordPress.

Stap 8: zet een back-up terug

Is de oorzaak na deze stappen nog niet gevonden en is de site langer dan een uur wit, overweeg dan om een recente back-up terug te zetten en daarna rustig uit te zoeken wat er misging. Dat is geen gezichtsverlies; het is de snelste weg terug online. Voor een webshop geldt: zet alleen de bestanden terug, niet de database, anders verdwijnen recente bestellingen.

Wanneer u het uit handen geeft

Stap 1 tot en met 5 kunt u zelf doen, ook zonder technische achtergrond, mits u een back-up heeft en toegang tot FTP of het hostingpaneel. Bij stap 6 en 7 wordt het lastiger, en wie zich daar niet prettig bij voelt, doet er verstandig aan om te stoppen voordat er meer stuk gaat. Een wit scherm behoort tot de meest voorkomende storingen die een WordPress-specialist oplost; bij WebMaintor is de meerderheid binnen een uur verholpen, en de oorzaak krijgt u er in gewoon Nederlands bij. Wat u het bureau in elk geval meegeeft: sinds wanneer het wit is, wat er die dag is bijgewerkt, en de regel uit het foutenlog als u die heeft gevonden. Dat scheelt zoektijd en dus kosten.