PHP 8.5 bij hosting: wijzigingen, compatibiliteit en veilig updaten

PHP 8.5 op de juiste manier in de hosting plaatsen

PHP 8.5 is sinds 20 november 2025 beschikbaar als stabiele minor-versie van de PHP 8-reeks. Volgens de officiële planning loopt de reguliere ondersteuning voor bugfixes en beveiliging tot en met 31 december 2027; kritieke beveiligingsupdates zijn gepland tot en met 31 december 2029. Daarmee is de versie in principe geschikt voor productieve hostingomgevingen, maar de beschikbaarheid ervan betekent nog niet automatisch dat een overstap zonder risico is.

Voor CMS-websites en webwinkels is PHP alleen niet bepalend voor de geschiktheid. Ook de geïnstalleerde CMS-versie, het thema, de plug-ins, de webwinkelmodules en de gekoppelde diensten moeten de gekozen runtime ondersteunen. Een goed onderhouden applicatie kan daarom een goede kandidaat zijn voor een geplande overstap; bij niet-onderhouden uitbreidingen is in eerste instantie de status van de fabrikant doorslaggevend.

Bij eigen ontwikkelingen heeft de update bovendien gevolgen voor afhankelijkheden en eigen code. PHP 8.5 brengt wijzigingen mee in de taal, de standaardbibliotheek en het gedrag. In de officiële migratiedocumentatie wordt aanbevolen om applicaties te testen voordat de productieomgeving wordt omgeschakeld. Dit geldt ook als de website bij een vluchtige blik in eerste instantie foutloos lijkt.

Nieuwe PHP-versies kunnen op de lange termijn de onderhoudbaarheid verbeteren, maar zijn geen vervanging voor updates van de applicatie of een beveiligingsbeleid. Evenmin houdt de versiewisseling een algemene prestatiegarantie in. Responstijden zijn onder andere afhankelijk van de applicatiecode, databasetoegang, caching, geactiveerde extensies en de concrete resources van de hostingomgeving.

Wanneer is een PHP-update zinvol?

Wie al PHP 8.4 gebruikt en een regelmatig bijgewerkte applicatie beheert, kan PHP 8.5 gericht testen in een testomgeving. Deze overstap richt zich op de wijzigingen van 8.4 naar 8.5. Een vaste datum na een succesvolle test biedt daarbij meer zekerheid dan een spontane overstap in de productieve omgeving.

Bij PHP 8.3, 8.2 of nog oudere versies ligt de situatie anders. In dat geval blijven alle wijzigingen uit de overgeslagen versies van kracht. Het volstaat dus niet om alleen de migratie-instructies voor PHP 8.5 te lezen: verwijderde functies, gewijzigde foutmeldingen en verouderde functies uit eerdere versiesprongen kunnen ook van invloed zijn op uitbreidingen of eigen ontwikkelingen.

Als de situatie rond plug-ins of modules onduidelijk is, is het vaak verstandiger om te wachten tot er een compatibele PHP-versie beschikbaar is die nog steeds wordt ondersteund. Dit betekent niet dat je het onderhoud moet verwaarlozen: controleer de informatie van de fabrikanten, beschikbare updates en mogelijke vervangende producten. Een webshop-uitbreiding zonder bevestigde goedkeuring mag niet alleen op basis van een goed functionerende startpagina als compatibel worden beschouwd.

Voor nieuwe eigen ontwikkelingen mag PHP 8.5 bewust worden gebruikt als Minimale versie moet worden vastgelegd als het doelplatform deze versie ondersteunt. Vervolgens moet deze instelling worden opgenomen in de Composer-configuratie, de implementatiedocumentatie en de instellingen voor commandoregelprocessen. Als dezelfde applicatie ook op oudere omgevingen moet draaien, mogen taalfuncties die uitsluitend in PHP 8.5 beschikbaar zijn, niet worden gebruikt zonder een compatibiliteitsplan.

De ondersteuningsperiode is een objectieve reden om een migratie te plannen, maar vormt geen vervanging voor compatibiliteitstests. Volgens het officiële overzicht ontvangt PHP 8.2 slechts tot 31 december 2026 beveiligingsupdates. Voor oudere versies moet de controle daarom tijdig beginnen, vooral als er veel extensies, aangepaste interfaces of achtergrondprocessen bij betrokken zijn.

