De PHP-versie wijzigen voor je WordPress site

Je host heeft je net een mailtje gestuurd dat je PHP-versie oud is en "niet meer ondersteund wordt". Je WordPress site draait prima. En je wil upgraden zonder morgen wakker te worden met een wit scherm, een kapotte checkout of een berg fatal errors in de logs. Dit artikel is het veilige pad van "mijn site draait op PHP 7.4" (of 8.0, of 8.1) naar een moderne, ondersteunde PHP-versie. Met een plugin-compatibiliteitsaudit, de exacte klikpaden voor de twee hostingpanelen die je waarschijnlijk gebruikt, de CLI-versus-webserver-valkuil waar WP-CLI-gebruikers in trappen, en de rollback-procedure voor als het toch misgaat.

Het artikel gaat ervan uit dat je nog geen developer-grade staging-omgeving hebt. Heb je die wel, dan kun je meteen door naar de compatibiliteitscheck en de upgrade via je bestaande staging-flow draaien. Heb je die nog niet, dan is de staging-stap niet optioneel. De gids over WordPress staging-omgevingen beschrijft vier manieren om er in een uurtje eentje op te tuigen.

Kort gezegd

• De doelversie in april 2026 is PHP 8.3 voor de meeste productiesites (security support tot december 2027, volledig stabiel in WordPress, brede plugin-compatibiliteit). PHP 8.4 is de betere keuze voor nieuwe sites of sites met een goed onderhouden plugin-stack. PHP 8.5 is te nieuw voor productie.
• Elke PHP-versie onder 8.2 is end-of-life en krijgt geen security-updates meer: 7.x (alle branches), 8.0 (EOL november 2023), 8.1 (EOL december 2024). Dit zijn geen acceptabele doelen, alleen startpunten waar je vanaf wil.
• Upgrade niet blind. Draai eerst een plugin/theme-compatibiliteitsscan, test op staging, zet productie om in een rustig moment van de dag, en houd de error log 24 tot 48 uur in de gaten.
• De rollback-knop bestaat. In cPanel, Plesk en bij de meeste managed hosts is de PHP-versie wisselen een kwestie van een klik. Breekt de site na de wissel, dan rol je net zo snel terug. Weten waar die terug-knop zit vóór je de upgrade-knop indrukt is de goedkoopste verzekering die er is.

Waarom je PHP-versie ertoe doet voor WordPress

Elk WordPress-request loopt door een PHP-interpreter. Als die interpreter oud is, gaan er drie dingen mis die je niet vanuit WordPress kunt oplossen.

Security. PHP-versies zonder ondersteuning krijgen geen patches meer voor nieuw ontdekte kwetsbaarheden. De PHP Supported Versions-pagina houdt per branch bij wat de active- en security-support-status is, en per april 2026 is elke PHP 7.x branch volledig end-of-life: PHP 7.4 bereikte EOL op 28 november 2022. Een EOL-branch draaien betekent dat elke nieuwe CVE voor jouw PHP-versie een permanent gat in je stack is. Je kunt het niet patchen zonder te upgraden.

Performance. PHP 8.x is aanzienlijk sneller dan PHP 7.x. Kinsta's PHP-benchmarks maten WordPress 6.1 op PHP 8.1 op ongeveer drie keer de requests per seconde van PHP 5.6, en elke 8.x minor heeft de executietijd verder teruggedrongen. De release notes van PHP 8.0 beschrijven de JIT-compiler die in die versie is toegevoegd. Het praktische effect op een drukke WordPress site is een lagere TTFB, minder CPU-gebruik en meer lucht per PHP-worker.

WordPress-compatibiliteit. Elke WordPress-versie declareert een minimum en een aanbevolen PHP-versie, en nieuwe core-features leunen soms op taalfeatures die alleen in nieuwere PHP zitten. De WordPress PHP compatibility-tabel is de bron voor die mapping. Een te oude PHP-versie draaien blokkeert uiteindelijk ook upgrades van WordPress zelf, wat op zijn beurt security-patches op de WordPress-laag blokkeert.

Welke PHP-versie WordPress aanbeveelt in 2026

De officiële WordPress requirements-pagina beveelt PHP 8.3 of hoger aan. Vanaf WordPress 6.9 staat PHP 8.4 als volledig ondersteund in de core PHP compatibility-tabel, en PHP 8.5 staat daar als beta-supported.

