WordPress onderhoud en updates worden vaak behandeld als een technisch klusje, maar in de praktijk is het vooral een kwestie van risicobeheersing en structuur.
Elke update—van WordPress zelf tot PHP en plugins—is een afweging tussen stabiliteit, compatibiliteit en toekomstbestendigheid.
In plaats van te zoeken naar “de juiste manier om te updaten”, draait het om de vraag: hoe zorg je dat je website blijft werken terwijl alles eronder verandert?
Dat vraagt minder om technische handigheid, en meer om voorbereiding, testen en bewust omgaan met onzekerheid in open source omgevingen.
De antwoorden heeft mijn pa me lang geleden gegeven
“Alles wat je hebt moet je bijhouden” – Toon Botermans
Ik weet het nog zo goed. We waren in de garage en ik was een jaar of tien toen hij me dat probeerde uit te leggen. Het ging over werken met gereedschap: hoe je ermee omgaat, waar je op let en waarom je er goed voor moet zorgen.
Een simpele les, die later veel breder bleek te gelden. Vandaag, hier en nu, gaat het over hoe wij technisch zorg dragen voor onze website — en alles wat daaronder draait.
Managed hosting helpt, maar neemt niet alles over
Het klopt dat een managed hosting partij veel uit handen neemt: merci Xel daarvoor. De meeste technische complexiteit speelt zich onder water af: updates, beveiliging, monitoring en support.
Maar “managed” betekent niet “alles geregeld”.
Er blijft genoeg over wat je zelf moet begrijpen en bewaken—zeker in een open source stack zoals WordPress en PHP.
Dit is onze manier van kijken naar snel veranderende software, risico’s en hoe je die beheersbaar maakt, aan de hand van een concreet voorbeeld: de upgrade van deze website.
Onderhoud is geen techniek, maar risicobeheer
WordPress onderhoud wordt vaak gezien als iets technisch: updates draaien, plugins bijwerken, klaar.
In werkelijkheid gaat het om het beheersen van risico’s in een systeem dat constant in beweging is.
Elke update verschuift de balans. Soms subtiel, soms ingrijpend.
De kernvraag is daarom niet:
wat moet er geüpdatet worden?
maar:
wat kan er misgaan als ik dit op het verkeerde moment doe?
De illusie van “altijd de nieuwste versie”
Er is een natuurlijke neiging om te denken dat de nieuwste versie altijd beter is.
Dat klopt deels, maar niet volledig.
Nieuw betekent vaak:
-
minder praktijkervaring in combinatie met andere systemen
-
meer onbekende randgevallen
-
meer onzekerheid
Oudere versies betekenen:
-
stabiel gedrag
-
maar een oplopend risico op einde ondersteuning
Onderhoud wordt daarmee geen technische keuze, maar een voortdurende afweging tussen stabiliteit en toekomstbestendigheid.
Werken met onzekerheid is de standaard
Bij open source software zoals WordPress werk je altijd met onzekerheid.
Je hebt geen controle over de volledige keten: thema’s, plugins, PHP, hosting en externe afhankelijkheden.
Daarom is “het zal wel werken” een gevaarlijke aanname.
In de praktijk ga je uit van het tegenovergestelde:
dat iets níet vanzelf goed gaat. Vertrouwen is goed, controleren is beter!
Testen als mentale zekerheid
Testen is geen technische fase, maar een manier om onzekerheid zichtbaar te maken.
Een testomgeving laat zien:
-
waar afhankelijkheden zitten
-
welke onderdelen kwetsbaar zijn
-
wat er gebeurt als iets breekt
Hoe complexer de website, hoe minder je kunt vertrouwen op aannames en hoe belangrijker observatie wordt.
Structuur is belangrijker dan snelheid
Snel updaten voelt efficiënt, maar vergroot het risico op verrassingen.
Een gestructureerde aanpak vertraagt bewust, zodat je minder afhankelijk bent van toeval.
Het gaat niet om traagheid, maar om voorspelbaarheid.
Een goed onderhoudsproces richt zich op:
-
zo min mogelijk onverwachte effecten
-
zo veel mogelijk controle over het moment van verandering
Terugkijken als onderdeel van onderhoud
Na een update zit de echte waarde niet in de uitvoering, maar in de evaluatie.
-
Wat ging goed?
-
Waar zat onverwacht risico?
-
Wat zou je volgende keer anders doen?
Zonder dit moment blijft onderhoud reactief. Met dit moment wordt het een lerend systeem.
In de praktijk: voorbereiding is het meeste werk
De voorbereiding bepaalt grotendeels het succes van een update.
Inventarisatie van je systeem
Je brengt alle onderdelen in kaart:
-
WordPress versie
-
PHP versie
-
database
-
thema
-
plugins
Niet als administratie, maar als basis van begrip: wat beheer je eigenlijk?
Welke versies worden ondersteund?
Je controleert per onderdeel of het nog binnen de ondersteuningscyclus valt.
Bronnen zoals end-of-life overzichten geven richting, maar geen zekerheid.
Belangrijker is de vraag:
is deze combinatie nog verantwoord?
Compatibiliteit is geen zekerheid
Software werkt zelden als simpele optelsom.
Je zit altijd tussen twee uitersten:
-
nieuwste versie → toekomstgericht maar onzeker
-
oudere stabiele versie → betrouwbaar maar tijdelijk
De juiste keuze zit meestal daartussenin: stabiel én actief ontwikkeld.
Testen: vertrouwen vervangen door observatie
Open source betekent geen garantie.
Daarom is een testomgeving essentieel.
Daar voer je dezelfde update uit en kijk je niet alleen of het werkt, maar vooral:
-
wat verandert er
-
wat breekt er
-
wat gedraagt zich anders
In de praktijk test je vooral de kritieke flows van je website.
Uitvoering: voorspelbaarheid in plaats van verrassing
Als voorbereiding klopt, wordt uitvoering een gecontroleerd proces.
Je werkt stap voor stap, controleert per wijziging en kiest een geschikt moment voor livegang.
Niet om het spannend te maken, maar om het voorspelbaar te houden.
Terugblik: onderhoud als leersysteem
Na livegang kijk je terug:
-
wat werkte goed
-
wat verraste je
-
wat moet anders
Zo wordt onderhoud geen herhaling van zetten, maar een steeds slimmer proces.
Ten slotte
“Goed gedaan jongen. En hou het gewoon bij.”
Zo zou mijn Pa het gezegd hebben. Misschien is dat uiteindelijk de kern van goed onderhoud: niet het uitvoeren zelf, maar het consequent bijhouden van alles wat al werkt—met aandacht voor wat er onder de oppervlakte verandert.
En jij?
Onderhoud jij het allemaal zelf? Voer jij de upgrades zelf uit? Toch wel eerst in een testomgeving he? Schouderklopje na afloop? Blik jij ook wel eens terug om van te leren? Of is het bij jou echt maar een druk op de knop?
Hier was het ongeveer een halve werkdag om op WordPress 7.0 en PHP 8.5.7 te belanden met 1 thema en 13 plugins. Het vroeg een tijdsinspanning van 2 uur aan voorbereiding, 1/2 uur voor de uitvoering, en testen 1,5 uur.