Wat gebeurt er als ik gewoon op PHP 8.1 blijf?

Technisch blijft de site werken, vaak nog jarenlang. Maar er komen geen security-patches meer voor PHP 8.1 sinds december 2025. Een lek dat in de toekomst wordt ontdekt, blijft openstaan. Hostingproviders gaan in 2026 en 2027 forced-upgrades doen, en dan kan een onaangekondigde switch alsnog dingen breken zonder dat jij erbij bent.

Kan ik direct van PHP 7.4 naar 8.3?

Ja, technisch kan dat. Maar de kans op problemen is groter dan een tussenstap via 8.0 of 8.1. Tussen PHP 7.4 en 8.0 zit een grote breuk (strictere type-juggling, weggevallen functies). Voor een grote sprong is testen op staging extra belangrijk, en is een degelijke compatibility-scan vooraf bijna verplicht.

Hoe weet ik welke plugins niet PHP 8.3-compatible zijn?

PHP Compatibility Checker scant op code-niveau. Daarnaast: kijk in plugin-changelogs en in de "Tested up to PHP" indicator in de WordPress.org plugin-listings. Plugins die officieel tested zijn tegen PHP 8.3 zijn veiliger dan plugins die voor het laatst in 2022 zijn bijgewerkt. Plug-ins die al 2 jaar geen update meer hadden zijn sowieso verdacht, ongeacht PHP.

Wat is het verschil tussen "deprecated" en een echte fout?

Deprecated betekent: werkt nu nog, maar verdwijnt in een toekomstige PHP-versie. Een echte fout (fatal) breekt direct. Beide horen in je log, maar alleen fatals zijn acuut. Deprecations zijn een planning-item: oplossen binnen 6 tot 12 maanden om te voorkomen dat ze in een volgende upgrade alsnog fataal worden.

Moet ik bij elke nieuwe PHP-versie meteen upgraden?

Nee, meestal is "n-1" prima: één versie achter de laatste. Op het moment van schrijven (juni 2026) is PHP 8.5 de nieuwste, dus PHP 8.4 (of 8.3) is een veilige keuze. Wel binnen de support-window blijven en niet wachten tot je versie EOL is. Een upgrade gepland 6 maanden voor EOL is rustiger dan een upgrade onder dwang van je hoster met 2 weken voorlooptijd.

PHP versie WordPress updaten: 8.1 is EOL, wat nu

PHP versie WordPress updaten is sinds december 2025 geen optionele klus meer. PHP 8.1 is EOL en krijgt geen security-patches meer. Een ongedichte kwetsbaarheid in PHP 8.1 blijft openstaan, ongeacht hoe goed je WordPress, plugins en thema zijn bijgewerkt.

In dit artikel beschrijf ik de aanpak die ik bij klanten gebruik. Niet “klik op de knop en hoop dat het goed gaat”, maar een stappenplan dat compatibility, staging en monitoring serieus neemt. Een PHP-upgrade is bij voorbereiding meestal een rustige klus, bij onvoorbereid een ramp.

Hosting-paneel met een keuze voor PHP 8.3 om de PHP versie van een WordPress site te updaten

PHP 8.1 is EOL sinds december 2025: wat betekent dat concreet?

End of life is officiële PHP-taal voor: deze versie wordt niet meer ondersteund. Per 31 december 2025 zijn de PHP-maintainers gestopt met het uitbrengen van security-updates voor PHP 8.1. Wat ervoor zorgt dat:

nieuwe kwetsbaarheden niet meer worden gedicht
hostingproviders gaan forced-upgrades plannen (meestal 4 tot 8 weken vooraf gewaarschuwd via mail)
WordPress en grote plugins gaan support voor PHP 8.1 langzaam laten vervallen

Voor de huidige PHP-versies geldt de volgende support-window, zoals te vinden op php.net/supported-versions:

PHP 8.2: actief support eindigde december 2024, security-only tot eind december 2026.
PHP 8.3: actief support tot eind december 2025, security-only tot eind december 2027.
PHP 8.4: actief support tot eind december 2026, security-only tot eind december 2028.

WordPress’ officiële aanbeveling sinds 2025 is PHP 8.3 of hoger. Voor de meeste shops en sites is dat de logische upgrade-bestemming: voldoende rijp om stabiel te zijn, voldoende ondersteund om de komende twee jaar geen issues te geven.