De compatibiliteit hangt af van de daadwerkelijke looptijd

Het is niet van belang welke PHP-versie lokaal tijdens het ontwikkelen is geïnstalleerd, maar welke PHP-runtime die het betreffende proces daadwerkelijk uitvoert. Webverzoeken kunnen een andere versie gebruiken dan CLI-opdrachten, cron-taken, queue-workers of geplande imports. Controleer daarom elke uitvoeringswijze afzonderlijk voordat code met nieuwe taalfuncties wordt geïmplementeerd.

De pipe-operator |> is een concreet voorbeeld: het hoort bij PHP 8.5 en kan niet worden geparseerd in PHP 8.4 of ouder. Het betreffende proces loopt al vast bij het inlezen van het bestand; de code bereikt dus noch een voorwaardelijke controle, noch een foutafhandeling. Dit kan vooral opvallen wanneer slechts één cronjob of worker nog met een oudere CLI-versie werkt.

<?php

$title = ' PHP 8.5 Released ';

$slug = $title
    |> trim(...)
    |> (fn($value) => str_replace(' ', '-', $value))
    |> strtolower(...);

Het voorbeeld toont uitsluitend PHP 8.5-syntaxis en is geen reden om werkende code te herschrijven. Nieuwe taalfuncties zijn vooral nuttig bij nieuwe of toch al herziene eigen ontwikkelingen. Voor een CMS zonder eigen PHP-aanpassingen levert dit geen direct voordeel op; compatibele versies van het kernsysteem, het thema en de geïnstalleerde plug-ins blijven belangrijker.

Composer-afhankelijkheden vereisen dezelfde zorgvuldigheid. De opgegeven PHP-vereisten moeten aansluiten bij de hostingomgeving, en een succesvolle implementatie betekent niet automatisch dat alle uitvoeringspaden compatibel zijn. Controleer daarom na een update de webinterface, geplande taken en externe interfaces. De officiële migratiehandleiding raadt uitdrukkelijk aan om tests uit te voeren voordat je een productieomgeving omzet.

Ook verschillen in de configuratie kunnen de resultaten beïnvloeden: geactiveerde extensies, memory_limit, max_execution_time en de foutmeldingen zijn niet per se identiek in de webprocess en de opdrachtregel. Noteer de gebruikte versies en instellingen per omgeving. Zo kun je een fout toewijzen aan een bepaalde runtime of configuratie, in plaats van deze zonder meer aan PHP 8.5 toe te schrijven.

Welke nieuwigheden in PHP 8.5 zijn in de praktijk van belang?

De nieuwe functies van PHP 8.5 zijn vooral interessant voor eigen applicaties en bibliotheken die actief worden ontwikkeld. Een CMS, een webwinkel of een plug-in wordt niet automatisch beter door de overstap alleen, alleen maar omdat de runtime nieuwe API’s aanbiedt. Het is van cruciaal belang of het project een concrete vereenvoudiging nodig heeft en of de vastgestelde minimumversie PHP 8.5 toestaat.

De Pipe-operator |> geeft een waarde links door aan een volgende ‘callable’-uitdrukking. Hierdoor kunnen verwerkingsstappen van links naar rechts leesbaar blijven, bijvoorbeeld bij het opschonen en herformuleren van een titel. Deze syntaxis kan echter alleen door PHP 8.5 worden geparseerd. Ze hoort daarom niet thuis in gezamenlijk geleverde code als webservers, CLI of workers nog met PHP 8.4 of ouder werken.

De functies array_first() en array_last() leveren respectievelijk het eerste en het laatste element van een array en geven bij een lege array null terug. Dit kan de code van kleine applicaties vereenvoudigen. Bibliotheken die meerdere PHP-versies ondersteunen, hebben echter nog steeds een compatibel alternatief nodig of moeten PHP 8.5 uitdrukkelijk als minimumversie aangeven. Het is niet nodig om werkende code alleen voor deze API’s te herschrijven.