Hieronder wat dat in de praktijk betekent, uitgesplitst naar de PHP-versies waar een echte WordPress site op kan draaien én de versies die je als doel overweegt.

Een misverstand dat het verdient om rechtgezet te worden, want het staat in veel oudere how-to's: WordPress 6.6 heeft support voor PHP 7.0 en 7.1 laten vallen, niet WordPress 6.7. Het minimum van WordPress 6.7 is nog steeds PHP 7.2.24, en de core post uit januari 2026 waarin de volgende drop werd aangekondigd legt uit dat de volgende stap WordPress 7.0 (april 2026) is, die de vloer naar PHP 7.4 tilt. Als een tutorial zegt "WordPress 6.7 heeft PHP 7.x laten vallen", mixt die "EOL volgens PHP.net" door elkaar met "gedropt door WordPress core". Dat zijn twee verschillende events met verschillende timing.

Wat je van tevoren nodig hebt

• Een volledige backup van bestanden en database. Niet de geplande backup van gisteren. Een verse on-demand backup, vlak voor je begint, waarvan je de restore hebt getest. Een PHP-upgrade is de serverwijziging die het vaakst een wit scherm produceert, en die backup is je verzekering voor als de revert-knop alleen niet genoeg is.
• Een staging-omgeving die productie nabootst. Zelfde server, zelfde database, zelfde WordPress-versie. De staging-gids beschrijft vier methodes. Staging overslaan op een live site is hoe een kleine PHP-bump verandert in een incidentrecovery.
• Admin-toegang tot WordPress om de compatibility checker-plugin te installeren en de output te bekijken.
• Toegang tot het hostingpaneel (cPanel, Plesk) of SSH-toegang tot de server, afhankelijk van je host.
• Weten op welke PHP-versie de site nu draait. Tools, Sitediagnose in wp-admin toont het onder "Informatie, Server, PHP-versie". WP-CLI's wp --info toont het ook. Rapporteren beide hetzelfde getal, dan kijk je naar de web-SAPI-versie. Verschillen ze, zie dan de CLI-versus-FPM-sectie verderop.

Stap 1: Check je huidige PHP-versie

Voor je iets wijzigt, schrijf je de exacte PHP-versie op waar je nu op draait. Die heb je nodig voor je rollback-plan.

De twee betrouwbare bronnen zijn:

Vanuit wp-admin: ga naar Tools, Sitediagnose, Informatie, klap het Server-blok open en lees de regel PHP-versie. Dit is de PHP-versie die de webserver voor WordPress gebruikt.

Vanuit het hostingpaneel: in cPanel open je "Select PHP Version" of "MultiPHP Manager". In Plesk open je "Domains, je domein, PHP Settings". Beide tonen de huidige versie bovenin.

Vertrouw niet op een <?php phpinfo(); ?> in een los bestand tijdens deze fase, tenzij je eraan denkt het daarna meteen weer te verwijderen: de output bevat interne paden en omgevingsdetails die je niet publiek bereikbaar wil hebben op een live site.

Stap 2: Check plugin- en theme-compatibiliteit vóór je de PHP-versie aanraakt

Dit is de stap die mensen overslaan en waar ze spijt van krijgen. Een compatibiliteitsaudit kost twintig minuten en vangt de plugins die op de nieuwe PHP-versie fatal errors gaan geven ruim voordat je ze op een kapotte live site moet debuggen.

Er zijn twee tools die hiervoor de moeite waard zijn, afhankelijk van hoeveel controle je over de server hebt.

Optie A: de PHP Compatibility Checker plugin (voor site-eigenaren op shared hosting). WP Engine's PHP Compatibility Checker is een gratis WordPress-plugin die elke geinstalleerde plugin en theme scant tegen een doel-PHP-versie vanuit de WordPress-admin. Installeer 'm, kies je doelversie in het dropdown (bijvoorbeeld "PHP 8.3"), kies of je actieve of alle plugins/themes wil scannen, en draai de scan. De output is een lijst van bestanden en regelnummers met eventuele problemen.

De plugin is een oude wrapper rond de PHPCompatibility-ruleset die door de community wordt onderhouden, dus af en toe geeft hij false positives op hele nieuwe PHP-versies, totdat de ruleset bij is. Behandel de output als "dit zijn de dingen om even naar te kijken", niet als "dit is alles wat stuk gaat". Elke plugin die als error uit de scan komt, is een echt probleem; warnings zijn het checken waard maar vaak onschuldig.