Hoe je een PHP versie WordPress updaten veilig doet

De aanpak in vijf stappen, in volgorde:

Back-up. Een complete site-backup plus database-export, opgeslagen op een andere locatie dan de site zelf. Geen optie, vereiste.
Compatibility-scan. Welke plugins en thema werken niet met de nieuwe PHP-versie? Welke custom code roept verouderde functies aan?
Staging-test. De PHP-upgrade eerst op een kopie van de site, niet direct op productie. Daar test je niet alleen “werkt het”, maar ook “werken de WooCommerce-checkout, het contactformulier, de zoekfunctie en de admin nog?”.
Productie-switch. Pas als staging stabiel is, schakelt de hosting-knop op productie om naar de nieuwe PHP-versie.
Monitoring 48 uur. Daarna 48 uur intensief de logs en de site in de gaten houden. De meeste problemen die uit een PHP-upgrade komen, openbaren zich in de eerste twee dagen.

Geen van deze stappen is moeilijk. Wat lastig is, is ze in deze volgorde uitvoeren in plaats van te denken “ik klik gewoon op de upgrade-knop en kijk wat er gebeurt”.

Compatibility-check: plugins, thema, custom code

De plugin PHP Compatibility Checker (van WP Engine) scant je hele site op breaking changes per PHP-versie. Installeren, kiezen voor welke PHP-versie je wil testen (bijvoorbeeld 8.3), en scannen. Resultaat: een lijst met bestanden en regelnummers die mogelijk problemen geven.

Wat de plugin niet ziet: runtime-fouten. Code die alleen onder bepaalde voorwaarden faalt (een specifieke functie die alleen draait bij een bestelling, of een hook die alleen op één specifieke pagina-template afgaat). Daarom blijft staging-testen onvervangbaar.

Een tweede check: kijk in WordPress.org plugin-listings naar de “Tested up to PHP” indicator. Plugins die officieel tested zijn tegen PHP 8.3 zijn safer dan plugins die voor het laatst in 2022 zijn bijgewerkt. Een plugin die al 2 jaar geen update meer heeft gehad is sowieso een vraag-teken, ongeacht PHP-versie.

Voor custom code (thema-functies, code in functions.php, kleine snippets die door de jaren zijn toegevoegd) is een handmatige review nodig. Typische PHP 8.x-breaking changes om naar te zoeken:

null doorgeven aan functies die strings verwachten (PHP 8.1+ geeft deprecated warning, 8.4+ mogelijk fatal)
dynamic properties op classes (PHP 8.2+ deprecated)
lege strings doorgeven aan trim() en consorten
each() is verdwenen sinds PHP 8.0
type-juggling rond == is strenger geworden

PHP Compatibility Checker plugin scant een WordPress site op breaking changes voor de PHP-upgrade

Eerst staging, dan productie: waarom altijd in deze volgorde

In mijn ervaring is dit de stap die het vaakst overgeslagen wordt, met het meeste risico. Een PHP-upgrade op productie kan een site direct breken: niet langzaam, niet stilzwijgend, maar volledig. De homepage geeft een witte pagina, de WooCommerce-checkout geeft een 500, en je hebt geen tijd om in alle rust de oorzaak te zoeken.

Op staging:

Switch PHP naar de nieuwe versie via de hosting-knop op de staging-omgeving
Doorloop een functionele test-checklist: homepage, hoofdpagina’s, contactformulier, WooCommerce add-to-cart, checkout, account-pagina, admin-dashboard, plugin-instellingen
Bekijk debug.log voor warnings en fatals
Test edge cases: een password-reset, een nieuwe gebruiker registreren, een upload doen, een PDF-factuur genereren

Dit duurt voor een gemiddelde site ongeveer 30 tot 60 minuten als je weet wat je test. Geen complete regressietest, maar wel de kritieke paden.

Pas als staging stabiel is en debug.log schoon is, switch je productie. Verbeteren boven herbouwen heet dat hier: de bestaande site behouden, de fundering eronder verstevigen, niet opnieuw beginnen.

Wat je 48 uur na de switch monitoort

De eerste 48 uur na een PHP-upgrade is het moment waarop de meeste problemen verschijnen. Niet omdat de upgrade verkeerd ging, maar omdat een specifieke combinatie van plugin + actie + data alleen onder echte productieconditioneringen optreedt.