De URI-uitbreiding biedt interfaces voor het verwerken en wijzigen van URI’s volgens RFC 3986 en de WHATWG-URL-standaard. Dit is nuttig wanneer een eigen ontwikkeling URL's op gestructureerde wijze samenstelt of normaliseert. Het vervangt noch bestaande URL-logica automatisch, noch een veiligheidscontrole: bij externe oproepen moeten toegestane doelhosts, machtigingen, time-outs en bescherming tegen ongewenste verzoeken aan de serverzijde nog steeds per toepassing worden geïmplementeerd.

Overstappen naar PHP 8.5 in de hostingomgeving

Een gecontroleerde overstap begint al vóór de overstap in het hostingpaneel. Maak een bruikbare back-up van bestanden, de database en relevante instellingen en maak een vluchtroute Kortom: wie de vorige PHP-versie, het herstelproces en het betreffende tijdsbestek kent, kan bij een fout op de juiste manier reageren. In de documentatie over PHP-migratie wordt aanbevolen om applicaties te testen voordat ze in productie worden genomen.

Gebruik hiervoor een proefversie of Staging-omgeving, voor zover deze beschikbaar is. Controleer daar niet alleen de PHP-versie die in de browser zichtbaar is, maar ook de uitvoeringstijden van commandoregelscripts, cron-taken en onderhoudswerkers. Composer-afhankelijkheden, de CMS-kern, het thema en de uitbreidingen moeten overeenkomen met de gekozen versie. Anders kunnen verschillen in PHP-versies tussen de implementatie en de achtergrondtaak pas na verloop van tijd fouten veroorzaken.

Bekijk tijdens de test de foutlogboeken en noteer de stappen waarmee elke fout kan worden gereproduceerd. Vooral opmerkingen en waarschuwingen van extensies mogen niet te snel als onschadelijk worden beschouwd: ze kunnen wijzen op interfaces die in de toekomst zullen worden verwijderd of op een verkeerde configuratie. Controleer bovendien welke extensies daadwerkelijk zijn geladen en welke limieten gelden; gedocumenteerde standaardwaarden komen niet noodzakelijkerwijs overeen met de daadwerkelijke php.ini van een specifieke hostingomgeving.

• Controleer de aanmelding, het verzenden van formulieren, het uploaden van media en het zoeken met realistische testgegevens.
• In de webshop de winkelwagen, het afrekenen, de integratie van betalings- en verzendopties en de bestellingsmails doorlopen.
• Cron-taken, wachtrijen of andere workers uitvoeren en koppelingen met externe diensten controleren.

Plan de productieve omschakeling pas na dit testblok en kies een tijdsvenster waarin je de gevolgen kunt observeren. Controleer daarna opnieuw de logbestanden en de belangrijkste processen, in plaats van alleen de startpagina te openen. Of bijvoorbeeld de geheugenlimiet, de maximale uitvoeringstijd of extra PHP-extensies aanpasbaar zijn, hangt af van het tarief en de provider. Deze factoren, evenals de CPU- en geheugencapaciteit, moeten los van de PHP-versie worden beoordeeld; achtergrondinformatie hierover vind je in het artikel over webhostinghardware die van invloed is op de prestaties.

Verouderde elementen in code en pakketten beoordelen

A Waarschuwing voor verouderde functies is in PHP 8.5 doorgaans een migratieadvies, geen directe productiestoring. De betreffende code kan blijven draaien, maar moet worden voorbereid op een latere verwijdering. Als er echter waarschuwingen worden weergegeven in HTML-pagina's of JSON-antwoorden, kunnen de lay-out, API-uitvoer of reeds ingestelde HTTP-headers hierdoor worden beïnvloed. Leg ze daarom vast in tests en los de oorzaak ervan op.

Tot de betrokken patronen behoren niet-canonieke Cast-schrijfwijzen zoals (boolean) of (integer), backticks als afkorting voor shell_exec() en een puntkomma in plaats van een dubbele punt na case. Ook relevant zijn null als array-offset of bij array_key_exists(). In eigen, overzichtelijke code kan de beoogde schrijfwijze meestal gericht worden gecorrigeerd.

Bij pakketten van derden is blind zoeken en vervangen riskant. Frameworks, ORM’s, dependency-injection-containers en testtools maken vaak gebruik van reflection; eventuele verouderde aanroepen zoals Reflection*::setAccessible() kunnen dus voortkomen uit een afhankelijkheid. Werk eerst de Composer-afhankelijkheden binnen de gedocumenteerde versiegrenzen en voer vervolgens de test opnieuw uit. Pas als er geen update beschikbaar is, moet de applicatie een alternatief, een patch van de fabrikant of het tijdelijk blijven gebruiken van een compatibele runtime overwegen.

