Een plugin-update heeft mijn WordPress-site stukgemaakt: zo diagnosticeer en draai je het terug

Je opende Plugins > Updates in wp-admin, klikte op Nu bijwerken bij een plugin die je al jaren draait, en de pagina kwam stuk terug. De voorkant van de site toont het kritieke-foutscherm, of erger nog, een volledig leeg document. Het dashboard laadt nog wel, of misschien is dat ook weg. Wat je in de afgelopen 60 seconden ook deed, je wil het terugdraaien. Dit artikel is dat rustige, stap-voor-stap terugdraaipad.

Wat "site stukgemaakt" meestal betekent na een plugin-update

Een plugin-update kan een site op drie verschillende manieren stukmaken, en het herstelpad hangt af van welke variant je in zit. Het type fout eerst herkennen voorkomt dat je de verkeerde fix gaat draaien.

1. PHP fatal error. De plugin-update introduceert code die PHP weigert uit te voeren. Je ziet "Er heeft zich een kritieke fout voorgedaan op deze site" aan de voorkant, of een volledig leeg scherm als de fatal heel vroeg toeslaat. De HTTP-response is 500. Het volledige diagnose-pad voor dit scherm vind je in there has been a critical error on this website.
2. Visuele of functionele regressie. De site laadt wel, maar de layout is stuk, een knop werkt niet meer, een formulier faalt stilletjes, of productpagina's renderen het verkeerde template. Geen PHP-fout, HTTP-status 200, maar er is duidelijk iets mis.
3. Database-corruptie of schema-mismatch. De plugin draaide bij de update een database-migratie (meestal WooCommerce bij een major versie, of elke plugin die dbDelta() aanroept), en nu probeert de nieuwe code tabellen te lezen die er anders uitzien dan voorheen. Symptomen lopen uiteen van ontbrekende data tot fatals op specifieke pagina's.

De eerste is de meest voorkomende en het meest zichtbaar. De derde is het gevaarlijkst, omdat de voor de hand liggende oplossing (de plugin-bestanden downgraden) de boel juist erger maakt. Daar kom ik zo op terug.

Stap 1: Check de WordPress Recovery Mode mail

Heeft de update een PHP fatal veroorzaakt tijdens een gewoon page load? Dan heeft WordPress je al een mail gestuurd. Dit is de officiële herstelflow, geïntroduceerd in WordPress 5.2 in mei 2019 en gedocumenteerd in het recovery mode handbook.

Wat je doet:

1. Open de inbox van het mailadres dat aan je WordPress admin-gebruiker hangt. Check ook de spam. De onderwerpregel is "[je sitenaam] Your Site is Experiencing a Technical Issue". De inhoud noemt welke plugin de fatal veroorzaakte en bevat een eenmalige recovery-link.
2. Klik op de recovery-link. WordPress logt je in wp-admin in in recovery mode, een speciale sessie waarin de stukke plugin alleen voor jou is gepauzeerd. Bezoekers zien nog steeds het kritieke-foutscherm.
3. Ga naar Plugins. De stukke plugin staat als gepauzeerd gemarkeerd. Deactiveer hem.
4. Log uit. Daarmee eindigt de recovery mode.

Je weet dat het werkte als de site weer normaal laadt voor bezoekers en het foutscherm weg is. Bevestig dat door de site in een privé-browservenster te openen.

Twee dingen over recovery mode die in artikelen vaak worden overgeslagen:

• Recovery mode werkt niet bij background-requests. Hij vuurt alleen als een gewoon page load de fatal triggert. Cron jobs en REST API background-calls die dezelfde fatal raken, leveren geen mail of recovery-sessie op. Als jouw fatal alleen optreedt tijdens bijvoorbeeld een geplande WooCommerce-actie, kan de recovery-mail nooit komen.
• Mailbezorging is niet gegarandeerd. Treedt de fatal op voordat SMTP-plugins zijn geladen, dan probeert WordPress de mail rechtstreeks via PHP's mail() functie te versturen, en dat is op veel hosts onbetrouwbaar of geblokkeerd. De mail kan in spam belanden of gewoon worden gedumpt. Komt er binnen vijf minuten geen mail? Ga dan door naar stap 2.

De recovery-link is rate-limited: standaard wordt er hooguit één keer per 24 uur een nieuwe mail verstuurd. Heb je de eerste gemist? Blijf dan niet de stukke pagina vernieuwen in de hoop op een nieuwe mail.

Stap 2: Kom binnen zonder dashboard

