WordPress-website kapot na een update: netjes terugdraaien

In het kort

Zoek uit wat er is bijgewerkt, en wanneer: het updatescherm, de e-mails van WordPress over automatische updates, het paneel van de hostingprovider.
Leeg eerst de caches: een kapotte opmaak komt vaak van oude CSS-bestanden die nog in een cache staan.
Blijft de site hangen op “Tijdelijk niet beschikbaar vanwege gepland onderhoud”: verwijder het bestand .maintenance in de root.
Plugin of thema: installeer de vorige versie opnieuw, met WP-CLI of het archief van de maker.
PHP-versie gewijzigd door de hostingprovider: keer in het paneel terug naar de vorige versie, zolang u het betrokken onderdeel bijwerkt.
Bewaar het terugzetten van een volledige back-up als laatste redmiddel, na een export van wat de site sinds die back-up heeft ontvangen.

Wat is er bijgewerkt?

Op een WordPress-site worden vier dingen bijgewerkt, en elk ervan draait u anders terug: de kern van WordPress, de plugins, het thema, en de PHP-versie van de server, die de hostingprovider in zijn eigen tempo vernieuwt. Om te weten welk onderdeel is veranderd:

De e-mails van WordPress: na een automatische update schrijft WordPress naar het beheerdersadres van de site, met een onderwerp als “[Naam van de site] Sommige plugins zijn automatisch geüpdatet”, en de lijst van wat er is veranderd.
Het scherm Plugins: de kolom “Automatische updates” toont welke plugins zichzelf bijwerken, en elke regel toont de geïnstalleerde versie.
Tools > Sitediagnose > Informatie: het onderdeel Server geeft de PHP-versie, en de onderdelen voor plugins en thema’s de versie van elk onderdeel.
De datums van de mappen: een pluginmap die door een update is herschreven, draagt de datum van die update.

Terminal, in de root van de site

wp plugin list
ls -lt wp-content/plugins | head

De eerste opdracht toont de plugins met hun versie en status; de tweede de pluginmappen, van de meest recent gewijzigde tot de oudste. Leg ze naast het tijdstip waarop de site veranderde.

De caches legen voordat u conclusies trekt

Na een update veranderen de CSS- en JavaScript-bestanden van inhoud, en een cache kan de oude blijven serveren. Het resultaat lijkt op een storing: opmaak in stukken, menu’s die niet meer openen. Leeg, in deze volgorde, de cache van de cache- of optimalisatieplugin, de cache van de hostingprovider als die er een aanbiedt, en daarna die van de browser, en laad de pagina opnieuw. Komt de site terug, dan lag het niet aan de update.

De site blijft in onderhoudsmodus hangen

Tijdens een update maakt WordPress een bestand .maintenance aan in de root van de site en toont het “Tijdelijk niet beschikbaar vanwege gepland onderhoud. Probeer het over enkele minuten nog een keer.” Wordt de update onderbroken, dan blijft het bestand staan. WordPress negeert het tien minuten na het tijdstip dat erin staat; wilt u niet wachten, of blijft de melding staan, verwijder het dan via SFTP of via de bestandsbeheerder van de hostingprovider. De naam begint met een punt, dus zet de weergave van verborgen bestanden aan om het te zien.

Ga daarna naar Dashboard > Updates: het onderdeel waarvan de update is onderbroken, start u opnieuw, of u installeert het opnieuw in de vorige versie.

De vorige versie van een plugin terugzetten

De vorige versie opnieuw installeren vervangt de bestanden van de plugin en behoudt de instellingen, die in de database staan.

Terminal: een specifieke versie opnieuw installeren

wp plugin install naam-plugin --version=2.4.1 --force

Plugin uit de repository van WordPress.org: op de publieke pagina van de plugin (nl.wordpress.org) leidt de link “Geavanceerde weergave” naar de lijst “Eerdere versies”. Download het gewenste archief en klik daarna in het scherm “Plugins toevoegen” op “Plugin uploaden”: WordPress herkent de al geïnstalleerde plugin en biedt “Huidige vervangen door de geüploade” aan.
Plugin gekocht bij een maker: eerdere versies zijn meestal te downloaden vanuit uw klantenaccount bij die maker.
Daarna: klik bij deze plugin op “Auto-updates uitschakelen”, tot de maker een oplossing uitbrengt.

WordPress draait in twee gevallen zelf terug. Sinds versie 6.3 wordt de oude versie teruggezet wanneer de update van een plugin of thema halverwege mislukt. Sinds versie 6.6 installeert WordPress de vorige versie opnieuw wanneer de automatische update van een actieve plugin een fatale fout veroorzaakt. Een update die slaagt en een functie breekt zonder fatale fout, draait u met de hand terug.

Het thema: de vorige versie, en verloren aanpassingen

Terminal

wp theme install naam-thema --version=3.1.0 --force

Een thema-update vervangt alle bestanden van het thema. Wijzigingen die rechtstreeks in die bestanden zijn gedaan, bijvoorbeeld in functions.php of een stylesheet, verdwijnen dus bij elke update. De back-up van vóór de update maakt het mogelijk ze terug te vinden; om ze blijvend te bewaren, horen ze in een child-thema, dat de updates van het hoofdthema ongemoeid laten.

De kern van WordPress

WP-CLI installeert een specifieke versie van de kern opnieuw:

Terminal (vervang 7.0 door de versie van vóór de update)

