Het klantportaal draait al jaren zonder klachten. Dan komt er een kritiek lek in PHP, de hostingpartij belt, en blijkt dat het portaal op PHP 7.4 draait, een versie die al lang geen updates meer krijgt. "Dan upgraden we toch," zegt iemand. Een dag later staat de testomgeving vol foutmeldingen.
Een PHP-upgrade van 7.4 of 8.1 naar 8.4 doe je in vijf stappen: vastleggen wat er draait, een doelversie kiezen, de code laten scannen en herschrijven, testen tegen het huidige gedrag en gefaseerd overstappen. Het meeste werk zit meestal niet in PHP zelf, maar in het framework en de pakketten die erop leunen.
Waarom PHP upgraden nu niet meer kan wachten
Het PHP-project onderhoudt op dit moment vier versies. Volgens het overzicht van ondersteunde versies op php.net krijgt PHP 8.2 tot 31 december 2026 beveiligingsupdates, PHP 8.3 tot eind 2027, PHP 8.4 tot eind 2028 en PHP 8.5 tot eind 2029. Alles daarvoor, dus ook 7.4, 8.0 en 8.1, krijgt van het project geen enkele fix meer.
Wat dat betekent, bleek op 21 oktober. Voor twee kritieke lekken kwamen er updates voor 8.2 tot en met 8.5. Voor 7.4, 8.0 en 8.1 kwamen er alleen minimale broncodepatches voor wie PHP zelf compileert, en voor nog oudere versies niets van het project zelf. In ons blog over de PHP-kwetsbaarheid van oktober lees je wat je in zo'n geval direct doet.
Je bent niet de enige met een oude versie. Van de websites die PHP gebruiken, draait 27,0 procent nog op PHP 7 en 7,7 procent op PHP 5, volgens de metingen van W3Techs van oktober 2026. Voor applicaties achter een inlog, zoals portalen en backoffice-systemen, bestaan zulke cijfers niet, maar de oorzaak is dezelfde: zolang alles werkt, staat upgraden onderaan de lijst.
Wat er verandert tussen PHP 7 en PHP 8.4
De grootste stap is die van 7.4 naar 8.0. Daar verdwenen dingen waar oudere code nog op leunt:
- De functies
each()encreate_function()bestaan niet meer. Code die ze aanroept, stopt met een fatale fout. - Tekens uit een tekst halen met accolades, zoals
$tekst{0}, werkt niet meer. Dat moet$tekst[0]zijn. 0 == "abc"is nufalse, waar het vroegertruewas. Validaties die op zo'n losse vergelijking rekenen, gedragen zich ineens anders, zonder foutmelding.- Een constante die niet bestaat, geeft nu een fout in plaats van een waarschuwing.
- PDO, de standaardmanier om met een database te praten, gooit nu standaard een exceptie bij een databasefout in plaats van stil
falseterug te geven.
Na 8.0 gaat het geleidelijker. PHP 8.1 keurt null af als argument voor ingebouwde functies die dat niet verwachten, 8.2 keurt eigenschappen af die je onderweg aan een object toevoegt zonder ze te declareren, en 8.4 keurt parameters af die stilzwijgend null mogen zijn. Zulke afkeuringen geven nu een melding en worden in een latere versie een fout. Wie van 8.1 komt, heeft het zwaarste werk dus al gehad.
Het framework gaat bijna altijd mee. Een oude versie van Laravel, Symfony of een WordPress-plugin draait vaak niet op PHP 8, en een frameworkupgrade heeft zijn eigen lijst wijzigingen. In de praktijk is dat vaak het grootste deel van het werk.
PHP upgraden in vijf stappen
- Leg vast wat er draait.
php -vgeeft de versie,php -mde geïnstalleerde extensies. Bewaarcomposer.jsonencomposer.lock, noteer de frameworkversie en vergeet de cronjobs en scripts op de opdrachtregel niet: die draaien soms op een andere PHP-versie dan de website. - Kies de doelversie. PHP 8.4 is voor de meeste applicaties de veilige keuze. Kan alles al op 8.5, dan heb je een jaar langer updates. Met
composer why-not php 8.4zie je welke pakketten de overstap tegenhouden. - Laat tools het eerste werk doen. PHPCompatibility, een set regels voor PHP_CodeSniffer, wijst code aan die niet meer werkt. PHPStan vindt typefouten. Rector herschrijft veel oude patronen automatisch. Behandel elke wijziging van Rector als gewone code: laten reviewen en testen.
- Test tegen het huidige gedrag. Oude applicaties hebben vaak weinig tests. Schrijf dan eerst tests die vastleggen wat de belangrijkste processen nu doen, zoals inloggen, een order plaatsen of een export draaien, en upgrade pas daarna.
- Stap gefaseerd over. Zet de nieuwe versie eerst in een testomgeving met realistische data, dan in acceptatie en dan in productie. Houd de oude server of het oude containerimage klaar, zodat je binnen minuten terug kunt.
Die vierde stap is waar het meestal misgaat. Bij legacy-modernisering leggen wij de regels uit het oude systeem eerst vast en bewijzen we daarna met geautomatiseerde tests tegen het oude gedrag dat het nieuwe systeem doet wat het oude deed. Bij een PHP-upgrade werkt dat precies zo.
Upgraden of vervangen?
Niet elke applicatie is een upgrade waard. Als het framework al jaren niet meer onderhouden wordt, als niemand nog weet wat grote delen van de code doen, of als je bij de upgrade toch de helft moet herschrijven, dan is de PHP-versie het kleinste probleem. Hoe je zo'n systeem herkent, lees je in ons blog over legacy systemen.
Vervangen hoeft dan niet in één keer. Wij migreren component voor component, zodat oud en nieuw naast elkaar draaien en elke fase teruggedraaid kan worden. De oude applicatie kan in die tijd op een ondersteunde PHP-versie gezet worden, zodat hij veilig blijft tot het laatste onderdeel over is.
Zo blijf je bij na de upgrade
Er komt elk jaar eind november of begin december een nieuwe PHP-versie uit, en elke versie krijgt ongeveer vier jaar updates: twee jaar volledige ondersteuning en twee jaar alleen beveiligingsfixes. PHP 8.4 kwam in november 2024 en krijgt updates tot eind 2028. Wie dat ritme in de planning zet, hoeft nooit meer drie versies tegelijk in te halen.
Twee gewoontes maken de volgende upgrade klein. Werk de pakketten in Composer elke maand bij, dan loopt je code nooit ver achter. En laat je testpipeline ook op de volgende PHP-versie draaien, zodat je ziet wat er breekt voordat je moet overstappen.
Veelgestelde vragen
Kan ik niet gewoon de PHP-versie op de server omzetten?
Bij een applicatie op 8.2 of 8.3 lukt dat vaak, na een goede testronde. Bij 7.4 of ouder gaat het bijna altijd mis, en vaak op pagina's die je niet meteen bekijkt. Zet de nieuwe versie daarom eerst in een testomgeving.
Welke PHP-versie kies ik?
PHP 8.4 als je framework en pakketten het ondersteunen, PHP 8.5 als alles daar al klaar voor is. Kies geen 8.2 meer: die krijgt na 31 december 2026 geen updates.
Hoe lang duurt een PHP-upgrade?
Dat hangt af van de omvang van de code, het aantal tests, de leeftijd van het framework en het aantal pakketten. Een recente applicatie op 8.1 met goede tests is een overzichtelijke klus. Een applicatie op 7.4 met een oud framework en weinig tests is een project. De eerste twee stappen geven je een betrouwbare inschatting.
Moet ik eerst naar PHP 8.0 en dan stap voor stap verder?
Nee, je hoeft niet elke tussenversie in productie te zetten. PHPCompatibility en Rector kunnen direct tegen 8.4 controleren. Lees wel de migratie-opmerkingen van elke versie ertussen, want de wijzigingen tellen op.
Draait er bij jou een applicatie op PHP 7 of 8.1 en weet je niet hoe groot de stap is? Neem contact met ons op voor een kort gesprek over je situatie. Je krijgt binnen 24 uur antwoord.