Wat je met de resultaten doet:

• Errors in plugins die je actief gebruikt: kijk of er een update beschikbaar is. De meeste goed onderhouden plugins hebben inmiddels PHP 8.3/8.4 compatibility fixes uitgebracht. Is er een update, update 'm eerst en draai daarna opnieuw de scan.
• Errors in plugins die al meer dan een jaar niet zijn geupdate: vervang de plugin of gooi 'm weg. Een niet-onderhouden plugin die breekt op moderne PHP is een permanente risicofactor.
• Errors in themes: is het een commercieel theme, check dan op updates of vraag het aan de support. Gebruik je een child theme van een parent, dan zit de error mogelijk in de parent, die je niet direct moet bewerken.
• Warnings: bekijk ze, maar de meeste zijn deprecation notices over dynamic properties (PHP 8.2) of implicitly nullable parameters (PHP 8.4) die pas in PHP 9.0 fatal worden. Je kunt live met warnings; niet met errors.

Optie B: PHPCompatibility op de command line (voor developers). Heb je SSH-toegang en staan je plugins in versiebeheer, dan geeft PHPCompatibilityWP via phpcs je meer controle en schonere output dan de plugin-wrapper. Installeer het in een Composer-project, wijs het naar je wp-content/plugins en wp-content/themes directories, en draai het tegen de doelversie:

phpcs -p . --standard=PHPCompatibilityWP \
  --runtime-set testVersion 8.3 \
  --extensions=php \
  wp-content/plugins wp-content/themes

Met --runtime-set testVersion 8.3 vertel je de ruleset welke doelversie je wil checken. Je kunt ook een range opgeven zoals 7.4-8.3 om dingen te vangen die op 7.4 werken maar ergens in de 8.x-reeks breken.

Welke tool je ook gebruikt, interpreteer een clean rapport niet als "de upgrade gaat soepel". Statische analyse voert geen code uit, en een plugin die leunt op runtime type coercion of variable function calls kan nog steeds runtime falen terwijl de bestanden de scan passeren. Staging is de check die de rest vangt.

Stap 3: Test op staging

Kloon de site naar een staging-omgeving (zie de staging-gids voor de methodes) en wissel de PHP-versie op staging naar je doelversie via de stappen in de volgende sectie. Loop daarna de site door alsof je bezoeker bent:

1. Homepage laadt.
2. Een blogpost of productpagina laadt.
3. Sitezoekfunctie werkt.
4. Een formulier verstuurt (contactformulier, checkout, nieuwsbrief-inschrijving, wat de site ook daadwerkelijk gebruikt).
5. Je kunt inloggen op wp-admin.
6. Het dashboard laadt zonder errors.
7. Update-schermen voor plugins en themes zijn bereikbaar.
8. Heeft de site een WooCommerce-winkel, dan kun je een product in de mand leggen, checkout bereiken en de test-mode betaling afronden. Heeft de site een boekingsplugin, dan kun je een testboeking maken.

Na de rondgang check je de error log. In cPanel is dat "Metrics, Errors". In Plesk "Logs". Op een zelfbeheerde server is het het bestand waar je PHP-FPM pool of Apache mod_php naartoe schrijft. Nieuwe deprecation notices zijn verwacht; fatal errors, witte pagina's en 500-errors niet.

Passeert staging, ga dan naar stap 4. Faalt staging, dan heb je de naam van de plugin of het theme dat het stukmaakt, en dat is precies de informatie die de compatibility checker moest opleveren. Fix, verwijder of vervang de dader en test opnieuw.

Stap 4: Wijzig de PHP-versie in je hostingpaneel

cPanel (MultiPHP Manager en Select PHP Version)

cPanel heeft twee interfaces voor dezelfde onderliggende feature. De MultiPHP Manager-documentatie is de autoritaire referentie.

1. Log in op cPanel.
2. In de "Software"-sectie klik je op MultiPHP Manager (of op oudere cPanel-installaties op Select PHP Version).
3. Vink het checkboxje aan naast het domein waarvan je de PHP-versie wil wijzigen.
4. Kies in het dropdown "PHP Version" rechtsboven je doelversie (bijvoorbeeld ea-php83).
5. Klik Apply.

De wijziging is bij het volgende request al actief. Er is geen "save en bevestig"-stap: zodra je op Apply klikt, is de versie gewisseld. Open je site in een privevenster en check dat hij nog laadt.