wp core update --version=7.0 --force

Een grote update van de kern kan ook de structuur van de database veranderen, en die laat deze opdracht zoals ze is. Het veiligst is vaak de kern bijgewerkt te laten en de incompatibele plugin of het incompatibele thema terug te draaien. Is terugkeren met de kern onvermijdelijk, doe het dan vanuit een volledige back-up van vóór de update.

De PHP-versie, gewijzigd door de hostingprovider

Hostingproviders stappen over op nieuwere PHP-versies naarmate de oude geen beveiligingsupdates meer krijgen. Een oude plugin of een oud thema kan dan stoppen op een fatale fout. In het paneel van de hostingprovider kiest u meestal de PHP-versie van de site:

Noteer de huidige versie en keer daarna terug naar de vorige.
Controleer of de site weer werkt.
Werk het betrokken onderdeel bij of vervang het; het debuglogboek wijst het aan.
Schakel weer over naar de recente versie.

Deze terugkeer is een noodstap: een PHP-versie zonder beveiligingsupdates stelt de site bloot. Volgens het officiële schema op php.net krijgt PHP 8.1 sinds 31 december 2025 geen beveiligingsupdates meer, krijgt PHP 8.2 ze tot 31 december 2026 en PHP 8.3 tot 31 december 2027. WordPress raadt PHP 8.3 of nieuwer aan.

Een volledige back-up terugzetten, als laatste redmiddel

Terugzetten brengt de bestanden en de database terug naar de toestand van de back-up. Alles wat de site sindsdien heeft ontvangen, verdwijnt: bestellingen, formulierberichten, reacties, inschrijvingen, gepubliceerde berichten.

Exporteer eerst wat er sinds de back-up is binnengekomen: bestellingen, formulierinzendingen, nieuwe accounts.
Zet bestanden en database van hetzelfde moment terug, met de tool van de hostingprovider of uw back-upplugin. Bestanden van de ene dag en een database van een andere dag geven fouten die moeilijk te lezen zijn.
Importeer de geëxporteerde gegevens opnieuw.
Pas de updates een voor een opnieuw toe en controleer de site na elke update: de laatste die vóór de storing is toegepast, is de oorzaak.

Voor de volgende update

Een testkopie: veel hostingproviders bieden een stagingomgeving die de site met één klik kopieert. De updates gaan daar eerst naartoe.
Een back-up vlak ervoor, bestanden en database samen.
Eén update tegelijk, met een controle van de belangrijkste pagina’s ertussen: homepage, contactformulier, winkelwagen.
De changelog van de plugin of het thema, gelezen vóór een grote update.

Updates door onze technici

Met Serenity by Simafri maken wij uw professionele website, hosten hem, beveiligen hem en houden hem up-to-date. U schrijft ons, wij zorgen voor alles. Domeinnaam en zakelijke e-mail inbegrepen.

Ontdek Serenity by Simafri

Veelgestelde vragen

Hoe draai ik de update van een WordPress-plugin terug?

Installeer de vorige versie opnieuw: met WP-CLI via wp plugin install naam-plugin --version=nummer --force; zonder WP-CLI downloadt u het archief van de vorige versie en uploadt u het via het scherm Plugins toevoegen, waarbij u kiest om de huidige plugin te vervangen. De instellingen van de plugin, die in de database staan, blijven bewaard.

Kan WordPress een update zelf terugdraaien?

In twee gevallen. Sinds WordPress 6.3 laat een update van een plugin of thema die halverwege mislukt, de oude versie staan. Sinds WordPress 6.6 wordt een automatische update van een actieve plugin die een fatale fout veroorzaakt, teruggedraaid. Een update die slaagt en een functie breekt zonder fatale fout, draait u met de hand terug.

Waarom is mijn opmaak veranderd na de update van het thema?

Ofwel serveert een cache nog de oude CSS-bestanden, en dan volstaat het de caches te legen; ofwel waren er wijzigingen rechtstreeks in de bestanden van het thema gedaan, en heeft de update die vervangen. In dat tweede geval haalt u ze terug uit de back-up van vóór de update, en zet u ze daarna in een child-thema.

Moet ik automatische updates uitschakelen?

Updates dichten ook beveiligingslekken, en een site die ze laat ontvangt, blijft langer blootgesteld. De aanpak die standhoudt, is een update die eerst op een testkopie wordt toegepast, met een back-up vlak ervoor. Voor een plugin die problemen geeft, kunt u de automatische updates uitschakelen tot er een oplossing is.

Bronnen en officiële documentatie

Gerelateerde gidsen

Wit scherm of kritieke fout in WordPress: eerst de foutmelding lezenUw site toont een lege pagina, of de zin “Er heeft zich een kritieke fout voorgedaan op deze site.” In beide gevallen heeft PHP ergens een precieze melding geschreven, die het betrokken bestand noemt. Deze gids laat zien waar u die leest, hoe u haar uitlegt, en welke stap bij elke melding hoort.Fout bij het maken van de databaseconnectie in WordPress: wat het betekentUw site toont nog maar één regel: “Fout bij het maken van de databaseconnectie”. WordPress kon de database niet openen waarin uw pagina’s, instellingen en accounts staan. Uw inhoud is meestal intact: deze gids laat zien hoe u vindt welke van de vier mogelijke oorzaken speelt, en hoe u die verhelpt.

WordPress-website kapot na een update: netjes terug naar de vorige versie