PHP 8.2 einde ondersteuning (31 dec 2026): wat nu?

PHP 8.2 bereikt het einde van de ondersteuning op 31 december 2026. Na die datum brengt het PHP-project er geen beveiligingsfixes meer voor uit. Je site blijft draaien, maar de volgende ernstige PHP-bug, zoals PHP2Shell in oktober, wordt voor 8.2 niet meer opgelost. De oplossing is overstappen naar PHP 8.4 (beveiligingsupdates tot 31 december 2028), of naar 8.3 (tot 31 december 2027) als een plugin of framework waar je van afhankelijk bent nog niet klaar is voor 8.4. Voor een WordPress-site met up-to-date plugins zijn dat meestal een paar uur testen. Oude maatwerkcode, verlaten plugins en Docker-images kosten meer tijd, dus begin in november, niet op 30 december.

Wat einde ondersteuning betekent, en wat niet

Je site stopt niet op 1 januari. PHP 8.2 blijft werken. Wat stopt, zijn de fixes van php.net, en de officiële Docker-images krijgen geen updates meer.
Het risico groeit na verloop van tijd. Elke beveiligingsbug die na 31 december in PHP wordt gevonden, blijft open op 8.2. In oktober 2026 liet PHP2Shell zien hoe snel dat telt: de aanvallen begonnen op de dag dat de fix uitkwam.
Je hoster kan je verhuizen. Veel hosters zetten sites na het einde van de ondersteuning over op een nieuwere PHP-versie, soms met weinig waarschuwing, en sommige rekenen extra om een oude versie draaiende te houden. Een gedwongen overstap op een site die nooit getest is, levert een melding over een kritieke fout op, in plaats van je website.
Linux-distributies zijn een bijzonder geval. Sommige distributies blijven hun eigen PHP 8.2-pakket patchen zolang ze de distributie zelf ondersteunen. Draait je server PHP uit de pakketten van je distributie, kijk dan in de security tracker van die distributie. Dit geldt niet voor php.net-builds, de officiële Docker-images of de meeste hostingpanelen.

PHP-versies en hun einddatums

Versie	Uitgebracht	Bugfixes tot	Beveiligingsfixes tot
PHP 8.1 en ouder	2021 of eerder	Afgelopen	Afgelopen (8.1 op 31 december 2025)
PHP 8.2	8 december 2022	Afgelopen op 31 december 2024	31 december 2026
PHP 8.3	23 november 2023	Afgelopen op 31 december 2025	31 december 2027
PHP 8.4	21 november 2024	31 december 2026	31 december 2028
PHP 8.5	20 november 2025	31 december 2027	31 december 2029

Elke PHP-versie krijgt twee jaar bugfixes en daarna twee jaar alleen beveiligingsfixes. Draai je 8.1 of ouder, dan zit je al zonder fixes: pak die upgrade als eerste aan.

Naar welke versie moet je overstappen?

PHP 8.4 voor de meeste sites. Het wordt ondersteund tot eind 2028, dus je hoeft dit volgend jaar niet te herhalen. WordPress 6.8 en nieuwer ondersteunen het.
PHP 8.3 als iets 8.4 blokkeert. Een oude plugin, een thema of een library die niet is bijgewerkt. Het levert je één jaar op, tot 31 december 2027.
PHP 8.5 als je opnieuw begint of je stack up-to-date is. WordPress ondersteunt het vanaf 6.9; Laravel 12 en 13 ondersteunen het. Veel plugins worden later op 8.5 getest dan op 8.4.

Bij Laravel horen de PHP-versie en de Laravel-versie bij elkaar. Laravel 11 draait op PHP 8.2 tot 8.4, maar de eigen beveiligingsfixes eindigden op 12 maart 2026. Laravel 12 draait op 8.2 tot 8.5, met beveiligingsfixes tot 24 februari 2027. Laravel 13 vereist PHP 8.3 of nieuwer. Een app op Laravel 10 of 11 is een goed moment om allebei te updaten.

Controleer welke PHP-versie je draait