Komt de recovery-mail niet, of is wp-admin zelf ook stuk, dan moet je de boosdoener van buitenaf uitschakelen. Er zijn drie betrouwbare manieren. Pak de manier waar jouw host je toegang voor geeft.

Optie A: hernoem de plugin-folder via SFTP

Dit is het eenvoudigste en veiligste pad. Je hebt alleen bestandstoegang nodig.

1. Connect met je site via SFTP, SSH of de file manager van je host.
2. Navigeer naar wp-content/plugins/.
3. Hernoem de folder van de verdachte plugin door er .off achter te plakken, bijvoorbeeld van bad-plugin naar bad-plugin.off.
4. Herlaad de voorkant van de site in een privé-browservenster.

Je weet dat het werkte als de site weer normaal laadt. WordPress kon de plugin niet meer vinden op de verwachte plek, behandelt hem als gedeactiveerd en gaat door. De instellingen van de plugin blijven gewoon in de database staan. Als je de plugin later fixt of vervangt en de oude folder-naam terugzet, staat al je configuratie er nog.

Weet je nog niet welke plugin de boosdoener is? Hernoem dan de hele wp-content/plugins/ folder naar plugins.disabled. WordPress deactiveert in één klap alle plugins. Herlaad de site. Komt hij weer terug? Zet dan de folder-naam terug en activeer plugins één voor één in wp-admin totdat de fatal terug is. De laatste plugin die je activeerde, is de oorzaak.

Optie B: WP-CLI

Geeft je host SSH-toegang en is WP-CLI geïnstalleerd? Dan heb je een snellere optie. Het commando staat in de WP-CLI plugin deactivate reference.

# Eén plugin deactiveren op folder-naam
wp plugin deactivate bad-plugin

# Alle plugins tegelijk uitzetten (snelste noodstop)
wp plugin deactivate --all

# Alles uitzetten behalve WooCommerce
wp plugin deactivate --all --exclude=woocommerce

# Op multisite, network-wide deactiveren
wp plugin deactivate bad-plugin --network

WP-CLI praat rechtstreeks met de WordPress-database en het filesystem, dus het werkt ook als wp-admin een fatal teruggeeft. Je weet dat het werkte als de volgende wp plugin list de plugin als inactive toont en de voorkant laadt.

Optie C: noodgreep met een PHP-bestand (alleen als A en B onmogelijk zijn)

Een handvol hosts blokkeren zowel SFTP als SSH en laten je alleen via een web-interface bestanden uploaden. In dat geval kun je een eenmalig PHP-bestand in de WordPress-root droppen dat deactivate_plugins() aanroept voor de verdachte plugin, het bestand één keer in je browser laden en het daarna direct verwijderen. Dit is een laatste redmiddel. wp_options.active_plugins direct in de database aanpassen staat nog een stap lager op de lijst en is écht een laatste redmiddel, want een serialized PHP-array is met de hand zo corrupt.

Stap 3: Vind de boosdoener via de debug log

Als de site weer draait, wil je nog steeds weten welke plugin de fatal veroorzaakte zodat je kan beslissen wat de volgende stap is. De debug log vertelt je het bestand en de regel, en dat vertelt je de plugin.

Heb je WP_DEBUG_LOG nog niet aanstaan? Volg dan mijn gids over de WordPress debug log inschakelen en lezen om de vier constanten in wp-config.php correct te zetten. De korte versie:

// WordPress debugging aanzetten
define( 'WP_DEBUG', true );
// Schrijf alle PHP-fouten naar wp-content/debug.log
define( 'WP_DEBUG_LOG', true );
// Verberg fouten in de pagina-output (sla deze regel NIET over)
define( 'WP_DEBUG_DISPLAY', false );
// Dubbele zekerheid: ook PHP zelf vragen geen fouten te tonen
@ini_set( 'display_errors', 0 );

Staan die vier regels eenmaal goed? Activeer de stukke plugin dan even tijdelijk weer (hernoem de folder terug van bad-plugin.off naar bad-plugin, of run wp plugin activate bad-plugin), herlaad de pagina die de fatal triggerde, en deactiveer de plugin meteen daarna weer. Open dan wp-content/debug.log. De laatste regels beschrijven precies wat er stuk ging. Een typische regel ziet er zo uit:

[08-Apr-2026 14:23:11 UTC] PHP Fatal error: Uncaught Error: Call to undefined function get_field() in /var/www/html/wp-content/plugins/some-plugin/render.php on line 87