Toont de site een wit scherm, een 500-error of de melding "Er is een kritieke fout op deze website opgetreden", zet dan in hetzelfde dropdown de versie terug naar de vorige waarde. De revert is een klik en gaat ook bij het volgende request in. Dit is de rollback-stap uit de intro. Voor het diagnosticeren van wat er brak voordat je opnieuw upgradet, zie de recovery-gids voor het witte scherm des doods.

Plesk

1. Log in op Plesk.
2. Open Domains, klik je domein aan, open PHP Settings.
3. Kies in de sectie "PHP support" je doelversie uit het dropdown PHP version (bijvoorbeeld PHP 8.3.x).
4. Klik OK (of Apply in nieuwere Plesk-versies).

Plesk past de wijziging toe bij het volgende request. Breekt de site, dan zet je 'm via hetzelfde dropdown weer terug.

De Plesk PHP version-documentatie beschrijft het verschil tussen per-domein en server-breed, wat in Plesk van belang is: je kunt de PHP-versie per domein zetten (het gebruikelijke geval voor WordPress) of de default voor de hele server aanpassen.

Managed hosts (Kinsta, WP Engine, SiteGround en vergelijkbaar)

Managed WordPress hosts hebben meestal een PHP-versie-dropdown per site in het hostingdashboard, los van cPanel. De klikreeks is qua vorm hetzelfde: kies de nieuwe versie, klik save, check dat de site nog laadt.

De exacte locatie verschilt per host, en de feature heeft per host een andere naam (Kinsta: "Tools, PHP engine"; WP Engine: "Utilities, PHP version"). Draait je staging-omgeving ook bij die managed host, wissel dan eerst staging, verifieer, en wissel daarna productie.

Zelfbeheerde servers (Apache mod_php, PHP-FPM pools)

Op een VPS of dedicated server die je zelf beheert, is de "wissel de PHP-versie"-stap wat je package manager en webserver-config zeggen. Er is geen universele klikreeks. De vorm van het werk is wel consistent.

Voor PHP-FPM op Debian/Ubuntu met meerdere PHP-versies uit deb.sury.org geinstalleerd: elke PHP-versie draait z'n eigen php-fpm service en z'n eigen UNIX-socket of TCP-poort. WordPress naar een nieuwe PHP-versie wisselen betekent het server block (bij nginx) of de virtual host (bij Apache met mod_proxy_fcgi) updaten zodat die naar de nieuwe socket wijst, en dan de webserver reloaden.

Voor nginx die naar een PHP-FPM-socket wijst:

location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    # was: fastcgi_pass unix:/run/php/php8.2-fpm.sock;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}

Reload nginx met sudo systemctl reload nginx. Die reload is graceful en laat requests die nog bezig zijn netjes afmaken.

Voor Apache met mod_php: mod_php zit strak gekoppeld aan het Apache-proces. PHP-versies wisselen betekent de oude module uitzetten, de nieuwe aanzetten, en Apache herstarten. Op Debian/Ubuntu:

sudo a2dismod php8.2
sudo a2enmod php8.3
sudo systemctl restart apache2

Restart, geen reload: PHP-modules wisselen gebeurt niet graceful.

Voor systemen die update-alternatives gebruiken om een default PHP-binary voor het hele systeem te kiezen:

sudo update-alternatives --config php

Kies de nieuwe versie uit het interactieve menu. Dit wijzigt alleen de CLI-default: het raakt Apache mod_php of PHP-FPM niet, die elk hun eigen PHP-versie onafhankelijk laden. Dit is de bron van de WP-CLI-valkuil in de volgende sectie.

Stap 5: De valkuil met WP-CLI en de webserver-versie

Dit is de val waar veel site-eigenaren in trappen die WP-CLI gebruiken op cPanel, Plesk of een andere multi-PHP-hostingomgeving. WP-CLI draait onder de command-line PHP-binary (/usr/bin/php of wat php in je shell ook resolvet). Je WordPress site draait onder de PHP van de webserver, wat een compleet andere binary is. Dit is dezelfde software, maar het kunnen verschillende versies op dezelfde server zijn.