WordPress: Gereedschap, Sitediagnose, Info, en daarna toont het onderdeel Server de PHP-versie.
Hostingpaneel: cPanel, Plesk, DirectAdmin en de meeste managed hosters tonen het onder PHP-instellingen of "Select PHP version".
Je eigen server: php -v op de opdrachtregel. De webserver kan een andere versie gebruiken dan de opdrachtregel, dus controleer ook een phpinfo()-pagina en verwijder die meteen daarna.
Docker: kijk naar de FROM-regel in je Dockerfile (bijvoorbeeld php:8.2-fpm), of draai docker run --rm your-image php -v.

Onze MigrateXtoY-gids over het einde van PHP 8.2 gaat dieper in op wat per platform kapotgaat (WordPress, WooCommerce, Magento, Laravel, Drupal) en op de tools die helpen.

Wat er kan breken bij de upgrade

De stap van 8.2 naar 8.3 of 8.4 is klein vergeleken met de sprong van PHP 7 naar 8. De meeste wijzigingen zijn nieuwe deprecation-waarschuwingen, die je logs vullen maar de site niet stilleggen. Wat een site wel breekt:

Plugins en thema's die jaren niet zijn bijgewerkt. Ze zijn de meest voorkomende oorzaak van een wit scherm of een kritieke fout na een PHP-wissel.
Verwijderde extensies. PHP 8.4 levert IMAP, OCI8, PDO_OCI en Pspell niet meer mee; ze zijn verhuisd naar PECL. Een plugin die met imap_open() een mailbox uitleest, of een app die met Oracle praat, heeft de extensie apart nodig of een vervanger.
Maatwerkcode met genegeerde waarschuwingen. Deprecations uit eerdere versies worden in latere versies fouten. Staan je logs er vol mee, los het dan nu op.
Composer-dependencies met een strikt PHP-bereik. composer why-not php 8.4 toont de pakketten die de upgrade blokkeren.

Zo upgrade je zonder downtime

Maak een back-up van bestanden en database, buiten de server opgeslagen.
Werk eerst al het andere bij: WordPress-core, plugins en thema's, of je Laravel- en Composer-pakketten. Verwijder plugins die je niet gebruikt.
Test op een kopie. De meeste hosters bieden een stagingsite. Zet de kopie op de nieuwe PHP-versie en zet foutlogging aan (WP_DEBUG_LOG in WordPress, het Laravel-log bij Laravel).
Klik door wat geld oplevert: formulieren, afrekenen, betalingen, inloggen, zoeken, geplande taken en de e-mails die je site verstuurt.
Lees het foutlog. Los fatale fouten op voor je live gaat; noteer de deprecations voor later.
Zet de live site om op een rustig moment, en laat de oude versie selecteerbaar in je hostingpaneel, zodat je snel terug kunt.
Bij Docker: wijzig de FROM-regel, bouw opnieuw met docker build --pull, controleer vóór de build of er genoeg schijfruimte vrij is, en deploy elke container opnieuw.

Gaat de site na een wissel toch kapot, dan behandelt onze checklist voor een WordPress-site die offline ging de herstelmodus en hoe je terugdraait.

Uit eigen werk: twee manieren waarop een PHP-deadline binnenkomt

Op 21 oktober patchten we het Laravel-platform van een klant tegen PHP2Shell. Het draait in Docker op PHP 8.2, op één cloudserver. Voor de update waren eerst drie fixes nodig: de officiële Docker-image had de gepatchte versie nog niet, dus bouwden we zelf de basisimage; de schijf zat voor 100% vol, dus verdubbelden we die van 15 naar 30 GB; en er stond meer open naar internet dan alleen de website, dus sloten we alle poorten behalve 80 en 443. Nog dezelfde dag draaide het platform op PHP 8.2.35. Maar 8.2.35 koopt alleen tijd: datzelfde platform heeft nu de deadline van 31 december, en een upgrade gaat makkelijker in november dan tijdens de volgende noodsituatie.