De PDO-DSN-vorm verdient bijzondere aandacht uri:, die in PHP 8.5 verouderd is. De bijbehorende RFC wijst op beveiligingsrisico’s wanneer DSN’s via onbetrouwbare of externe URI’s kunnen worden beïnvloed, evenals op mogelijke opvragingen bij het tot stand brengen van een verbinding. Dit is geen reden om inloggegevens in URL’s of bestanden op te slaan. Controleer in plaats daarvan of de verbindingsgegevens afkomstig zijn uit een gecontroleerde configuratie en hoe het gebruikte pakket een ondersteunde DSN beschikbaar stelt.

Het globaal onderdrukken van fouten schuift het probleem alleen maar naar de toekomst en bemoeilijkt de voorbereiding op latere PHP-versies. Geef daarom prioriteit aan waarschuwingen op basis van bereik: eerst productiegerelateerde paden zoals checkout, login, interfaces en cron, daarna zeldzame beheerfuncties. Zo blijft het duidelijk of een gevonden fout afkomstig is uit de eigen code, wordt veroorzaakt door een plug-in of slechts betrekking heeft op een niet-gebruikte ontwikkelingsafhankelijkheid.

Fouten nauwkeurig vastleggen en correct interpreteren

Na een overstap naar PHP 8.5 geven foutlogboeken meer informatie dan een vluchtige blik op de startpagina. PHP 8.5 kan bij fatale fouten uitgebreidere stacktraces weergeven, bijvoorbeeld wanneer de maximale uitvoeringstijd is overschreden. Dit maakt het gemakkelijker om de fout aan een bestand en een aanroepspad te koppelen, maar lost noch eindeloze lussen, noch trage databasequery's of externe wachttijden op.

Voor een bruikbare diagnose noteer je het tijdstip van de fout, de opgeroepen URL of actie, de status van de aangemelde gebruiker en de stappen die tot de fout hebben geleid. Herhaal de procedure eerst op een testomgeving, indien mogelijk met dezelfde configuratie en dezelfde versies van de extensies. Zo kun je vaststellen of de oorzaak ligt in de PHP-update, in een extensie of in een specifieke invoer.

In een testomgeving mag de Foutmelding het opsporen van de oorzaak ondersteunen. In een openbare omgeving horen technische details echter thuis in beveiligde logbestanden en niet in de browseruitvoer. Zichtbare meldingen kunnen bestandspaden, klassennamen, gebruikte extensies of delen van een stacktrace onthullen. Welke instellingen daadwerkelijk van toepassing zijn, hangt af van de concrete PHP-configuratie; gedocumenteerde standaardwaarden hoeven niet overeen te komen met een hostingomgeving.

Een time-out is dus een bevinding, geen oplossing. Controleer eerst of de fout bij elke aanroep optreedt of alleen bij een bepaalde zoekopdracht, een import of een interface. Daarna komen de applicatiecode, databasequery’s, externe diensten en de toegestane looptijd als afzonderlijke oorzaken in aanmerking. Het simpelweg verhogen van de in de hosting ingestelde tijdslimiet kan symptomen verdoezelen en is alleen zinvol nadat de oorzaak is vastgesteld.

• Witte pagina of HTTP-500-fout: vergelijk de tijdstempels in de PHP- en webserverlogs met de herhaalbare aanroep.
• Afgebroken import of cron-taak: controleer de looptijd, het geheugengebruik, de hoeveelheid invoer en de fouten van het betreffende achtergrondproces.
• Fouten die alleen optreden na het inloggen of tijdens het afrekenen: test de betreffende extensies en de gehele actie, inclusief de e-mail- en betalingsintegratie.
• Onverwachte uitvoer of ongeldige JSON: zoek naar waarschuwingen en verouderde functies voordat headers of API-antwoorden worden verzonden.

HTTP-headers en achtergrondtaken controleren

