Wit scherm of kritieke fout in WordPress: eerst de foutmelding lezen

“Kritieke fout” of wit scherm: dezelfde storing

Een wit scherm is meestal een fatale PHP-fout: een bestand van de site vroeg iets onmogelijks, en de uitvoering stopte voordat er iets werd getoond. Sinds WordPress 5.2 vangt WordPress deze fouten op: in plaats van een lege pagina toont het “Er heeft zich een kritieke fout voorgedaan op deze site.” en stuurt het een e-mail naar het beheerdersadres van de site.

De pagina blijft in enkele gevallen helemaal wit: een oudere versie van WordPress, een fout die optreedt voordat dit mechanisme is geladen, de constante WP_DISABLE_FATAL_ERROR_HANDLER op true, of een cacheplugin die een lege pagina serveert die tijdens de storing is opgeslagen. De methode hieronder werkt in al deze gevallen.

Drie stappen kunnen wachten tot u de fout hebt gelezen: WordPress opnieuw installeren, plugins verwijderen, een oude back-up terugzetten. Elk daarvan kan instellingen of recente gegevens wissen, terwijl de foutmelding meestal precies zegt welk onderdeel u uitschakelt, zonder iets te verliezen.

De snelle weg: de herstelmodus

Wanneer WordPress de fout opvangt, stuurt het naar het beheerdersadres van de site een e-mail met als onderwerp “[Naam van de site] je site ervaart een technisch probleem”. Die noemt de plugin of het thema in kwestie en bevat een link die het dashboard opent in herstelmodus.

• In deze modus wordt het foutieve onderdeel alleen voor u gepauzeerd: uw bezoekers zien nog steeds de fout.
• Deactiveer via Plugins of Weergave > Thema's het onderdeel dat de e-mail noemt, en klik daarna in de balk bovenaan op “Herstelmodus verlaten”.
• De link blijft 24 uur geldig, en WordPress stuurt hoogstens één zo’n e-mail per dag. Komt de e-mail niet aan, kijk dan in de spammap en ga daarna door met de volgende methode.

De fout lezen: het debuglogboek

Maak verbinding met de site via SFTP of via de bestandsbeheerder van uw hostingprovider, open wp-config.php in de root en vervang de regel define( 'WP_DEBUG', false ); door deze vier regels:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Ze komen boven de regel /* That's all, stop editing! Happy publishing. */ (in het Engels, ook bij een WordPress in het Nederlands). Laad de pagina met de fout opnieuw en open daarna wp-content/debug.log. Met WP_DEBUG_DISPLAY op false blijven de meldingen in het bestand, buiten de pagina die uw bezoekers zien.

Blijft debug.log leeg of verschijnt het niet, dan heeft PHP de fout zelf vastgelegd: zoek een bestand error_log in de root van de site of in wp-admin, of het onderdeel met foutlogboeken in het paneel van uw hostingprovider.

Wat de melding zegt, en de stap die erbij hoort

Een fatale fout past op één regel: het type fout, de beschrijving, daarna in gevolgd door het volledige pad van het bestand en het regelnummer. Het pad is het nuttigste gegeven: wp-content/plugins/naam/ wijst naar een plugin, wp-content/themes/naam/ naar een thema.

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

Het onderdeel uitschakelen zonder dashboard

Via SFTP of de bestandsbeheerder

Hernoem de map van de plugin die in de melding wordt genoemd, bijvoorbeeld wp-content/plugins/naam-plugin naar naam-plugin.off. WordPress vindt de plugin niet meer en laadt hem niet meer; de instellingen blijven in de database bewaard, en WordPress deactiveert de plugin de volgende keer dat het scherm Plugins wordt geopend, met als foutmelding “Plugin bestand bestaat niet.”

Voor een thema maakt het hernoemen van de map in wp-content/themes het dashboard weer bereikbaar, maar bezoekers zien een lege pagina zolang er geen thema actief is. Open meteen Weergave > Thema's: WordPress meldt “Het actieve thema is kapot. Terugdraaien naar het standaard thema.” en schakelt over op een geïnstalleerd standaardthema.

Met WP-CLI

wp plugin list --status=active
wp plugin deactivate naam-plugin
wp theme list
wp theme activate twentytwentyfive

De eerste opdracht legt vast welke plugins actief zijn, handig vóór elke deactivering in bulk. Stopt WP-CLI zelf op de fout, voeg dan --skip-plugins --skip-themes aan de opdracht toe: WP-CLI start dan zonder plugins of thema te laden. De plugins in de map wp-content/mu-plugins worden toch geladen; komt de fout van een van die plugins, hernoem dan het bestand ervan.

Noemt de melding geen enkel onderdeel, dan deactiveert wp plugin deactivate --all alle plugins. Komt de site terug, activeer ze dan een voor een opnieuw en laad de site telkens opnieuw: de laatste die u activeerde voordat de fout terugkwam, is de boosdoener.

Zodra de site weer werkt

1. Zet define( 'WP_DEBUG', false ); terug en verwijder WP_DEBUG_LOG uit wp-config.php.
2. Verwijder wp-content/debug.log: in een map die via het web bereikbaar is, kan iedereen het lezen, en het bevat paden van de server.
3. Werk het betrokken onderdeel bij of vervang het, na het lezen van de changelog.
4. Leeg de cache van de cacheplugin en die van de hostingprovider, als die er een heeft.
5. Voor de volgende keer: test updates op een kopie van de site voordat u ze online toepast.