PHP upgraden op WordPress-sites van klanten zonder ze te breken

De PHP-beveiligingsrelease van oktober 2026 was een nuttige herinnering: sommige oplossingen komen niet uit een WordPress-update. Zit het lek in PHP zelf, dan is de oplossing een nieuwere PHP-versie op de server, en sites op een tak die geen beveiligingsupdates meer krijgt, krijgen helemaal geen oplossing. Deze gids is een werkwijze die je op elke klantsite kunt draaien om hem zonder verrassingen naar een ondersteunde PHP-versie te brengen.

Waarom de PHP-versie belangrijker is dan het lijkt

Elke PHP-tak krijgt een beperkte tijd beveiligingsupdates. Stopt dat, dan blijft elk nieuw lek erin open, hoe zorgvuldig je WordPress, plugins en thema’s ook bijwerkt. PHP 8.1 en ouder krijgen geen officiële beveiligingsupdates meer. Kijk op php.net/supported-versions voor de actuele data van elke tak.

Er is een tweede reden. Makers van plugins en thema’s laten oude PHP-versies na verloop van tijd vallen. Een site die op een oude tak blijft, verliest langzaam toegang tot plugin-updates, en daarmee tot beveiligingsoplossingen in de plugins zelf.

Stap 1: noteer de PHP-versie van elke site

In WordPress vind je die onder Extra → Sitestatus → Info → Server. Je hostingpaneel toont hem ook. Noteer per site de PHP-versie, de WordPress-versie, het thema, de pagebuilder, of er WooCommerce draait en of er maatwerkcode in een child theme of must-use-plugin zit.

Sorteer daarna de lijst. Begin met de oudste PHP-versies, en daarbinnen met de sites die geld opleveren of leads binnenhalen: shops, boekingssites en sites met belangrijke formulieren.

Stap 2: zoek wat de overstap tegenhoudt

De meeste PHP-upgrades lopen vast op één oude plugin, een verlaten thema of een stuk maatwerkcode. Zoek deze op voordat je overstapt:

• Plugins en thema’s die twee jaar of langer niet zijn bijgewerkt. Kijk naar de regels “Requires PHP” en “Tested up to” op hun pluginpagina.
• Oude versies van pagebuilders en premium plugins waarvan de licentie verlopen is, zodat de site nooit de versies kreeg die nieuwere PHP ondersteunen.
• Maatwerkcode in functions.php of must-use-plugins. Functies zoals each() en create_function() zijn verwijderd in PHP 8.0, en PHP 8.2 waarschuwt voor dynamische properties.
• Compatibiliteitsscanners kunnen helpen, maar ze geven valse meldingen. Zie hun uitvoer als een startlijst, niet als een oordeel.

Update eerst WordPress, plugins en thema’s, terwijl de site nog op de huidige PHP-versie draait. Nieuwere pluginversies ondersteunen meestal nieuwere PHP. Doe de updates en de PHP-overstap op verschillende dagen, zodat je weet welke wijziging een probleem veroorzaakte.

Stap 3: test eerst op een kopie

Maak een stagingkopie van de site en zet die op de doelversie van PHP. Bij de meeste hosts kies je de PHP-versie per site. Zet WP_DEBUG_LOG aan op de kopie, zodat fouten in een logbestand komen in plaats van op het scherm.

Klik daarna door wat er voor deze klant toe doet:

• De homepage en de twee of drie meest bezochte pagina’s, op desktop en mobiel.
• Elk belangrijk formulier: verstuur het en controleer of de e-mail aankomt.
• Bij een shop: in winkelwagen, afrekenen met een testbestelling, de accountpagina.
• In de beheeromgeving: de editor en de pagebuilder openen, media uploaden werkt, instellingenpagina’s laden.

Lees daarna wp-content/debug.log. Fatale fouten moet je oplossen voordat je live gaat. Deprecation-meldingen zijn waarschuwingen voor de volgende upgrade; schrijf ze op, ze kunnen wachten. Schermafbeeldingen van de belangrijkste pagina’s voor en na vergelijken vangt de problemen die geen fout geven, zoals een slider of menu dat niet meer verschijnt.

Stap 4: zet de live site om op een rustig moment

Kies een moment met weinig verkeer. Maak vlak voor de overstap een verse back-up van bestanden en database, en noteer de huidige PHP-versie. Wissel PHP in het hostingpaneel, leeg de paginacache en een eventuele objectcache, en doe dezelfde controles als op de kopie. Laat het loggen van fouten naar een bestand een dag of twee aan staan, zodat je de pagina vangt die niemand tijdens je controle bezocht.

Vertel de klant in een of twee zinnen wat je deed en waarom. Een PHP-upgrade is onzichtbaar als hij goed gaat, en het is goed onderhoudswerk waar ze van mogen weten.

Stap 5: ken je weg terug

Terugdraaien na een PHP-upgrade is meestal eenvoudig: zet de versie terug in het hostingpaneel. Daarom schreef je de oude versie op. Blijkt één plugin het probleem, dan heb je drie opties: bijwerken, vervangen, of korte tijd op de vorige ondersteunde tak blijven terwijl je het oplost. Blijf nooit langer dan nodig op een niet-ondersteunde tak.

Als het dringend is: een beveiligingsrelease voor PHP zelf

Wordt er een lek in PHP gepubliceerd, dan lost een WordPress-update het niet op. Vraag je host of de patchrelease voor jouw tak is toegepast. Een patch binnen dezelfde tak, bijvoorbeeld van de ene 8.3-release naar de volgende, breekt zelden iets. De risicovolle stap is de sprong naar een nieuwe tak, en precies daar bereidt deze gids je op voor. Sites op een tak zonder beveiligingsupdates plan je als eerste in.

Update 23 oktober 2026: een tweede PHP-probleem met lager risico. Twee dagen na de kritieke release publiceerde PHP een informatieve melding over CVE-2026-115560 in session upload progress (php.net). PHP acht misbruik onwaarschijnlijk: er zijn meerdere specifieke instellingen en code tegelijk voor nodig. Er is nog geen oplossing; die komt in de volgende reguliere PHP-release. Werk tot dan eerst de updates van 21 oktober af en vraag je host daarna om session.upload_progress.enabled op off te zetten in php.ini of de PHP-FPM-pool en PHP te herstarten. Dit instellen vanuit WordPress of een .user.ini -bestand kan op PHP-FPM te laat komen.

Hoe Verploy met PHP-upgrades omgaat

Op sites met een oude PHP-versie laat de PHP-upgradecheck van Verploy zien wat de overstap tegenhoudt en in welke volgorde je het oplost. Elke update wordt gecontroleerd, en de risicovolle worden eerst op een kopie getest. Zie hoe het in een volledige onderhoudsroutine past op WordPress-onderhoud voor bureaus.