Contact
← Terug naar kennisbank HOSTING

PHP-versie veilig upgraden zonder je site te breken

Een mail van je hoster: "PHP 8.1 wordt over zes weken uitgeschakeld." Voor sommigen aanleiding voor paniek, voor anderen aanleiding om het uit te stellen tot het te laat is. Dit is hoe je de upgrade veilig doet — voor elk CMS-platform, met compatibility-checks en een werkbare rollback.

13 min lezen · Laatst gecheckt:

PHP-versie upgraden klinkt als een onzichtbaar technisch klusje, maar voor onvoorbereide sites is het een van de meest voorkomende oorzaken van plotselinge offline-momenten. Een verouderde plugin die incompatibel is met PHP 8.x, een functie die in PHP 8 verwijderd werd zonder dat iemand het doorhad, een framework dat strict types eist waar het oude vrij omging — en je site werpt witte schermen.

Goed nieuws: alle problemen zijn voorspelbaar. Dit artikel geeft het stappenplan om de upgrade voor te bereiden, uit te voeren en te valideren — voor WordPress, Drupal, Joomla, OpenCart en CMS Made Simple.

Waarom moet je upgraden?

Vier redenen, in volgorde van urgentie:

  • Security: PHP 7.x heeft sinds november 2022 geen security-updates meer. PHP 8.0 sinds november 2023. PHP 8.1 sinds november 2024. Draai je daarop, dan loop je actieve risico's bij elke nieuwe kwetsbaarheid die ontdekt wordt
  • Hosting-druk: Nederlandse hosters (Mijndomein, TransIP, Hostnet, Vimexx, Antagonist, etc.) schakelen actief oude PHP-versies uit. Krijg je een "wordt uitgeschakeld op X" mail, dan moet je echt acteren
  • Performance: PHP 8.x is meetbaar sneller dan PHP 7.x — soms tot 30% bij CMS-workloads. Op grotere sites scheelt dat hosting-kosten
  • Compatibility: nieuwere versies van plugins, modules en composer-packages vereisen vaak PHP 8.1 of hoger als minimum

Per begin 2026 is de praktische werkelijkheid:

  • PHP 7.x: alleen draaien als je hoster het nog ondersteunt en je geen andere keuze hebt — niet veilig
  • PHP 8.0 / 8.1: end of life, alleen in noodsituaties
  • PHP 8.2: in security-support-fase tot december 2026 — werkbare doelversie
  • PHP 8.3: actieve support tot december 2027 — beste keuze voor de meeste sites
  • PHP 8.4: nieuwste, actieve support — alleen kiezen als al je extensies/plugins compatibel zijn

Stap 1: Inventariseer wat je hebt

Voor je iets verandert, breng deze gegevens in kaart:

  • Huidige PHP-versie: te vinden in je hosting control panel of via een PHP-info bestand. Maak info.php in je webroot met inhoud <?php phpinfo(); ?>, open in browser, lees versie, verwijder daarna direct
  • CMS-versie: oudere CMS-versies werken vaak niet met nieuwere PHP. WordPress 5.x op PHP 8.2 is bijvoorbeeld geen goede combinatie
  • Lijst van plugins/modules/extensies + hun versies
  • Custom code: themes, eigen plugins, snippets in functions.php — alles wat niet uit een officieel pakket komt
  • PHP-extensies die je site nodig heeft (mbstring, gd, curl, intl, etc.) — moeten ook in de nieuwe PHP-versie aanwezig zijn
  • Composer dependencies bij Drupal en moderne PHP-applicaties

Stap 2: Compleet backup van je site

Voor een PHP-upgrade is dit non-negotiable. Files + database, naar een externe locatie. Zelfs als je hoster automatische backups maakt — vertrouw die niet als enige veiligheidsnet. Maak een handmatige backup naar je eigen computer of een cloud storage:

# Files
tar czf site-pre-php-upgrade.tar.gz public_html/

# Database
mysqldump --single-transaction --quick \
  --user=DBUSER --password DBNAME > pre-upgrade.sql

Bewaar deze backups op een aparte locatie buiten je hosting. Test minimaal of de tarball uitpakt — een onleesbare backup is geen backup.

Stap 3: Test eerst op staging

