U klikt op “Nu bijwerken”, het balkje loopt vol, en dan gebeurt het. De pagina blijft wit. Of u ziet een melding dat er een kritieke fout is opgetreden. Of de site blijft hangen in de onderhoudsmodus van WordPress, tien minuten nadat de update klaar had moeten zijn. Uw eerste reflex is de pagina verversen. Uw tweede reflex is paniek.

Een mislukte WordPress-update is vervelend, maar zelden een ramp. In veruit de meeste gevallen is de oorzaak een enkele plugin of een onderbroken bestandsoverdracht, en is de site binnen een half uur weer in de lucht. Dit artikel loopt in volgorde door wat u ziet, wat de waarschijnlijke oorzaak is, en wat u concreet doet. Adem eerst even uit; verversen helpt niet, systematisch werken wel.

Eerst kijken: welk symptoom heeft u?

Wat u op het scherm ziet, zegt al veel over waar het probleem zit. De vier meest voorkomende beelden na een update:

  • “Kort niet beschikbaar voor gepland onderhoud.” WordPress zet tijdens een update een tijdelijk bestand neer en verwijdert dat na afloop. Is de update halverwege afgebroken, dan blijft het bestand staan. Dit is de makkelijkste variant.
  • Een wit scherm zonder tekst. Meestal een PHP-fout in een plugin of thema die niet wordt getoond omdat foutmeldingen uitstaan. De oorzaak staat vrijwel altijd in het foutenlog.
  • “Er heeft zich een kritieke fout voorgedaan op deze website.” Zelfde oorzaak als het witte scherm, maar dan met een nette melding. Vaak ontvangt de beheerder ook een e-mail met een link om in herstelmodus in te loggen.
  • De site werkt, maar iets is kapot. Menu weg, lay-out verschoven, formulier stuurt niets meer. De update is technisch geslaagd, maar een plugin of het thema werkt anders dan voorheen.

Noteer ook wát u precies aan het bijwerken was. Eén plugin? Alles tegelijk? WordPress zelf? Dat bepaalt waar u straks als eerste kijkt.

WordPress-update mislukt: het stappenplan

Werk deze stappen in volgorde af en stop zodra de site weer werkt. Voor de meeste stappen heeft u toegang nodig tot de bestanden op de server, via het bestandsbeheer van uw hostingpaneel of via FTP. Weet u niet hoe u daar komt, dan is de handleiding van uw hostingpartij de eerste plek om te kijken.

  1. Controleer de onderhoudsmelding. Ziet u de tekst over gepland onderhoud? Zoek in de hoofdmap van uw website naar een bestand met de naam .maintenance en verwijder het. Ververs de site. Vaak is dit alles.
  2. Bekijk de herstel-e-mail. Bij een kritieke fout stuurt WordPress een mail naar het beheerdersadres met de naam van de plugin of het thema dat de fout veroorzaakt, plus een link naar de herstelmodus. Daarin kunt u de boosdoener uitschakelen zonder verdere toegang.
  3. Schakel de laatst bijgewerkte plugin uit. Komt u niet meer in het beheer, hernoem dan via de bestanden de map van die plugin in wp-content/plugins, bijvoorbeeld van formulier naar formulier-uit. WordPress ziet de plugin dan niet meer en laadt de site zonder. Werkt het weer, dan heeft u de oorzaak.
  4. Weet u niet welke plugin? Schakel ze allemaal uit. Hernoem de hele map plugins naar plugins-uit. Laadt de site nu wel, dan zit het probleem in een plugin. Zet de mapnaam terug en activeer de plugins één voor één in het beheer tot de fout terugkeert.
  5. Verdenk het thema. Was het thema bijgewerkt? Hernoem de themamap; WordPress valt dan terug op een standaardthema. Laadt de site, dan is het thema de oorzaak.
  6. Bekijk het foutenlog. Blijft het wit? In het hostingpaneel staat meestal een foutenlog. De laatste regels noemen het bestand en de regel waar het misgaat, en daarin staat de map van de verantwoordelijke plugin of het thema.
  7. Zet de back-up terug. Lukt niets, of duurt het te lang? Zet de back-up van vóór de update terug. Daarvoor heeft u hem gemaakt. Hoe dat zorgvuldig gaat, leest u in de uitleg over een back-up terugzetten.

