Op 31 december 2026 is PHP 8.2 end of life: na die dag komen er geen beveiligingsupdates meer voor die versie. Niet elke Magento-shop lost dat op met “even PHP upgraden”. Op de nieuwste Magento-versies raakt de deadline je niet. Op 2.4.7 is PHP upgraden een eerste stap, geen oplossing. En op 2.4.6 is PHP niet eens je grootste probleem.
Wat er op 31 december verandert
Na 31 december 2026 komt er geen patch meer voor nieuwe lekken in PHP 8.2 zelf. De actieve support, waarin ook bugs werden gefixt, stopte al eind 2024. Nu valt ook het laatste vangnet weg: security support.
Dat is een ander soort risico dan een lek in Magento. Een Magento-patch lost een probleem op in de code van je shop. Een PHP-lek zit in de laag daaronder, de taal waarin die code draait. Dat bleek op 21 oktober dit jaar bij PHP2Shell, een zero-day in PHP zelf. Niemand zag die aankomen, en een Magento-patch had niets opgelost: alleen een update van PHP zelf hielp.
Het verschil met 31 december is dat die datum al jaren vaststaat. Je weet nu al dat er na die dag geen fix meer komt, voor welk lek dan ook in PHP 8.2. Dat is geen incident dat je oplost zodra het zich voordoet, maar een deadline waar je nu al voor kunt plannen.
Welke PHP-versie hoort bij welke Magento-versie
PHP-versies en Magento-versies hebben allebei hun eigen support-einddatum, en die twee klokken lopen niet gelijk. Een Magento-versie die zelf nog support heeft, kan toch op een PHP-versie draaien die al is uitgefaseerd. En omgekeerd: PHP upgraden lost niets op als de Magento-versie daaronder zelf aan het einde van zijn support zit.
| Magento-versie | PHP-versie | Support Magento-versie tot |
|---|---|---|
| Open Source 2.4.6 | 8.1 / 8.2 | verlopen (11-08-2026) |
| 2.4.7 | 8.2 / 8.3 | 31-05-2027 |
| 2.4.8 | 8.3 / 8.4 | 31-05-2028 |
| 2.4.9 | 8.5 (8.4 alleen tijdens upgrade) | 31-05-2029 |
PHP zelf kent een vergelijkbare reeks: 8.3 krijgt security support tot 31-12-2027, 8.4 tot 31-12-2028, 8.5 tot 31-12-2029. Welke PHP-versie je hoster daadwerkelijk aanbiedt en hoe snel die wordt gepatcht, is een aparte vraag. Zie daarvoor wat Magento hosting nodig heeft.
Wat je nu doet, per versie
Open Source 2.4.6
Hier is PHP niet je eerste probleem. Open Source 2.4.6 is zelf al over zijn reguliere support-datum heen en viel in oktober buiten de patch voor BlockStrap, het kritieke lek uit bulletin APSB26-153. Draai je nog op PHP 8.1, dan zit je sinds 31 december 2025 al zonder PHP-securityfixes. En naar 8.3 kan niet eens: 2.4.6 ondersteunt die PHP-versie niet. Je zit hier vast aan een Magento-upgrade, niet aan een PHP-upgrade.
Draai je Adobe Commerce 2.4.6, dan heb je verlengde support van Adobe tot 31 augustus 2027. Maar ook daar is PHP 8.2 het plafond, dus vanaf januari draai je een ondersteunde Magento-versie op een PHP-versie zonder securityfixes. Lees wat er dit najaar aan patches is uitgekomen voor de volledige context.
2.4.7 op PHP 8.2
Upgraden naar PHP 8.3 is hier technisch mogelijk en lost het PHP-probleem op. Maar 2.4.7 zelf loopt tot 31 mei 2027. Alleen de PHP-versie oplossen is een pleister: vijf maanden na de PHP-deadline sta je weer voor een support-einddatum, nu van Magento zelf. Plan de PHP-upgrade dus niet los, maar als eerste stap richting een volgende Magento-versie.
2.4.8
Deze versie draait niet op PHP 8.2, dus de deadline raakt je productieshop niet. Check wel of al je omgevingen meegingen: een staging-omgeving of losse cronserver die na de upgrade is vergeten, staat soms nog op een oude PHP-versie.
2.4.9
Op 2.4.9 draai je al op PHP 8.5, met 8.4 alleen toegestaan tijdens het upgradetraject zelf. Hier is er niets te doen behalve controleren dat productie niet per ongeluk op die tussenversie is blijven staan.
Mage-OS
Mage-OS 3.x draait op PHP 8.3, 8.4 en 8.5, dus PHP 8.2 speelt hier niet. De valkuil zit ergens anders: Mage-OS patcht alleen de nieuwste releasebranch. Sta je een paar releases achter, dan mis je securityfixes, op welke PHP-versie je ook draait.
Eerst de extensies checken
Of een PHP-upgrade soepel gaat, hangt vooral af van de extensies in je shop. Niet elke extensie ondersteunt elke PHP-versie, en dat geldt ook voor Hyvä-modules en eigen maatwerkcode.
Begin met Composer: composer why-not php 8.3 laat in één keer zien welke packages de nieuwe PHP-versie tegenhouden. Dat werkt alleen voor extensies die hun PHP-eisen netjes opgeven; staat er niets, vraag het dan na bij de leverancier. Voor je eigen code en voor extensies zonder duidelijke eisen helpt statische analyse als volgende filter: PHPCompatibility, een regelset voor PHP_CodeSniffer, scant je code op constructies die in de nieuwe PHP-versie zijn verwijderd of veranderd. Dat filtert het grootste deel van de problemen eruit voordat je ook maar iets hebt getest.
Wat die scan niet vangt, vang je op staging. Draai de shop daar echt op de nieuwe PHP-versie en loop de belangrijkste flows door: bestellen, betalen, inloggen, en elke koppeling met een extern systeem. Twijfel je of de code en extensies van je shop in goede staat zijn, los van deze specifieke upgrade, dan is dat een vraag voor een code review.
Het plan tot 31 december
Vanaf nu tot 31 december heb je ongeveer acht weken. Begin met inventariseren: welke Magento-versie draai je, op welke PHP-versie, en welke extensies staan erop. De Magento-versie zie je met bin/magento --version, de PHP-versie met php -v op de server of in het dashboard van je hoster. Daarna check je de compatibiliteit van die extensies met de doel-PHP-versie, voordat je iets installeert.
Zodra dat duidelijk is, zet je de upgrade op staging en test je de belangrijkste flows. Pas als dat goed gaat, gaat de wijziging live.
Houd rekening met Black Friday en de drukte van december. Een PHP- of Magento-upgrade vlak voor je drukste verkoopdagen is geen moment om risico’s te nemen. Plan de wijziging liever vóór Black Friday. Wat je in de weken ervoor nog wel en niet meer doet, staat in je Magento-webshop klaar voor Black Friday.
Lukt dat niet, bijvoorbeeld omdat je op 2.4.6 een complete Magento-upgrade voor de boeg hebt, forceer het dan niet midden in de piek. 31 december is geen klif: de shop draait gewoon door, alleen loopt het risico op met elk nieuw PHP-lek dat niet meer wordt gedicht. Plan de upgrade dan vast voor januari, en vraag je hoster nu al wat die doet als er in de tussentijd een lek als PHP2Shell opduikt.
Hoe wij het doen
Bij shops die bij ons in Magento onderhoud zitten, houden we de PHP-versie en de Magento-versie samen bij, niet los van elkaar. Een PHP-upgrade plannen we in samenhang met de volgende Magento-upgrade, en staging gaat altijd eerst over naar de nieuwe PHP-versie voordat productie volgt. Neem contact op als je wilt weten waar jouw shop precies staat.
Veelgestelde vragen
Is PHP 8.3 genoeg, of moet ik meteen naar 8.4?
Dat bepaalt je Magento-versie. Kies de nieuwste PHP-versie die jouw Magento-versie ondersteunt, want die heeft het langst support: op 2.4.7 is dat 8.3, op 2.4.8 is dat 8.4.
Ik draai Magento Open Source 2.4.6, kan ik naar PHP 8.3?
Nee. Open Source 2.4.6 ondersteunt PHP 8.3 niet, alleen 8.1 en 8.2. De enige route is een Magento-upgrade naar een versie die PHP 8.3 wel ondersteunt.
Blijft mijn shop werken na 31 december?
Ja, de shop blijft draaien. Wat stopt, zijn beveiligingsupdates voor PHP 8.2. Nieuwe lekken in die PHP-versie krijgen geen fix meer, wat het risico op misbruik vergroot naarmate de tijd verstrijkt.
Hoe weet ik of mijn extensies de nieuwe PHP-versie aankunnen?
Begin met composer why-not php 8.3 (of de versie waar je naartoe wilt): dat toont welke packages de upgrade blokkeren. Draai daarna een statische analyse, zoals PHPCompatibility voor PHP_CodeSniffer, als eerste filter. Test wat daar doorheen komt op staging, met de belangrijkste flows van je shop.