Dit is de stap die het meeste tijd bespaart. Niemand wil ontdekken dat z'n WooCommerce-site het niet meer doet om 14:00 op een dinsdag. Test op een staging-omgeving (zie het staging artikel) of een lokale kopie. Op staging kun je rustig de PHP-versie wijzigen en kijken wat breekt.

Bij sommige hosters kun je een test-PHP-versie instellen voor een specifiek subdomein — handig voor staging.

Stap 4: Run compatibility checks

Voor je upgrade: laat tools je code scannen op deprecated of verboden constructies. Per CMS:

WordPress

Plugin: "PHP Compatibility Checker" van WP Engine (gratis). Installeer op staging, run scan tegen doel-PHP-versie. Krijgt je een rapport van welke plugins/themes issues hebben.

Maar pas op: deze tool detecteert alleen statische problemen, geen runtime-issues. Combineer met handmatig testen.

Voor de plugin- en theme-check: bezoek de WordPress.org pagina van elke plugin/theme. Onder "Tested up to" staat het hoogste WordPress-versie waarop 'ie getest is, en sommige plugins vermelden expliciet "Requires PHP".

Drupal

Drupal heeft de phpstan en drupal-rector tools. Voor een snelle check:

composer require --dev mglaman/drupal-check
vendor/bin/drupal-check . --memory-limit=2G

Plus: in de Drupal admin → Reports → Status report staat de minimale PHP-versie voor jouw Drupal-versie. Drupal 9.x werkt met PHP 7.4+, Drupal 10.x vereist PHP 8.1+.

Joomla

Joomla heeft Akeeba Admin Tools' "PHP File Change Scanner" en "Server Configuration" check. Plus: System → System Information → PHP Information toont actieve extensions.

Joomla 4.x werkt met PHP 7.2.5+, Joomla 5.x vereist PHP 8.1+.

OpenCart

Geen ingebouwde compatibility-tool. Aanpak: laat error_reporting(E_ALL) aan op staging en doorloop alle frontend + admin functies. Letten op deprecated warnings.

OpenCart 3.0.x heeft moeite met PHP 8.1+. OpenCart 4.x werkt met PHP 8.1+ maar vraag je hoster om GD-extensie correct geconfigureerd.

CMS Made Simple

Geen automatische tool. Test handmatig op staging. CMSMS 2.2.x werkt formeel met PHP 7.2-8.2; vanaf PHP 8.3 zijn er deprecation warnings, maar de site blijft meestal werken.

Stap 5: Update je CMS en componenten vóór de PHP-upgrade

Volgorde matters: oude CMS-versie + nieuwe PHP = moeilijkere combinatie dan nieuwe CMS-versie + nieuwe PHP. Werk dus eerst alles bij naar laatste versies:

  1. CMS core update naar latest stable
  2. Plugins/modules/extensies updaten
  3. Themes updaten
  4. Composer dependencies updaten (waar van toepassing)
  5. Cache flushen
  6. Test alles werkt op huidige PHP-versie

Pas dan ga je de PHP-versie zelf wijzigen.

Stap 6: PHP-versie wijzigen — per control panel

cPanel

Software → MultiPHP Manager. Selecteer domein, kies versie uit dropdown, "Apply". Wijziging is onmiddellijk actief.

Voor specifieke directories of extensies: PHP Selector (als je hoster het aanbiedt). Daar kun je per domein extensies aan/uit zetten en INI-waarden aanpassen.

Plesk

Domains → kies domein → PHP Settings → "PHP version" dropdown. Kies versie, "OK". Wijziging is direct actief, geen restart nodig.

Plesk geeft je per domein-controle, en kan ook per directory een andere PHP-versie draaien (handy voor migraties).

DirectAdmin

Account → Domain Setup → klik domein → "PHP Version Selector". Kies versie. DirectAdmin gebruikt per default CloudLinux's PHP Selector als de hoster dat heeft geactiveerd.

In sommige DirectAdmin-installaties moet je het via het Reseller-niveau aanpassen — dan moet je hosting support het voor je doen.

Via .htaccess (alleen als je hoster het ondersteunt)

Sommige hosters laten je via .htaccess een PHP-versie afdwingen voor een specifieke map. Syntax verschilt per hoster:

# cPanel/EasyApache style
AddHandler application/x-httpd-php82 .php

# Sommige andere hosters
<FilesMatch "\.php$">
    SetHandler application/x-httpd-php-8.2
