Veel sites hebben PHP2Shell deze week opgelost door PHP 8.2 bij te werken naar 8.2.35. Dat was de juiste keuze: het is een gepatchte release en het kostte minuten. Het is ook een keuze voor de korte termijn. PHP 8.2 bereikt op 31 december 2026 het einde van zijn beveiligingsondersteuning. Na die datum krijgt de reeks niets meer, hoe de volgende kwetsbaarheid er ook uitziet, en elke site die er nog op draait, zit precies waar de PHP 7.4- en 8.1-sites zich op 21 oktober bevonden: geen release, geen pakket, alleen een upgrade.
Wat er verandert op 1 januari 2027
Niets zichtbaars. Sites op 8.2 blijven draaien. Wat verandert, is dat het PHP-project stopt met fixes voor de reeks. Linux-distributies met lange ondersteuningscycli porteren misschien nog een tijd fixes terug voor hun eigen pakketten, maar dat hangt af van de distributie en helpt sites op hostingpanelen met upstream-builds niet.
Het huidige ondersteuningsschema van PHP, met data aan het jaareinde:
| Reeks | Actieve ondersteuning tot | Beveiligingsfixes tot |
|---|---|---|
| PHP 8.2 | 31 december 2024 | 31 december 2026 |
| PHP 8.3 | 31 december 2025 | 31 december 2027 |
| PHP 8.4 | 31 december 2026 | 31 december 2028 |
| PHP 8.5 | 31 december 2027 | 31 december 2029 |
Naar welke versie je gaat
- PHP 8.3 is de kleinste stap vanaf 8.2 en koopt een vol jaar. De meeste WordPress-plugins, thema's en Composer-packages die überhaupt worden onderhouden, ondersteunen deze versie. Kies hiervoor als je de overstap met het laagste risico wilt en de oefening eind 2027 wilt herhalen.
- PHP 8.4 koopt twee jaar en is de betere keuze als je afhankelijkheden al ondersteuning opgeven. De opvallende wijziging voor maatwerkcode is dat impliciet nullable parameters (
string $x = null) deprecated zijn; een snelle zoekopdracht in je codebase laat zien hoeveel dat je raakt. - PHP 8.5 is de nieuwste reeks. Het is een redelijk doel voor nieuwe applicaties; wacht bij bestaande sites tot het ecosysteem erop is ingehaald.
Waarom nu en niet in december
Drie redenen.
- Rust wint van haast. Een upgrade in een gepland venster, met een stagingkopie en tijd om te repareren wat breekt, kost minder dan een upgrade tijdens het volgende advies, met een blootgestelde site in de tussentijd.
- Wachtrijen bij hosting. Als de volgende noodsituatie zich aandient, lopen de supportwachtrijen vol en zijn onderhoudsvensters moeilijk te krijgen. In november niet.
- Afhankelijkheden bewegen traag. Blokkeert een plugin of package de overstap, dan wil je dat ontdekken terwijl je tijd hebt om hem te vervangen, niet terwijl er een exploit rondgaat.
Hoe de overstap eruitziet
Voor een WordPress-site op shared hosting is de overstap vaak één wijziging in de PHP-keuze, gevolgd door een controle van de belangrijkste pagina's, het beheer en de formulieren. Zorg voor een back-up en de mogelijkheid om het eerste uur terug te schakelen. De handleiding voor de versiecheck laat zien waar je het resultaat bevestigt.
Voor een maatwerk- of Laravel-applicatie zit het werk in afhankelijkheden en serverconfiguratie; onze Laravel-checklist geldt ook voor de overstap van 8.2 naar 8.3 of 8.4, met minder deprecations om af te handelen.
In beide gevallen zijn de stappen dezelfde als in het end-of-life-artikel: inventarisatie, compatibiliteitscontrole, staging, repareren, omschakelen, bewaken.
Een eenvoudig plan
- Deze week: noteer de PHP-versie van elke site die je bezit. Alles op 8.2 gaat op de lijst.
- November: voer voor elke site op de lijst de compatibiliteitscontrole en de stagingtest uit.
- Begin december: schakel productie om in een rustig venster, één site tegelijk.
- Na 31 december: niets draait nog op 8.2, en het volgende advies is een routine-update.
Wil je dat wij de lijst afhandelen, stuur dan de websiteadressen en hostingproviders en we komen terug met wat elke site nodig heeft.