Waarom gaat een update eigenlijk mis?

Begrijpen waarom het gebeurt, helpt om het volgende keer te voorkomen. De oorzaken die wij het vaakst tegenkomen:

  • Een pluginconflict. Twee plugins die na een update dezelfde functie op een andere manier aanpakken. Vooral bij plugins die diep in de site ingrijpen, zoals page builders, cache- en beveiligingsplugins.
  • Een verouderde PHP-versie. Een nieuwe pluginversie eist een nieuwere PHP-versie dan uw server draait. De plugin werkt dan simpelweg niet meer.
  • Onderbroken overdracht. De server had even geen ruimte of de verbinding viel weg, waardoor er halve bestanden staan. Opnieuw installeren van dezelfde versie lost dit op.
  • Geheugentekort. Grote updates hebben tijdelijk meer werkgeheugen nodig dan de server toestaat. Vaak zichtbaar in het log als “allowed memory size exhausted”.
  • Aanpassingen in het thema zelf. Iemand heeft ooit rechtstreeks in de themabestanden gewerkt. Een thema-update overschrijft die bestanden en de aanpassingen zijn weg.

Zo voorkomt u het de volgende keer

Een kwestie van drie gewoontes die weinig tijd kosten en veel ellende schelen.

Altijd eerst een back-up. Niet vertrouwen op de nachtelijke back-up van de hosting, maar zelf een verse maken vlak vóór de update en controleren dat hij compleet is. Dan is de ergste uitkomst van een mislukte update een kwartier terugzetten.

Niet alles tegelijk. Werk plugins in kleine groepjes bij en kijk tussendoor. Dat maakt het zoeken naar de veroorzaker een stuk korter dan wanneer er twintig updates in één klik zijn gedaan.

Test grote updates apart. Voor WooCommerce, page builders en het thema loont het om eerst op een testkopie te kijken of alles blijft werken. Bij een webshop is dat geen luxe maar noodzaak.

Een voorbeeld: een accountantskantoor in Amersfoort werkte vlak voor het weekend zelf een beveiligingsplugin bij. De site gaf maandagochtend een kritieke fout, precies toen klanten hun jaarstukken wilden uploaden. De herstelmail zat in de spamfolder van een oud-medewerker. Uiteindelijk was het een pluginmap hernoemen en één versie terugzetten; twintig minuten werk, maar wel na een weekend offline. Sindsdien staat het beheerdersadres op een gedeelde mailbox en gebeuren updates op dinsdagochtend.

Wanneer u hulp inschakelt

Komt u er na stap zeven nog niet uit, kunt u niet bij de bestanden, of durft u de back-up niet terug te zetten omdat er intussen bestellingen zijn binnengekomen? Dan is het verstandig om het uit handen te geven. Een specialist zet een site als deze doorgaans binnen een uur of twee weer in de lucht; bij WebMaintor begint dat vanaf 89 euro, en ook andere bureaus rekenen hier meestal een vast bedrag voor. Dat is bijna altijd goedkoper dan een dag zelf zoeken.

Voelt u er vooral niets voor om dit nog een keer mee te maken, dan is het nuttiger om naar de oorzaak te kijken dan naar de reparatie. Updates die met back-up, in stapjes en met controle worden uitgevoerd, gaan zelden mis. Dat kunt u zelf inplannen, of u laat het vast onderdeel zijn van een onderhoudsabonnement waarin iemand anders er elke maand naar kijkt. Beide zijn beter dan een rood bolletje dat u niet meer durft aan te klikken.