PHP 8 upgrade WordPress fatal error voorkomen en oplossen

PHP 7.4 ging in november 2022 uit beveiligingsondersteuning. PHP 8.0 volgde in november 2023, PHP 8.1 in november 2025. Dat staat in het PHP supported versions overzicht. Toch draait een flink deel van de WordPress-sites in Nederland nog op een verouderde PHP-versie, vaak zonder dat de eigenaar het weet.

Bij een PHP 8 upgrade WordPress fatal error gebeurt het volgende: hosting forceert een nieuwe PHP-versie, een plugin of thema is niet PHP 8-compatibel, en de site valt om met een witte pagina of een 500-fout. Vaak gebeurt het zelfs zonder waarschuwing, omdat de hostingpartij stilletjes upgrade.

In dit artikel lees je hoe je dit voorkomt en wat je doet als het al gebeurd is. Ik werk al jaren met PHP, in WordPress maar ook in Laravel en eigen scripts. De aanpak hieronder is wat ik zelf gebruik bij elke PHP-migratie.

Waarom een PHP-upgrade fout kan gaan

PHP 8 brengt grote veranderingen ten opzichte van PHP 7. Strenger type-checking, nieuwe reserved keywords, weggevallen functies, andere error-handling. Voor moderne code is dat winst. Voor oudere plugins en thema’s is dat een breekpunt.

De drie meest voorkomende oorzaken die ik tegenkom:

• Een verouderde plugin gebruikt een functie die in PHP 8 is verwijderd
• Een thema (vaak ouder dan vier jaar) heeft code die niet meer compileert in PHP 8
• Een custom snippet in functions.php of in een mu-plugin gebruikt deprecated PHP-syntax

Een specifieke valkuil: bij PHP 8 zijn waarschuwingen die in PHP 7 alleen in de log verschenen, ineens fatale errors geworden. Een site die “werkt met waarschuwingen” onder PHP 7.4 kan onder PHP 8.0 volledig stoppen.

Welke PHP-versie moet je hebben

WordPress raadt zelf PHP 8.2 of hoger aan. Het absolute minimum is PHP 7.4, maar dat krijgt geen beveiligingsupdates meer.

Mijn aanbeveling voor de meeste sites:

• Brochuresite of klein bedrijf: PHP 8.2 (stabiel en breed ondersteund)
• WooCommerce shop met actieve plugins: PHP 8.2 (verifieer plugin-versies vooraf)
• Site met veel custom code of een ouder thema: eerst testen op PHP 8.1, dan door naar 8.2
• Headless of API-zware sites: PHP 8.3 (snelste, lichtere geheugen-footprint)

Springen van PHP 7.4 direct naar PHP 8.2 kan, maar het is risicovoller dan in stapjes. In de praktijk doe je 7.4 naar 8.0, test alles, dan door naar 8.1, dan naar 8.2. Per stap los je incompatibele code op.

Voorbereiding voordat je upgrade

Drie dingen vóór je iets aanpast.

Volledige backup. Bestanden via FTP of het hostingpaneel, plus een database-export. Bewaar dit op een externe locatie. Geen “ik vertrouw op de hostingbackup”, maar je eigen kopie.

Plugin- en thema-inventaris. Ga in WordPress-admin naar de plugin-pagina en noteer welke plugins er staan, met versienummers. Doe hetzelfde voor het thema. Controleer of er updates beschikbaar zijn die je niet hebt geïnstalleerd. Verouderde plugins zijn de meest voorkomende oorzaak van PHP-incompatibiliteit.

Site Health-check. WordPress heeft een ingebouwde Site Health-pagina (Tools → Site Health). Daar staat de huidige PHP-versie, geheugenlimiet, en eventuele bekende problemen. Maak hier een screenshot van zodat je later weet wat de uitgangssituatie was.

Optioneel maar verstandig: installeer de plugin PHP Compatibility Checker. Deze scant je plugins en thema’s op PHP 8-incompatibele code. Niet feilloos (sommige issues vindt hij niet), maar wel een goede eerste filter.

Testen op een staging-omgeving

De gouden regel: nooit PHP upgraden op productie zonder een geslaagde test op staging.

Een staging-omgeving is een werkende kopie van je site op een sub-domein of in een aparte map. Bij Hostinger, SiteGround en Cloudways is staging een knop in het hostingpaneel. Bij eigen servers maak je een sub-domein zoals staging.jouwsite.nl en kopieert daarheen je hele site.

Op staging zet je de PHP-versie naar de nieuwe versie, en je doorloopt:

• Werkt de homepage zonder fouten?
• Werkt de admin-login?
• Werken alle formulieren? (Test elk formulier met een testbericht)
• Werken WooCommerce-checkouts (testorder met een testbetalingsplugin)?
• Verschijnen er foutmeldingen in wp-content/debug.log?
• Werken alle custom scripts en API-koppelingen?