De foldernaam in het pad (some-plugin) is de plugin om in de gaten te houden. De functienaam in de melding (get_field()) vertelt je vaak ook de onderliggende oorzaak: in dit voorbeeld hangt de plugin af van Advanced Custom Fields, en die is niet geladen. Bewaar de laatste 30 regels van debug.log integraal. Die heb je nodig als je de bug bij de plugin-auteur meldt, en als je beslist welk rollback-pad je kiest.

Zet WP_DEBUG terug op false zodra je je antwoord hebt. Live sites moeten nooit langer met debug logging aan draaien dan het incident zelf.

Stap 4: Draai de plugin terug

Je hebt drie rollback-opties, en die zijn niet gelijkwaardig. Kies op basis van wat de plugin daadwerkelijk doet met je database tijdens een update.

Optie A: gebruik de WP Rollback plugin (gratis, alleen wordpress.org plugins)

De WP Rollback plugin op versie 3.1.0 is het standaard hulpmiddel om naar een oudere versie van een plugin terug te gaan zonder een volledige backup-restore. Na installatie krijgt elke plugin in je dashboard een "Rollback"-link waarmee je een willekeurige eerdere versie kunt kiezen uit de WordPress.org SVN-repository. WP Rollback installeert die versie op exact dezelfde manier als de ingebouwde updater nieuwe versies installeert.

De gratis versie werkt alleen met plugins die op wordpress.org staan. Premium plugins, betaalde extensies en alles wat je rechtstreeks van een ontwikkelaar of marketplace hebt, krijgt geen rollback-link, tenzij je WP Rollback Pro draait van wprollback.com, dat een aparte Plugin Vault-archief gebruikt.

Hoe je het gebruikt voor een wordpress.org plugin:

1. Installeer WP Rollback uit de WordPress plugin directory en activeer hem.
2. Ga naar Plugins > Geïnstalleerde plugins.
3. Zoek de stukke plugin op. Eronder staat een nieuwe "Rollback"-link.
4. Klik erop. Je krijgt een lijst met alle uitgebrachte versies van de plugin.
5. Kies de versie die werkte vóór de stukke update. Klik op "Rollback".
6. Wacht tot de installatie klaar is.
7. Herlaad de voorkant en test de pagina die eerst stuk was.

Je weet dat het werkte als de site normaal laadt en de pagina die de fatal triggerde nu weer netjes reageert.

Een historisch detail dat handig is om te weten: WP Rollback versies vóór 3.0.12 hadden een bug waarbij de rollback-flow per ongeluk de uninstall.php hook van de plugin afvuurde. Bij plugins die hun eigen data verwijderen tijdens uninstall, betekende dat: database-tabellen en options weg, voordat de oudere code überhaupt geïnstalleerd werd. Die bug is in 3.0.12 in 2024 verholpen en komt op huidige versies niet meer voor. Installeer je WP Rollback nu voor het eerst, dan krijg je 3.1.0 of nieuwer en heb je hier geen last van. Heb je een oude versie al staan, update die dan eerst.

Optie B: restore vanaf een volledige backup (de enige veilige route bij migration-heavy plugins)

Dit is de optie die de val oplost waar WP Rollback niets aan kan doen.

WP Rollback vervangt alleen bestanden. Het zet je database niet terug. Dat is belangrijker dan het klinkt.

Als een plugin tijdens een update een database-migratie draait, schrijft de nieuwe versie nieuwe tabellen, nieuwe kolommen of nieuwe schema's, en bewaart vervolgens een versienummer in wp_options zodat hij weet dat de migratie is gedraaid. WooCommerce doet dit bij elke major versie (van 8.x naar 9.x veranderden bijvoorbeeld de order-tabellen). Gravity Forms doet het. Elke plugin die dbDelta() aanroept tijdens activatie kan het doen.

Als je de bestanden van zo'n plugin terugdraait zonder ook de database terug te draaien, laadt de oude code tegen een database die hij niet snapt. Het resultaat: dezelfde fatal die je probeerde op te lossen, plus mogelijk stille datacorruptie die je dagen later pas opmerkt.

Het veilige pad voor elke migration-heavy plugin is om de hele site, bestanden én database, terug te zetten vanaf een backup die vóór de update is gemaakt.

Kan je host of je backup-tool een one-click full restore doen? Gebruik dat. Heb je losse file- en database-backups? Zet ze als paar terug. De match tussen bestanden en database is wat telt. Een file-restore van gisteren gepaard aan een database van vorige week is op zichzelf weer een stukke staat. De volledige uitleg van de restore zelf staat in een WordPress-site herstellen vanaf een backup, en de vraag welke backup je terug moet zetten hoort in datzelfde artikel thuis.