In cPanel kun je de PHP-versie van een domein van 7.4 naar 8.3 wijzigen in MultiPHP Manager, en de site gaat onmiddellijk op 8.3 draaien. WP-CLI-commando's blijven intussen onder de systeem-PHP uit /usr/bin/php draaien, die nog steeds op 7.2 of zelfs 7.0 kan staan. Draai je na de upgrade wp plugin update --all, dan praat WP-CLI met de WordPress-database onder een oude PHP, en de commando's kunnen zich anders gedragen dan wanneer een browser dezelfde code triggerde. Erger nog: als je WP-CLI gebruikte om te verifieren dat de site nu op PHP 8.3 draait ("laat ik even wp php --info draaien om te checken"), check je de CLI-binary, niet de web-SAPI.

Check welke PHP-versie WP-CLI gebruikt:

wp --info

Kijk naar de regels PHP binary en PHP version in de output. Is die PHP version niet je doel, dan draait WP-CLI onder de verkeerde binary.

Fix het door WP-CLI naar de doel-PHP-binary te wijzen voor een enkel commando:

WP_CLI_PHP=/opt/cpanel/ea-php83/root/usr/bin/php wp --info

Of permanent voor je shell door de variabele in je .bashrc / .zshrc te exporteren:

export WP_CLI_PHP=/opt/cpanel/ea-php83/root/usr/bin/php

Het exacte pad hangt af van de host. In cPanel staan PHP-versies onder /opt/cpanel/ea-phpXX/root/usr/bin/php. In Plesk onder /opt/plesk/php/X.Y/bin/php. Op Debian/Ubuntu met de deb.sury.org repository onder /usr/bin/php7.4, /usr/bin/php8.3, enzovoort.

Waarom dit ertoe doet: een WP-CLI-commando dat migraties draait, plugins in bulk update of de wp_options-cache aanraakt onder de verkeerde PHP-versie kan uitkomsten produceren die afwijken van wat dezelfde code via de browser zou doen. WP-CLI en de web-SAPI op dezelfde versie houden is een kleine ingreep die een hele klasse verwarrende bugs uit de weg ruimt.

Stap 6: Verifieer na de wijziging

Zodra productie op de nieuwe PHP-versie draait, loop je dezelfde check door die je op staging deed.

1. Open de site in een privevenster. Homepage laadt, een post laadt, de sitezoekfunctie werkt.
2. Log in op wp-admin. Het dashboard laadt.
3. Tools, Sitediagnose toont de nieuwe PHP-versie onder "Informatie, Server".
4. Check de error log de eerste 24 uur. In cPanel is dat "Metrics, Errors". In Plesk "Logs". Op een zelfbeheerde server de error_log directive in je PHP-FPM pool-config.
5. Nieuwe deprecation notices zijn verwacht op een versiebump en niet urgent. Nieuwe fatal errors of "Uncaught Error"-regels zijn wel urgent, en het signaal om meteen te onderzoeken of terug te rollen.
6. Voor WooCommerce- of boekingzware sites, check dat bestellingen of boekingen nog aangemaakt en afgewerkt worden. Een PHP-upgrade hoort dat niet te raken, maar stille fouten in een scheduled action (zoals een terugkerende payment webhook) zijn het bekijken waard.

Verwachte uitkomst na stap 3 (Sitediagnose controleren):

Sitediagnose toont onder Tools, Informatie de regel PHP-versie: 8.3.x (of welke versie je ook als doel koos). Het Server-blok toont de bijbehorende waardes voor PHP-extensies, memory limit en execution time zoals je host die blootstelt.

Stap 7: Terugrollen als er iets fout gaat

Tref je fatal errors of ziet de site er verkeerd uit na de upgrade, rol dan eerst terug en debug daarna. De rollback is hetzelfde dropdown waarmee je de upgrade deed, maar dan in omgekeerde richting.

In cPanel: MultiPHP Manager, kies de vorige versie (bijvoorbeeld ea-php74 als je daar vandaan kwam), klik Apply. De site draait bij het volgende request weer op de oude PHP.

In Plesk: Domains, je domein, PHP Settings, kies in het dropdown de vorige versie, klik OK.

Bij managed hosts: het dashboard laat je meestal met een klik terugrollen.

Op zelfbeheerde servers: draai je nginx- of Apache-wijziging terug, reload de webserver, verifieer.

Helpt de rollback niet om de site te herstellen (zelden, maar mogelijk als de upgrade ook een mislukte plugin-migratie heeft getriggerd), zet dan de backup terug die je aan het begin hebt gemaakt. Het recovery-pad is hetzelfde als bij elk ander wit-scherm-des-doods-incident: breng de site terug naar een werkende staat, en analyseer het verschil daarna in een staging-omgeving waar je niet onder druk staat.

