Een kritieke fout op je WordPress-website oplossen

Open de homepage, een gewone onderliggende pagina en het inlogscherm. Noteer welke pagina’s dezelfde melding geven. Werkt alleen een specifiek formulier niet, dan is de scope anders dan wanneer ook het beheer onbereikbaar is. Probeer een privévenster om een oude browserweergave uit te sluiten. Een tweede apparaat helpt vaststellen of het probleem overal optreedt. Noteer de exacte URL, het tijdstip en de handeling vlak vóór de fout. Maak een screenshot zonder klantgegevens. Deze informatie maakt een latere vergelijking veel betrouwbaarder dan de omschrijving ‘de site doet het niet’.

WordPress kan bij bepaalde fatale fouten een e-mail naar de beheerder sturen met informatie over de betrokken code en een link voor herstelmodus. Controleer ook spam en het werkelijk ingestelde beheerdersadres. Behandel de herstellink als toegangsinformatie: deel hem niet openbaar. Volg de uitleg in de mail en kijk welke uitbreiding wordt genoemd. Het ontbreken van de mail bewijst niet dat er geen PHP-fout is; ook de mailroute kan falen. Verwar het adres waarmee je zelf inlogt niet met het algemene beheerdersadres van de site.

Maak vóór wijzigingen een backup van bestanden én database, of laat de hostingpartij die vastleggen. Controleer datum, inhoud en herstelmogelijkheid. Een melding dat backups aanstaan is onvoldoende om te weten of de juiste versie beschikbaar is. Download belangrijke recente inzendingen of bestellingen via een veilige route als dat nog kan. Zet een oude database niet zomaar terug over nieuwe klantgegevens. Bij een webshop wil je eerst weten welke transacties na het backupmoment zijn binnengekomen en hoe die behouden blijven.

Bekijk bij de hostingpartij het PHP-foutenlog rond het genoteerde tijdstip. Een fatale fout bevat vaak een bestandsnaam en regelnummer. Laat zo nodig tijdelijk WordPress-debuglogging instellen, met foutweergave voor bezoekers uit. Wijzig wp-config.php alleen als je weet waar bestaande instellingen staan; dubbele definities geven extra verwarring. Bewaar logs buiten openbare toegang en verwijder gevoelige details voordat je ze deelt. Het genoemde bestand is een aanwijzing, geen automatisch bewijs dat de hele plugin slecht is. Een afhankelijkheid of gewijzigde PHP-versie kan eveneens de oorzaak zijn.

Is vlak ervoor één plugin bijgewerkt? Test die eerst op een kopie van de site. Deactiveer de verdachte uitbreiding en controleer dezelfde URL opnieuw. Als het dashboard onbereikbaar is, kan een developer of host de betreffende pluginmap tijdelijk hernoemen. Dat verwijdert de pluginbestanden niet, maar de functie valt wel weg. Houd daarom bij welke wijziging je uitvoert. Schakel niet blind alle uitbreidingen uit op een actieve webshop. Zodra de fout verdwijnt, onderzoek je welke combinatie van versies en instellingen het probleem veroorzaakt.

Een zichtbare homepage is pas de eerste controle. Test ook inloggen, zoeken en de belangrijkste klantactie. Bekijk of nieuwe foutmeldingen verschijnen en controleer een niet-ingelogde weergave op mobiel. Leg vast welke versie is hersteld of aangepast. Zet tijdelijke debuginstellingen terug en beperk de bewaartijd van logs. Blijft de oorzaak onbekend, houd dan het onderzoek klein: één reproduceerbaar probleem en één volgende hypothese. Stuur bij overdracht het tijdstip, de betrokken URL, recente wijzigingen en opgeschoonde foutregel mee. Deel toegang via een afzonderlijk veilig kanaal.

De officiële uitleg over WordPress-debugging beschrijft de debuginstellingen. Voor pluginherstel en veelvoorkomende storingen is er de WordPress-probleemhulp.