Je weet dat het werkte als de site laadt, de eerder stukke pagina weer correct reageert en een snelle scan van recente posts, orders of formulier-inzendingen geen ontbrekende data toont na het restore-punt.

Optie C: handmatig de oude versie reinstalleren

Voor premium plugins en alles wat niet op wordpress.org staat, is dit vaak de enige file-only rollback-optie buiten WP Rollback Pro om.

1. Download vanuit je account bij de plugin-leverancier het .zip-bestand van de oudere versie. De meeste serieuze leveranciers houden een archief van eerdere versies bij in je accountgedeelte. Doen ze dat niet? Mail dan support en vraag erom.
2. Ga in wp-admin naar Plugins > Geïnstalleerde plugins.
3. Deactiveer de stukke plugin en verwijder hem. WordPress vraagt of je de data van de plugin wil verwijderen. Kies nee, tenzij je echt opnieuw wil beginnen, want de meeste plugins draaien hier hun uninstall.php hook, en sommige verwijderen daarbij al je instellingen.
4. Klik op Nieuwe plugin > Plugin uploaden en upload het oudere .zip-bestand.
5. Activeer de oudere versie.
6. Herlaad de voorkant en test.

Heeft de plugin tijdens de stukke update een database-migratie gedraaid? Dan zit deze methode met dezelfde val als optie A: de database staat in het nieuwe schema en de oude code kan daar misschien niets mee. Voor elke plugin die zijn eigen tabellen aanraakt tijdens een update is een full backup restore (optie B) de veiligere keuze.

Wat de "rollback"-features in WordPress core eigenlijk doen

Je hebt misschien gelezen dat WordPress 6.3 of WordPress 6.6 rollback-features aan core hebben toegevoegd. Allebei klopt, maar geen van beide is de aanklikbare rollback-knop die mensen erin lezen.

WordPress 6.3 voegde auto-revert toe voor mislukte handmatige updates in augustus 2023. Vóór een handmatige plugin-update begint, verplaatst WordPress de vorige versie naar wp-content/upgrade-temp-backup/. Faalt het update-proces zelf halverwege (de download is corrupt, de doelmap kan niet leeggemaakt worden, het install-pakket geeft een fout terug), dan zet WordPress automatisch de oude versie weer terug. Het geeft je geen rollback-knop ná een geslaagde update. Is de update wel afgerond maar is de nieuwe versie stuk, dan doet WP 6.3 niets voor je. De upgrade-temp-backup/ directory is volgens de docs niet bedoeld voor handmatig rollback-gebruik.

WordPress 6.6 voegde auto-rollback toe voor auto-updates in juli 2024. Na een achtergrond-auto-update vuurt WordPress een loopback HTTP-request af naar zijn eigen homepage. Raakt dat request een PHP fatal error, dan zet WordPress de plugin automatisch terug naar de vorige versie en mailt de admin. Dit geldt alleen voor background auto-updates, niet voor handmatige updates die je vanuit het dashboard start. Het vangt alleen PHP fatals af, geen visuele breuken, JavaScript-fouten of datacorruptie. En omdat het op loopback-requests leunt, kunnen sites met stukke loopbacks updates onnodig terugdraaien, of updates die wél teruggedraaid hadden moeten worden juist laten staan.

De conclusie: als jij in de Plugins-pagina op "Nu bijwerken" klikt en de nieuwe versie is stuk, helpt geen van beide features je. Het herstel komt op jou neer, en dat is precies waarom dit artikel bestaat.

Wanneer je hulp moet inschakelen

Krijg je de site met geen van de stappen hierboven weer aan de praat, of is de rollback wel gelukt maar is er data weg, leg het probleem dan neer bij je host of een WordPress-specialist. Elke minuut die zij besparen op context, is een minuut dichterbij een gezonde site. Verzamel dit pakket voordat je vraagt:

• De exacte naam en versie van de plugin die je hebt geüpdatet, plus de versie waarvan je upgradede als je dat nog weet.
• Een kopie van de foutmelding die bezoekers aan de voorkant zien, of "lege pagina" als die er niet is.
• De HTTP-statuscode (open de Network-tab van je browser op het mislukte request).
• De PHP-versie op de server (zichtbaar in je hostingpaneel).
• De WordPress-versie (uit wp-includes/version.php of een werkend dashboard-scherm).
• De volledige laatste 30 regels van wp-content/debug.log na één keer triggeren van de fatal.
• Een lijstje van elke herstelstap die je hebt geprobeerd, op volgorde, en wat er telkens gebeurde.
• Of je een backup hebt van vóór de update, waar die staat en hoe je hem terugzet.
• Bij migration-heavy plugins (WooCommerce, Gravity Forms, alles met eigen tabellen): of de stukke update door dbDelta() ging of een nieuwe schema-versie installeerde.

