Het is vrijdag 16:12. Een installatiebedrijf uit Zwolle, acht monteurs, een kantoor van twee mensen, wil nog snel een nieuwe vacature op de website zetten voordat het weekend begint. De office manager logt in, klikt op “Berichten” en ziet niets anders dan een witte pagina met één zin: “There has been a critical error on this website.” De voorkant van de site geeft dezelfde melding. Klanten die het telefoonnummer willen opzoeken, zien een foutmelding in plaats van een bedrijf.
Deze case beschrijft wat er daarna gebeurde. Niet omdat het verhaal spectaculair is, maar juist omdat het zo gewoon is. Een critical error oplossen is in de meeste gevallen geen kwestie van geluk of van zeldzame kennis. Het is een kwestie van een vaste volgorde aanhouden, geen paniekbeslissingen nemen en de juiste informatie op de juiste plek zoeken. De namen en details zijn aangepast, het verloop is realistisch.
De situatie: een site zonder eigenaar
De website was vier jaar eerder gebouwd door een freelancer die inmiddels iets anders deed. Er was geen onderhoudscontract. Updates werden af en toe gedaan door wie er toevallig achter de computer zat, meestal wanneer de rode bolletjes in het beheer te veel opvielen. Die vrijdag had de office manager om 15:50 op “Alles bijwerken” geklikt, omdat er veertien updates klaarstonden en “dat leek handig voor het weekend”.
Wat er precies gebeurde, wist niemand meer. Ergens tussen die veertien updates zat er één die de site omtrok. De office manager belde eerst de freelancer (voicemail), daarna de hostingpartij (wachtrij van twintig minuten, uiteindelijk het advies “een specialist inschakelen”) en kwam om 16:40 via een zoekopdracht bij ons terecht.
Belangrijk detail: er was die vrijdag een nieuwsbrief verstuurd naar ruim tweeduizend adressen, met een link naar de site. Elke minuut dat de foutmelding bleef staan, klikten er mensen op een dode link.
Stap 1: de melding lezen die niemand leest
Bij een critical error stuurt WordPress sinds versie 5.2 automatisch een e-mail naar het beheerdersadres. Die e-mail bevat een technische samenvatting van de fout én een herstellink waarmee u in een speciale herstelmodus kunt inloggen. In de praktijk wordt die e-mail bijna nooit gelezen: het beheerdersadres is vaak een oud adres, of de mail zit in de spam.
Hier was het beheerdersadres het privéadres van de freelancer. Weg informatie dus. Het alternatief is het foutenlog van de server, en daarvoor hadden we de hostinggegevens nodig. Die stonden gelukkig in een oude e-mail die de office manager nog kon terugvinden. Om 17:05 hadden we toegang tot het beheerpaneel van de hosting.
In het foutenlog stond binnen een minuut de oorzaak: een “fatal error” in een bestand van een plugin voor sliders, met de melding dat een functie niet bestond. De plugin was in de bulk-update meegenomen naar een nieuwe hoofdversie die een recentere PHP-versie vereiste dan de 7.4 die op de server draaide. Twee dingen tegelijk verouderd, en de update maakte dat zichtbaar. Wie zelf zo’n log wil lezen, vindt in ons artikel over het foutenlog van WordPress een uitleg zonder jargon.
Stap 2: de site weer in de lucht, nog niet gerepareerd
Het doel op vrijdagmiddag was niet om alles perfect te maken. Het doel was: de site bereikbaar voor het weekend. Dat is een verschil dat vaak vergeten wordt. Reparatie kan wachten, bereikbaarheid niet.
- Back-up van de huidige toestand. Ook een kapotte site krijgt eerst een back-up. Als een herstelpoging iets verergert, wilt u terug kunnen.
- De schuldige plugin uitschakelen via FTP. De map van de sliderplugin kreeg een andere naam (slider-plugin werd slider-plugin-uit). WordPress ziet de plugin dan niet meer en deactiveert hem vanzelf. Om 17:14 laadde de site weer.
- Controleren wat er nu ontbreekt. De homepage had bovenaan een lege ruimte waar de slider stond. Verder werkte alles: menu, contactformulier, vacaturepagina.
- De office manager gebeld. Vacature kon geplaatst worden. Nieuwsbrieflezers zagen weer een website.
Totale tijd van eerste contact tot werkende site: iets meer dan een half uur, waarvan het grootste deel opging aan het vinden van de hostinggegevens.
Stap 3: de echte reparatie op maandag
Op maandagochtend, met de site draaiend op een kopie in een testomgeving, werd het onderliggende probleem aangepakt. Dat bestond uit drie delen.
PHP-versie. De server draaide op een versie die al geruime tijd geen beveiligingsupdates meer kreeg. Op de testkopie werd PHP 8.2 ingeschakeld en werden alle pagina’s doorgelopen. Twee andere plugins gaven waarschuwingen, geen fouten. Die waarschuwingen verdwenen na een update van die plugins.
De sliderplugin. Met de nieuwe PHP-versie werkte de nieuwe versie van de plugin gewoon. Maar de slider zelf bleek drie afbeeldingen van elk ruim 2 MB te laden en niemand op kantoor wist nog waarom die er stond. In overleg is de slider vervangen door één statische afbeelding met een duidelijke tekst en een knop. De homepage werd er overzichtelijker en merkbaar sneller van.
Het beheerdersadres. Het e-mailadres in de algemene instellingen werd gewijzigd naar een adres dat op kantoor gelezen wordt. Klein werk, groot verschil bij een volgende storing.
Daarna werd alles in één keer naar de live site gezet, met opnieuw een back-up vooraf. Totale reparatietijd op maandag: ongeveer twee uur.
Wat het kostte en wat het had gekost
De eigenaar vroeg achteraf wat hij anders had moeten doen. Het eerlijke antwoord: niet op vrijdagmiddag veertien updates tegelijk draaien op een server met een verouderde PHP-versie, zonder back-up en zonder iemand die het kon opvangen. Maar dat wist hij zelf ook wel. De interessantere vraag is waarom die situatie kon ontstaan.
Het antwoord was simpel: niemand was verantwoordelijk. De freelancer was weg, de hosting doet geen onderhoud, en op kantoor was de website “iets wat er gewoon is”. Precies dat is de situatie waarin een spoedreparatie van een foutmelding nodig wordt, terwijl regulier onderhoud die reparatie meestal overbodig had gemaakt. Wat had het gekost om het weekend met een foutmelding door te komen? Dat weet niemand precies. Wel dat er tweeduizend nieuwsbrieflezers waren en dat de vacature een week later alsnog werd ingevuld door iemand die op maandag de site had bekeken.
De les die u meeneemt
Drie dingen uit deze case gelden voor vrijwel elke ondernemer met een WordPress-site.
- Weet waar uw hostinggegevens staan. Het langste deel van het herstel was zoeken naar een wachtwoord. Leg de gegevens vast op een plek die u kunt vinden zonder de persoon die de site bouwde.
- Zet het beheerdersadres op een adres dat gelezen wordt. De foutmail van WordPress bevat de oplossing vaak al, inclusief herstellink.
- Update nooit alles tegelijk op een moment dat u het niet kunt opvangen. Veertien updates op vrijdag om 15:50 is vragen om een weekend zonder site. Doe updates in kleine groepen, op een moment dat u kunt controleren, of laat het doen door iemand die het kan terugdraaien als het misgaat.
Het installatiebedrijf heeft na deze vrijdag gekozen voor een vast onderhoudsritme, waarbij de updates maandelijks in een testomgeving worden gedraaid voordat ze live gaan. Sindsdien is er geen foutmelding meer geweest op een vrijdagmiddag. Niet omdat er niets meer misgaat, maar omdat het nu misgaat op een testkopie, waar niemand het merkt. Staat uw site nu met een foutmelding? Begin dan bij het foutenlog en de herstelmail, en werk de stappen in dit artikel in volgorde af. Hoe u een critical error oplost zonder spoedhulp beschrijven we in ons uitgebreide stappenplan voor de critical error.
