PHP 7.4, 8.0 en 8.1 zijn end of life: wat PHP2Shell betekent voor je site en hoe een upgrade werkt

Toen PHP op 21 oktober 2026 zijn noodreleases publiceerde, deed het wat het altijd doet: het repareerde de reeksen die nog worden ondersteund. PHP 8.2, 8.3, 8.4 en 8.5 kregen een release. PHP 8.1 en alles wat ouder is niet, en dat gaat ook niet gebeuren. Voor de vele sites die nog op die versies draaien, veranderde PHP2Shell een langlopend "we moeten ooit upgraden" in een beslissing die niet kan wachten. Weet je niet zeker welke versie je site gebruikt, controleer dat dan eerst; het kost een minuut.

Wat "end of life" betekent

Elke PHP-reeks krijgt ongeveer twee jaar actieve ondersteuning en daarna nog twee jaar beveiligingsfixes. Daarna is hij end of life: geen fixes meer, hoe ernstig het probleem ook is.

Voor PHP2Shell ging het PHP-team een stap verder dan gebruikelijk en publiceerde het minimale bronpatches voor 7.4, 8.0 en 8.1. Die zijn bedoeld voor wie PHP zelf compileert. Het zijn geen releases, geen pakketten, en de meeste hostingaccounts kunnen er niets mee. Sommige Linux-distributies en hostingproviders bouwen eigen teruggeporteerde pakketten; doet de jouwe dat, bevestig het dan bij hen. Zo niet, dan is er geen fix voor je reeks en is de enige echte optie een overstap naar een ondersteunde reeks.

Naar welke versie je gaat

Niet 8.2. Die is gepatcht, maar de beveiligingsondersteuning eindigt op 31 december 2026, waardoor je binnen enkele weken weer in dezelfde positie zit. De praktische doelen zijn:

• PHP 8.3 als je de kleinste stap wilt die toch tijd koopt, met beveiligingsfixes tot eind 2027. De meeste actief onderhouden WordPress-plugins en PHP-packages ondersteunen deze versie.
• PHP 8.4 als je plugins, thema en packages er al ondersteuning voor opgeven. Op de lange termijn is dit de betere keuze.

Controleer de ondersteuning voordat je beslist. In WordPress tonen de plugin- en themapagina's op wordpress.org "Vereist PHP" en de versie waarmee is getest. Voor applicaties op basis van Composer toont composer why-not php 8.4 elk package dat de overstap zou blokkeren.

Wat er meestal breekt

Een sprong van 7.4 naar 8.3 of 8.4 slaat jaren aan wijzigingen over. De meeste sites komen er met een handvol fixes doorheen, maar dit zijn de gebruikelijke verdachten:

• Striktere typen. Interne functies geven nu fouten in plaats van waarschuwingen bij verkeerde argumenttypen, en null doorgeven waar een string wordt verwacht is sinds 8.1 deprecated. Oude code die op stille conversie vertrouwde, begint te falen.
• Verwijderde functies. create_function(), each() en money_format() zijn sinds 8.0 verdwenen; de mysql_*-functies sinds 7.0. Oude thema's en maatwerkplugins gebruiken ze nog.
• Gewijzigde vergelijkingen. Sinds 8.0 is 0 == "tekst" onwaar. Code die getallen en strings losjes vergeleek, kan een andere route nemen.
• Deprecations die ruis worden. Dynamische eigenschappen op klassen en ${var}-interpolatie in strings zijn sinds 8.2 deprecated. Ze werken nog, maar vullen het foutlogboek en breken in een toekomstige release.
• Verlaten plugins en thema's. Alles wat niet is bijgewerkt voor PHP 8 is een risico. Dit is vaak het echte werk: een vervanger vinden.
• Versielimieten van frameworks. Oudere Laravel-releases ondersteunen alleen de PHP-versies die destijds bestonden. Een PHP-upgrade kan eerst een framework-upgrade betekenen, en dat is een groter project.

Zo verloopt een geplande upgrade

Dit is de volgorde die wij gebruiken, voor één WordPress-site of voor de klantsites van een bureau:

1. Inventarisatie. Welke sites, welke hosting, welke PHP-versie en SAPI, welke plugins, thema's en packages. Voor een WordPress-site brengt het tabblad Info van Sitediagnose je al een heel eind.
2. Compatibiliteitscontrole. Eerst geautomatiseerde scans: de plugin PHP Compatibility Checker of een PHPCompatibility-run voor WordPress-code, composer why-not plus PHPStan of Rector voor applicaties. Daarna een doorlezing van de maatwerkcode die de scanners niet kunnen beoordelen.
3. Stagingkopie. Een kopie van de site op de doelversie van PHP, waar fouten niets kosten. De meeste hostingpanelen kunnen dit; anders zetten wij er een op.
4. Repareren en opnieuw testen. Het foutlogboek en de belangrijkste routes doorwerken: homepage, onderliggende pagina's, zoeken, inloggen, formulieren, checkout, beheerschermen, geplande taken.
5. Productie omschakelen. In een afgesproken onderhoudsvenster, met vooraf een back-up en een terugweg naar de oude versie als er iets onverwachts opduikt.
6. Bewaken. Logboeken en belangrijke pagina's een paar dagen na de omschakeling in de gaten houden, omdat sommige routes maar af en toe worden uitgevoerd.

Een patchupdate binnen dezelfde reeks, bijvoorbeeld van 8.3.30 naar 8.3.36, vraagt veel minder dan dit: installeren, de PHP-workers herstarten, de belangrijkste pagina's controleren. De checklist hierboven is voor de overstap tussen reeksen waar end-of-life-sites nu voor staan.

In de tussentijd

Heeft de upgrade een paar dagen planning nodig, dan noemt het advies van PHP zelf tussentijdse maatregelen: zet session.upload_progress.enabled=0 en herstart de workers, houd memory_limit onbeperkt, stel verstandige limieten voor de verzoekgrootte in bij de webserver en gebruik een web application firewall. Ze verkleinen de blootstelling aan de bekende aanvalspaden. Ze maken een end-of-life PHP niet veilig, en niets doet dat totdat de site op een ondersteunde versie draait.

Wil je hulp bij de inventarisatie of de upgrade zelf, stuur ons dan je websiteadres, hostingprovider en huidige PHP-versie. We bevestigen waar je staat en wat de overstap zou inhouden.