Een specialist kan een plugin-update-incident meestal binnen een uur oplossen met dat pakket in handen. Zonder pakket duurt dezelfde klus de rest van de middag.

De bug melden bij de plugin-auteur

Sla deze stap niet over nadat je hebt teruggedraaid en de site weer staat. Plugin-auteurs fixen bugs waar ze van horen. De bugmeldingen die ze nodig hebben zijn kort, specifiek, en bevatten de stukke regel uit de debug log.

Voor een wordpress.org plugin: open een topic op het supportforum van de plugin op wordpress.org (elke plugin heeft een "Support"-tab op zijn directory-pagina). Voeg toe:

• De plugin-versie die stuk ging (de nieuwe).
• De plugin-versie die werkte (de vorige).
• Je PHP-versie en WordPress-versie.
• De volledige laatste PHP Fatal error regel uit debug.log, letterlijk gekopieerd.
• Andere plugins die op dat moment actief waren, en zeker alles waar de fatal-regel op lijkt te leunen.
• Stappen om het te reproduceren, als je die kunt benoemen. Soms is "ik klikte op update" de enige stap die er is.

Voor een premium plugin: open een support-ticket via het accountgedeelte van de leverancier met hetzelfde pakket. Premium support-tickets gaan vaak sneller dan threads op het wordpress.org forum, en dat is deels waar je voor betaalt.

Veiliger updaten zodat de volgende keer niets stukgaat

Je kunt mislukte plugin-updates niet helemaal voorkomen, maar je kunt ze wél zeldzaam en overleefbaar houden.

• Test plugin-updates eerst op een staging-kopie. Een staging-omgeving is verreweg de grootste risicobeperker voor dit type incident. Het volledige opzetpad staat in een WordPress staging-omgeving inrichten. Belangrijke nuance: staging is niet perfect. Staging-sites kunnen verschillen van productie in PHP-versie, serverconfiguratie, verkeerspatronen, databasegrootte en third-party connecties. Een plugin-conflict dat alleen onder productiebelasting opduikt, zie je niet op een rustige staging-kopie. Staging beperkt het risico, maar haalt het niet weg.
• Maak vlak voor elke update een volledige backup. Bestanden én database, niet alleen één van beide. Een backup van vijf minuten geleden laat je in 60 seconden terugzetten. Een backup van gisteren betekent dat je vandaag's content kwijt bent. Doet je host dit automatisch? Bevestig dan waar de backups landen en hoe je een restore start.
• Update één plugin per keer. Tien plugins in één klik bijwerken bespaart je 30 seconden en kost je het vermogen om te weten welke het stukmaakte als er iets misgaat. Eén voor één doen, en na elke update de voorkant herladen, is langzamer maar veiliger.
• Houd de site vijf minuten in de gaten na elke update. Veel plugin-fouten duiken pas op bij het eerste request dat het nieuwe code-pad raakt. Een 200 op de homepage vlak na de update bewijst niet dat de checkout nog werkt. Klik door de stukken van de site die voor jouw business tellen.
• Zet auto-updates uit voor plugins die je eerder hebben geraakt. WordPress auto-updates staan standaard uit voor plugins, maar misschien heb je ze aangezet. Heeft een plugin je site eerder stukgemaakt bij een update? Dan is handmatig updaten de kleine extra moeite waard.
• Abonneer je op de release notes van de plugin. Voor missiekritische plugins (zeker WooCommerce, alles dat betalingen doet, alles dat klantdata raakt) vertelt het lezen van de changelog vóór je op update klikt of de nieuwe versie de database aanraakt. Doet hij dat? Behandel die update dan als een grote ingreep, niet als een routine-klik.

De reden dat plugin-updates sites stukmaken: WordPress is een open ecosysteem met tienduizenden plugins gebouwd door mensen met heel verschillende test-standaarden. De reden dat je snel kunt herstellen: je hebt een herstelflow die je één keer hebt geoefend voordat je hem nodig had. Loop dit artikel een keer door op een staging-site die je expres mag stukmaken. Het volgende echte incident wordt dan een klusje van een kwartier in plaats van een paniekerige middag.