</FilesMatch>

Dit is hosting-specifiek. Werkt het niet, dan mist die functionaliteit. Vraag je hoster naar de juiste syntax. Zie ook het .htaccess artikel voor algemene context.

Stap 7: Test grondig en monitor logs

Na de switch:

  1. Doorklik-check: homepage, contactformulier, login, alle belangrijke functies
  2. WooCommerce/OpenCart/etc.: complete checkout-flow met test-bestelling
  3. E-mail uitgaand: verstuur een test-mail vanaf het contactformulier
  4. Admin-paneel: log in, bewerk een pagina, sla op
  5. Cron jobs: check of geplande taken nog draaien (vaak draaien die op CLI met andere PHP-config)

Server-logs check:

  • Apache/Nginx error_log voor 500-errors
  • PHP error_log voor deprecated warnings (negeer warnings, focus op fatal errors)
  • Mailtraffic — soms breekt PHP-upgrade SMTP via plugin

Veelvoorkomende errors — en hoe je ze fixt

"Call to undefined function each()"

Functie each() is verwijderd in PHP 8. Vaak in oudere code. Vervang met foreach():

// Oud (werkt niet in PHP 8)
while (list($key, $val) = each($array)) { ... }

// Nieuw
foreach ($array as $key => $val) { ... }

"Trying to access array offset on value of type bool"

Code probeert array-indexering op een boolean. Strict in PHP 8.x. Toegang via $result['key'] waar $result false is bij DB-fout. Voeg null-check toe.

"mysql_* functies niet gevonden"

De mysql_* familie is verwijderd in PHP 7.0. Code moet mysqli_* of PDO gebruiken. Bij oude WordPress/Joomla snippets: vervangen.

"Required parameter follows optional parameter"

PHP 8.x is strict over parameter-volgorde. Functie zoals function f($a = 1, $b) werkt niet meer. Maak alle parameters optioneel of zet required eerst.

Witte scherm na upgrade

Meestal: een fatal error die niet getoond wordt. Tijdelijk in wp-config.php / configuration.php / config.php error display aan zetten:

ini_set('display_errors', 1);
error_reporting(E_ALL);

Refresh, lees de fout, fix de oorzaak. Daarna error display weer uit.

"Cannot find module/extension"

Bijvoorbeeld: "PHP Curl extension required". De nieuwe PHP-versie heeft die extensie niet ingeschakeld. Activeer via control panel:

  • cPanel: PHP Selector → Extensions
  • Plesk: PHP Settings per domain → Extensions
  • DirectAdmin: PHP Selector → Select Extensions

Rollback-strategie

Als alles misgaat:

  1. PHP-versie terugzetten via je control panel — meestal binnen 1 minuut hersteld
  2. Code-issues blijven? Dan was de upgrade niet de oorzaak — controleer je laatste deploys
  3. Database corruption? Restore vanuit Stap 2 backup

Houd de oude PHP-versie minimaal 7-14 dagen actief op je hosting. Zo kun je makkelijk teruggaan als er na een paar dagen pas issues opduiken (cron jobs die wekelijks draaien, edge-case scenarios).

Tip voor commerciële sites: plan PHP-upgrades altijd op rustige momenten — vroege ochtend, late avond voor B2C-sites; weekend voor B2B. Vermijd vrijdagmiddag ("Friday deploys are forbidden" is een industrieel inzichtelijk advies).

Wanneer schakel je hulp in?

  • Compatibility-tools tonen 50+ issues — handmatig fixen kost dagen, een specialist doet het in uren
  • Custom code waarvan de oorspronkelijke ontwikkelaar niet meer beschikbaar is
  • WooCommerce/OpenCart-shop met live klanten en orders — hoge risico's, je kunt het niet "even uitproberen"
  • Drupal-site met composer dependencies die conflicten geven
  • Site die op een verouderde CMS draait die nieuwere PHP niet ondersteunt — dan moet eerst de CMS upgraden, dan PHP
  • Je hoster geeft een deadline van 7 dagen en je weet niet eens waar je moet beginnen

Een PHP-upgrade is een vakantie-of-niet-vakantie beslissing. Goed voorbereid is het 1-2 uur per site. Slecht voorbereid is het een hele dag stress en mogelijk dagen downtime. De stappen hier zorgen ervoor dat je in de eerste categorie zit.