De tweede manier is schaal. Voor een Nederlands designbureau onderhouden we meer dan 50 WordPress-sites onder hun naam, sinds juli 2026 zo'n 10 uur per maand. Toen PHP2Shell werd gepubliceerd, handelden we binnen minuten op hun sites. Een einddatum is de trage versie van dezelfde klus: een lijst met sites, een deadline en een controle per site. Of je nu één site hebt of vijftig, het werk is hetzelfde: weten welke versie elke site draait, testen voordat je hoster voor je omschakelt, en een weg terug houden.

Meer over wat er in oktober gebeurde: PHP2Shell: wat je nu moet doen met je WordPress- of Laravel-site.

Wat het kost

Optie	Prijs excl. btw	Goed om te weten
Zelf doen	Je eigen tijd	Prima voor een WordPress-site met actuele plugins en een stagingkopie bij je hoster.
Je hostingbedrijf	Vaak inbegrepen	De meeste hosters zetten de versie om; weinig testen je site of lossen op wat breekt.
WDDW-strippenkaart	€910 voor 14 uur	Vooruitbetaalde uren voor de upgrade, het testen en de fixes, met uren over voor reguliere updates.
WDDW-spoedhulp	€75/uur, geen minimum	Als de hoster al heeft omgeschakeld en de site plat ligt: een senior developer begint dezelfde dag.

Wil je PHP- en pluginupdates elke maand laten afhandelen in plaats van in haast? Bekijk wat websiteonderhoud kost. Bureaus met veel klantsites lezen in WordPress-onderhoud voor bureaus hoe wij dat onder hun naam doen.

Upgrade vóór de deadline

Stuur ons je websiteadres. Een senior developer controleert welke PHP-versie erop draait, test op een kopie met PHP 8.4, lost op wat breekt en zet de live site om, met een weg terug. WordPress, WooCommerce, Laravel of Docker: we werken met de hosting die je hebt. Neem contact op → of, als de site al plat ligt, vraag spoedhulp.

Heb je een bureau? Wij upgraden de sites van je klanten onder jouw naam, onder NDA. Tot 31 december: koop 2 strippenkaarten, krijg er 1 gratis. Bekijk het bureauaanbod →

Feiten gecontroleerd op 6 november 2026. Bronnen: PHP supported versions, PHP 8.4 migration guide, WordPress PHP compatibility, Laravel support policy.

Veelgestelde vragen

Wanneer bereikt PHP 8.2 het einde van de ondersteuning?

Op 31 december 2026. De actieve ondersteuning eindigde op 31 december 2024; sindsdien kreeg PHP 8.2 alleen beveiligingsfixes, en die stoppen eind 2026.

Stopt mijn website na 31 december 2026?

Nee. PHP 8.2 blijft draaien, maar beveiligingsbugs die na die datum worden gevonden, worden er niet meer voor opgelost. Je hoster kan je site ook naar een nieuwere versie verhuizen, wat een ongetoetste site kan breken.

Moet ik upgraden naar PHP 8.3, 8.4 of 8.5?

PHP 8.4 voor de meeste sites: die krijgt beveiligingsfixes tot 31 december 2028 en WordPress 6.8 en nieuwer ondersteunen het. Kies 8.3 alleen als een plugin of library nog niet klaar is voor 8.4, en 8.5 als je hele stack up-to-date is.

Werkt WordPress op PHP 8.4?

Ja. WordPress 6.8 en nieuwer ondersteunen PHP 8.4, en 6.9 en nieuwer ondersteunen ook 8.5. Problemen komen meestal van oude plugins en thema's, dus werk die eerst bij en test op een stagingkopie.

Welke Laravel-versies draaien op PHP 8.4?

Laravel 11 en 12 draaien op PHP 8.4, en Laravel 13 vereist PHP 8.3 of nieuwer. Laravel 11 krijgt geen beveiligingsfixes meer, dus een app op Laravel 10 of 11 verhuis je het best meteen naar 12 of 13.

Hoelang duurt een PHP-upgrade?

Voor een WordPress-site met up-to-date plugins meestal een paar uur, inclusief testen. Sites met oude maatwerkcode, verlaten plugins of een Docker-opzet kosten meer tijd, dus begin ruim voor de deadline.