Code die gebruikmaakt van HTTP-verzoeken verdient bij een update een grondige controle. De variabele $http_response_header is in PHP 8.5 verouderd. Deze bevatte de responsheaders van een aanroep via de HTTP-wrapper en werd aangemaakt in het lokale bereik waarin de aanroep plaatsvond. Code buiten een functie had daarom geen automatische toegang tot headers die binnen de functie waren aangemaakt.

Sinds PHP 8.4 is http_get_last_response_headers() als alternatief beschikbaar. De functie geeft de laatst ontvangen headers weer of null , als er geen beschikbaar zijn. Voor projecten die nog op PHP 8.3 moeten draaien, is een versiecontrole vereist; voor een project waarvoor PHP 8.4 of hoger verplicht is, kan de nieuwe API direct worden gebruikt.

De volgende overgangscode houdt rekening met beide gevallen. Deze code gaat ervan uit dat het opvragen zelf is toegestaan volgens het applicatieconcept; het vervangt noch time-outs, noch foutafhandeling, noch een beperking van toegestane bestemmingsadressen. Juist bij URL’s die door gebruikers worden ingevoerd, moeten machtigingen en toegestane hosts worden gecontroleerd, onafhankelijk van de evaluatie van de headers.

<?php

$responseBody = file_get_contents('https://example.invalid/');

$headers = function_exists('http_get_last_response_headers')
    ? http_get_last_response_headers()
    : ($http_response_header ?? null);

Controleer deze wijziging niet alleen in het webverzoek. Achtergrondbanen Cron-taken, queue-workers, importscripts en CLI-commando’s kunnen een ander PHP-binair bestand gebruiken dan de website. Daardoor zijn ook afwijkende extensies en configuratiewaarden mogelijk. Bepaal voor elke uitvoeringsroute de daadwerkelijke PHP-versie en voer de betreffende taken na de omschakeling onder toezicht uit.

Na de update de situatie in de gaten houden en een besluit nemen

Na de omschakeling begint de operationele nacontrole. Houd gedurende een redelijke gebruiksperiode de foutlogboeken en de eerder gedefinieerde kernprocessen in de gaten: aanmeldingen, formulieren, bestellingen, verzending van e-mails, koppelingen en geplande taken. Let daarbij op nieuwe waarschuwingen, terugkerende fatale fouten en afgebroken processen. Afzonderlijke testaanroepen direct na de omschakeling leggen niet noodzakelijkerwijs tijdgestuurde of zelden gebruikte functies vast.

Ook responstijden en meldingen over systeembronnen moeten in hun context worden gezien. De PHP-versie is slechts één factor naast de applicatiecode, de database, caching, OPcache, PHP-FPM, geactiveerde extensies en de beschikbare CPU- en geheugenbronnen. PHP 8.5 is daarom geen algemene prestatiegarantie. Alleen metingen met vergelijkbare processen laten zien of een waargenomen gedrag daadwerkelijk is veranderd.

Met name limieten zoals memory_limit en max_execution_time moeten worden bepaald op basis van de werkelijke omgeving, in plaats van uit te gaan van waarden uit de handleiding. Hetzelfde geldt voor geactiveerde uitbreidingen en het procesbeheer. De documentatie beschrijft mogelijke of vooraf ingestelde waarden, terwijl het hostingpakket en de serverconfiguratie bepalen wat een toepassing daadwerkelijk aantreft.

Wie prestatiekwesties los van de versiemigratie wil onderzoeken, moet PHP-FPM, OPcache en de applicatie bekijken aan de hand van traceerbare meetwaarden. Het interne artikel over de De rol van PHP-JIT bij webhosting legt uit waarom CPU-intensieve codepaden anders moeten worden beoordeeld dan database- of netwerkgerelateerde verzoeken. Een configuratiewijziging mag daarbij pas worden doorgevoerd na een reproduceerbare basismeting.

De beslissing vloeit voort uit de bevinding: als een goed onderhouden applicatie, inclusief uitbreidingen, foutloos draait in de testomgeving, is een geplande overstap naar PHP 8.5 zinvol. Als er voor een kritieke plug-in geen goedkeuring is of als er een onopgeloste fout is, blijft de aantoonbaar compatibele PHP-versie de veilige tussenoplossing. Bij oudere basisversies is in plaats van een geïsoleerde overstap naar 8.5 een uitgebreidere migratie nodig, waarbij alle overgeslagen migratie-instructies worden meegenomen.