Vind je problemen op staging? Los ze daar op. Update de betreffende plugin, vervang hem, of pas custom code aan. Pas als staging volledig schoon draait, ga je live.

De daadwerkelijke upgrade uitvoeren

Bij de meeste hostings is PHP-versie wijzigen één knop in het hostingpaneel. Geen ingewikkelde server-commando’s nodig.

Bij cPanel: ga naar “Select PHP Version” of “MultiPHP Manager”, kies de gewenste versie, en bevestig. Wijziging is binnen enkele seconden actief.

Bij Plesk: ga naar het domein, klik op “PHP Settings”, en kies de gewenste versie.

Bij managed WordPress hosting: Cloudways, Kinsta, WP Engine en SiteGround hebben allemaal een eigen PHP-management-tool in hun paneel.

Direct na de switch:

1. Open de site in een incognito-tab (cache uitsluiten)
2. Login in WordPress-admin en controleer dat alles laadt
3. Check de Site Health-pagina opnieuw
4. Doe een steekproef op drie tot vijf belangrijke pagina’s
5. Test een formulier en een aankoop

Werkt alles? Dan ben je klaar. Werkt er iets niet? Switch direct terug naar de oude PHP-versie en analyseer het probleem op staging.

Wat te doen bij een fatal error of white screen

Eerst geen paniek. Een PHP-fatal error is meestal binnen minuten op te lossen, mits je weet waar je moet kijken.

Stap 1: schakel debug-mode aan. Bewerk wp-config.php en zet:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Hiermee schrijft WordPress fouten naar wp-content/debug.log in plaats van ze op het scherm te tonen. Open dit bestand om de exacte foutmelding te zien. Je krijgt iets als:

Fatal error: Uncaught Error: Call to undefined function each() in /plugins/oude-plugin/file.php on line 42

Stap 2: identificeer de oorzaak. De foutmelding noemt de plugin of het thema dat de fout veroorzaakt. In het voorbeeld hierboven: oude-plugin. Dat is de boosdoener.

Stap 3: schakel de schuldige plugin uit. Lukt het niet via WP-admin (omdat de admin zelf vastloopt), dan hernoem je de plugin-map via FTP. Map wp-content/plugins/oude-plugin/ wordt wp-content/plugins/oude-plugin-uit/. WordPress beschouwt de plugin dan als verwijderd en de site komt weer in de lucht.

Stap 4: kies een vervanger of een update. Zoek de meest recente versie van de plugin (vaak is een update al beschikbaar). Niet beschikbaar? Zoek een alternatief op WordPress.org plugins, of bouw de functionaliteit zelf in een korte snippet.

Stap 5: opnieuw testen op staging. Voordat je de vervanger live activeert, eerst op staging.

Wanneer rollback de juiste keuze is

Niet elke fout is direct te repareren. Rollback naar de oude PHP-versie is verstandig als:

• De foutmelding wijst op meerdere plugins tegelijk
• Het thema zelf incompatibel is en je geen tijd hebt voor een vervanging
• De site een webshop is met live bestellingen
• Je geen FTP-toegang hebt op het moment van de fout

Een rollback geeft je adempauze om op staging rustig de oorzaak te onderzoeken. Verbeteren boven herbouwen geldt ook hier: liever een week extra op PHP 7.4 met een paar updates voorbereiden, dan halsoverkop een upgrade doordrukken die de site een dag offline trekt.

Wat ik bij dit soort werk doe

Werkwijze als ik een PHP-upgrade voor een klant uitvoer:

1. Inventarisatie van PHP-versie, plugins, thema en custom code
2. Staging-omgeving opzetten (vaak één klik bij Hostinger of SiteGround)
3. PHP Compatibility Checker draaien en de uitkomsten doorlopen
4. Probleemplugins updaten of vervangen
5. Staging-tests op homepage, admin, formulieren en checkout
6. Productie-switch op een rustig moment in de week
7. Eerste dag actieve monitoring

Voor onderhoudswerk reken ik €70 per uur. Voor migratie- en serverwerk €95 per uur. Een PHP-upgrade valt vaak op de grens: standaard upgrade is onderhoud, upgrade met meerdere incompatibele plugins of een custom thema valt onder migratie-tarief. Ik benoem dat vooraf in de offerte.

Bij mij heb je direct contact met degene die het werk uitvoert. Geen bureau-tarieven en geen wachten op een terugkoppeling van iemand die het werk niet kent.

Heb je een site die hapert na een PHP-upgrade, of wil je vooraf weten of jouw site PHP 8 aankan? Stuur me je URL en de huidige PHP-versie. Meer artikelen over migratie-werk staan in de categorie website migratie. Voor de scope van mijn werk zie je terug op diensten.