Een website op PHP 5.6 in 2026 is zeldzaam maar niet uitgestorven. Deze case gaat over een makelaarskantoor met twee vestigingen dat er zonder het te weten al zeven jaar een had draaien. De aanleiding om er iets aan te doen was banaal: het koppelstuk met de landelijke woningdatabase werd vernieuwd, en de leverancier meldde dat de nieuwe versie minimaal PHP 7.4 vereist.

Hieronder het verloop, de kosten in uren en wat er onderweg misging. Het kantoor blijft anoniem; de aanpak is precies zoals hij is uitgevoerd.

Wat we aantroffen

PHP 5.6 is uitgebracht in 2014 en kreeg zijn laatste beveiligingsupdate eind 2018. Alles wat daarna aan lekken is gevonden, is in die versie nooit gerepareerd. De site had:

  • WordPress 5.4, achttien versies achter op wat er beschikbaar was;
  • eenentwintig actieve plugins, waarvan er zeven al vijf jaar of langer geen update meer hadden gekregen;
  • een maatwerkkoppeling met de woningdatabase, geschreven door een bouwer die niet meer bereikbaar was;
  • een thema met aanpassingen die rechtstreeks in de themabestanden waren gezet, dus zonder child-thema;
  • geen back-up, anders dan de wekelijkse kopie van de hostingpartij die zeven dagen bewaard bleef.

Het opvallendste: er waren geen klachten. De site laadde in ruim drie seconden, wat niemand als traag ervoer, en hij was in al die jaren nooit gehackt. Dat is een belangrijk punt bij dit soort verhalen. Verouderde techniek geeft geen alarm; het maakt alleen de kans op iets vervelends elk jaar wat groter.

Waarom een website op PHP 5.6 niet in één klik omhoog kan

In het hostingpaneel stond een keuzelijst waarin PHP 8.2 selecteerbaar was. Eén klik. Dat is precies wat u niet doet bij een site op PHP 5.6.

De reden is dat tussen 5.6 en 8.0 een aantal schrijfwijzen definitief is verdwenen. Code die op 5.6 nog werkte, valt op 8 stil met een fatale fout, en het resultaat is een witte pagina zonder enige uitleg. Bij eenentwintig plugins en een onbekend stuk maatwerk is de kans daarop niet klein maar vrijwel zeker.

Er was nog een reden om het rustig te doen: het kantoor kreeg zijn aanvragen via de site. Twee dagen uit de lucht zou echt geld kosten. Alles gebeurde daarom in een kopie, met de echte site onaangeroerd tot het eind. Waarom dat werkt en wat het kost, staat bij het opzetten van een testomgeving naast de live site.

De vier stappen die we hebben gezet

Stap 1: veiligstellen en kopiëren

Een volledige kopie van bestanden en database, weggezet buiten de hosting, en daarna een testomgeving op hetzelfde platform maar met een eigen adres. Tijdsbesteding: twee uur.

Stap 2: eerst WordPress en de plugins, nog op 5.6

Dit is de stap die vaak wordt overgeslagen. We hebben eerst alle software bijgewerkt naar de laatste versie die nog op PHP 5.6 draaide, en pas daarna aan de PHP-versie gezeten. Zo scheidt u twee soorten problemen. Breekt er iets, dan weet u of het door de update of door de PHP-sprong komt.

Vier van de zeven verlaten plugins hadden geen nieuwere versie. Twee daarvan bleken overbodig en zijn verwijderd; twee zijn vervangen door een onderhouden alternatief, waarbij de instellingen handmatig zijn overgezet. Tijdsbesteding: zes uur.

Stap 3: stapsgewijs omhoog

Van 5.6 naar 7.4, testen, dan naar 8.0, testen, dan naar 8.2. Bij elke stap alle belangrijke pagina’s langs, plus inloggen, zoeken, het contactformulier en het woningoverzicht.

Twee dingen gingen kapot. De maatwerkkoppeling gaf op PHP 8.0 een fatale fout door een verouderde manier van functies aanroepen; dat is herschreven in ongeveer drie uur. En een oude galerijplugin toonde na de sprong lege blokken; die is vervangen door de galerijfunctie die inmiddels in WordPress zelf zit. Tijdsbesteding inclusief herstel: negen uur.

Stap 4: overzetten

Op een dinsdagochtend om zeven uur is de testversie live gezet en is de PHP-versie op de echte omgeving verhoogd. De site was elf minuten in onderhoudsmodus. Daarna twee uur meekijken en de foutenlog in de gaten houden. Tijdsbesteding: drie uur.

Het resultaat, gemeten

  • Laadtijd van 3,2 naar 1,4 seconden op de woningoverzichtspagina, zonder dat er iets aan de opmaak of de afbeeldingen is veranderd. Dat is puur het effect van de nieuwere PHP-versie en het verwijderen van zes plugins.
  • Van eenentwintig naar veertien actieve plugins.
  • Beheerscherm merkbaar sneller, wat voor de twee medewerkers die dagelijks woningen invoeren het meest tastbare verschil was.
  • Twintig uur werk in totaal, verspreid over drie weken.

Wat het niet opleverde: meer bezoekers, althans niet aantoonbaar binnen drie maanden. Wie beweert dat een PHP-upgrade uw posities in Google verbetert, gaat te ver. Snelheid is één van vele factoren en het effect is bij een site van deze omvang niet uit de ruis te halen.

Wat u hieruit kunt halen

Drie lessen die breder gelden dan dit ene kantoor.

Zet nooit één grote stap. Software eerst bijwerken, dan pas de PHP-versie, en dan per tussenversie. Het kost meer testrondes maar bespaart uren zoeken.

Reken op verlaten plugins. Bij elke site die jaren stilstond zit een handvol onderdelen zonder toekomst. Hoe u die vooraf herkent, leest u bij het bijwerken van de PHP-versie van uw site.

Het probleem was niet de techniek maar het gebrek aan toezicht. Zeven jaar lang keek er niemand, tot een leverancier toevallig een eis stelde. Dat is de kern: niet één keer moderniseren, maar zorgen dat het niet opnieuw zeven jaar duurt. Sindsdien loopt de site mee in beheer met een vaste controle op serverversies, waarbij twee keer per jaar naar de PHP- en databaseversie wordt gekeken. Die controle kost een kwartier en voorkomt precies dit soort inhaalslagen.