Wat ik dan in de gaten houd:

/wp-content/debug.log: elke fatal of warning die hier verschijnt en niet eerder bestond is een gevolg van de upgrade
Server-error-log: 500-fouten of memory-errors die niet eerder voorkwamen
Slow-query-log: sommige PHP-versies veranderen query-execution; trage queries die er voorheen niet waren kunnen verschijnen
WooCommerce-orders: lukt elke order zonder vastlopen?
Mailflow: komen orderbevestigingen, contactformulier-mails, password-resets allemaal aan?
Gebruikersmeldingen: krijg je signalen via klantcontact dat iets niet werkt?

Voor een gemiddelde site is na 48 uur het beeld helder. Alles wat dan stabiel draait, blijft meestal stabiel. Wat er in die periode misgaat, is meestal binnen één tot drie uur werk te fixen (een verouderde plugin vervangen, een functie-call aanpassen, één custom-snippet refactoren).

Veelvoorkomende problemen na een PHP-upgrade

Een paar klassiekers die ik in praktijk veel zie:

“Deprecated: Constant XXX is deprecated.” Een functie of constante is officieel deprecated, maar werkt nog. Voor nu logging-only, op een toekomstige PHP-versie wordt het een fatal. Plan om dit binnen 6 tot 12 maanden op te lossen.

“Constant ABC already defined.” Twee plugins definiëren dezelfde constante. Soms tolerant in oudere PHP, strenger in nieuwere. Oplossing: één van de twee plugins aanpassen of vervangen.

null waardes naar string-functies. PHP 8.1+ klaagt over strlen(null). Veel oude code rekent erop dat dit gewoon 0 retourneert. Soms een fatal, soms een deprecation. Vereist een refactor van de aanroepende code.

Dynamic properties op classes. PHP 8.2 marked dit als deprecated, PHP 9.0 maakt het naar verwachting een fatal. Veel oudere plugins gebruiken dit patroon. De fix is meestal de class declareren met #[AllowDynamicProperties] of de properties expliciet definiëren.

Checklist voor de PHP-switch op staging en daarna productie bij een WordPress site

Wanneer een PHP-upgrade niet kan zonder code-refactor

Niet elke site kan zomaar door. Soms loop je tegen een muur waarvan de fix duur is. Een paar scenario’s:

Een verouderde custom plugin. Geschreven door een ex-developer die niet meer beschikbaar is. Werkt op PHP 7.4 of 8.0, breekt op 8.3. De keuze: opnieuw schrijven, vervangen door een alternatief, of behouden op de oude PHP-versie tot vervanging.

Een paid plugin waarvan de licentie is verlopen. Werkt nog, maar krijgt geen updates meer. Bij een PHP-upgrade kan hij breken zonder dat er een fix te halen is. Licentie verlengen of vervangen.

Een legacy thema met veel functions.php-aanpassingen. Vaak in de loop der jaren ontstaan. Een PHP-upgrade dwingt soms een refactor af. Bij grote sites kan dat een dagwerk worden.

In zulke gevallen is eerlijke calculatie het belangrijkste. Een upgrade die 12 uur werk vraagt is duurder dan een hosting verhuizen naar een provider die langer PHP 8.1 ondersteunt, maar levert wel een toekomstbestendiger site op. Geen bureau-tarieven zijn hier vooral een geruststelling: een PHP-upgrade kost bij mij geen 500 tot 1500 euro zoals bureaus rekenen, maar ligt voor een gemiddelde site tussen 175 euro (vaste-prijs check) en 4 tot 8 uur regulier werk als er complicaties zijn.

Het principe geldt overigens stack-breed. Laravel 11 vereist PHP 8.2+, Drupal 11 vraagt PHP 8.3+, Joomla 5 werkt op PHP 8.1 tot 8.5. Een PHP-versie-keuze is een platformvraag, niet alleen een WordPress-vraag. Wie meerdere apps op één server draait moet de upgrade-beslissing in samenhang nemen.

Voor doorlopend WordPress onderhoud inclusief PHP-upgrade-tracking is dit een van de structurele aandachtspunten die ik in een onderhoudscontract opneem. Niet één keer per drie jaar paniek, maar een geleidelijke planning waar elke versie-stap ruim van tevoren wordt getest.