Ben je teruggerold, lees dan de error log. Bijna elke mislukte PHP-upgrade die ik heb gezien gaat terug naar een of twee specifieke plugins of naar een zelfgeschreven snippet in functions.php. De boosdoener in een staging-omgeving identificeren, fixen of vervangen, en de upgrade opnieuw draaien is het normale recovery-pad.

Veelvoorkomende fouten en hoe je ze leest

"Uncaught Error: Call to undefined function create_function()". create_function() is in PHP 8.0 verwijderd. Een plugin of theme die 'm nog aanroept moet worden geupdate of vervangen. Dit is de meest voorkomende PHP 7-naar-8 upgrade-fout en die is al jaren fixbaar, maar niet-onderhouden plugins slepen de oude code nog mee.

"Deprecated: Creation of dynamic property ...". PHP 8.2 heeft dynamic properties deprecated: een property zetten op een class die hem niet declareert geeft nu een deprecation notice. WordPress core is hier prima in orde (de #[AllowDynamicProperties]-attribute is toegevoegd, getracked in Trac #56034). Niet-onderhouden plugin-code produceert deze notices in de log. Ze zijn niet fatal in PHP 8.2, 8.3 of 8.4, maar wel in PHP 9.0, dus behandel ze als signaal dat je die plugin moet updaten.

"Deprecated: ... implicit conversion from nullable type". PHP 8.4 heeft implicitly nullable parameters deprecated: function foo(string $x = null) geeft nu een deprecation notice. De fix is function foo(?string $x = null). WordPress core trackt dit in Trac #60786. Third-party plugins zijn ongelijk, dus verwacht een aantal van deze in je log na een upgrade naar 8.4. Nog niet fatal; wel in PHP 9.0.

500 Internal Server Error zonder PHP-error in de log. Dit wijst meestal op een verkeerd geconfigureerde mod_php, PHP-FPM of het hostingpaneel zelf, niet op je WordPress-code. Zie de 500 Internal Server Error-gids voor de server-level diagnose.

"Maximum execution time of N seconds exceeded" direct na de upgrade. Een trage plugin die al traag was, wordt nu opgepikt door de PHP error reporter zodra je WP_DEBUG_LOG aanzet. De fix staat in het executietijd-artikel, niet in de PHP-versie.

Wanneer je hulp moet inschakelen

Ben je teruggerold en krijg je de site nog steeds niet stabiel, verzamel dan deze info voor je om hulp vraagt:

• De exacte WordPress-versie (uit wp-admin of wp-includes/version.php).
• De exacte PHP-versie van voor en na de upgrade-poging.
• Het hostingpaneel dat je gebruikt (cPanel, Plesk, Kinsta, WP Engine, iets anders).
• De eerste 30 regels van de error log vanaf het moment dat de site brak.
• De naam van elke plugin of theme die in de stack traces van de error log opduikt.
• Of de compatibility checker diezelfde plugin of theme vooraf al flagde.
• De exacte tekst van elke error op het scherm, of een screenshot.
• Wat je al hebt geprobeerd (naar welke PHP-versie je bent teruggerold, of plugin-deactivatie iets veranderde).

Stuur dat naar de support van je host of naar een WordPress-developer. "De site is stuk na een PHP-upgrade" is niet diagnosticeerbaar; de lijst hierboven wel.

De volgende upgrade inplannen

Is de upgrade eenmaal gedaan en stabiel, zet dan alvast een kalender-reminder voor de volgende. De PHP supported versions-pagina wordt bijgewerkt als een branch van active support naar security-only naar EOL opschuift. Een vuistregel die voor mij goed werkt: zodra je huidige PHP-versie het laatste jaar van security support ingaat, plan je de volgende upgrade. Je probeert niet op de bleeding edge te zitten; je probeert nooit op een EOL-versie te zitten.

Voor april 2026 betekent dat: PHP 8.2-sites moeten een move naar 8.3 of 8.4 plannen ruim voor december 2026. PHP 8.3-sites hebben langer de tijd, tot december 2027. PHP 8.4-sites hebben tot december 2028 en zitten comfortabel up-to-date. Zit je vandaag nog op 7.4, 8.0 of 8.1, dan is de upgrade achterstallig en dit artikel is het pad vooruit.