Twee keer per jaar, soms drie keer, verschijnt er een nieuwe hoofdversie van WordPress. Op uw dashboard ziet u een blauwe balk met de vraag of u nu wilt bijwerken. De meeste ondernemers klikken, wachten dertig seconden en gaan verder met hun dag. Meestal gaat dat goed. Maar een grote versie is iets anders dan een kleine beveiligingsupdate, en het verschil bepaalt hoeveel aandacht u eraan moet geven.
In dit artikel leggen we uit wat een WordPress nieuwe versie doorgaans verandert, welke ontwikkelingen van de afgelopen jaren nog steeds doorwerken op bestaande websites, en welke punten u na een grote update binnen een kwartier kunt controleren. Geen technisch verhaal, wel een nuchter overzicht.
Het verschil tussen 6.8 en 6.8.2
WordPress gebruikt versienummers met twee of drie cijfers. Een sprong van 6.7 naar 6.8 is een hoofdversie: nieuwe functies, aanpassingen aan de editor, soms andere eisen aan uw hosting. Een sprong van 6.8.1 naar 6.8.2 is een onderhoudsrelease: bugfixes en beveiligingsreparaties, zonder nieuwe functies.
Dat onderscheid is praktisch belangrijk. Onderhoudsreleases kunt u vrijwel altijd direct installeren, en WordPress doet dat standaard zelfs automatisch. Hoofdversies verdienen een moment van aandacht: een back-up vooraf, een controle van uw plugins en thema, en een blik op de site na afloop. Hoe u dat ritme inricht, leest u in ons artikel over een realistisch updateschema.
Wat er de afgelopen jaren echt veranderde
Wie een website heeft die drie of vier jaar geleden is gebouwd, heeft een aantal grote verschuivingen meegemaakt, ook al viel dat aan de buitenkant misschien niet op.
De blokkeneditor werd volwassen
Sinds WordPress 5.0 is de blokkeneditor (Gutenberg) de standaard. Elke hoofdversie sindsdien heeft die editor uitgebreid: kolommen, groepen, patronen, en later de mogelijkheid om de hele site met blokken op te bouwen. Als uw site nog met de klassieke editor werkt, draait die op een plugin die Automattic nog steeds onderhoudt. Dat is prima, maar het is wel een extra afhankelijkheid.
Blokthema’s naast klassieke thema’s
Nieuwe standaardthema’s zoals Twenty Twenty-Four en Twenty Twenty-Five zijn blokthema’s. Ze werken zonder de vertrouwde menu’s voor widgets en customizer. Uw bestaande klassieke thema blijft gewoon werken; WordPress heeft veel moeite gedaan om oude thema’s niet te breken. Maar wie nieuwe functies verwacht die alleen in blokthema’s zitten, komt bedrogen uit.
Strengere eisen aan PHP
Elke hoofdversie schuift de minimale en aanbevolen PHP-versie een stukje op. Oude PHP-versies krijgen geen beveiligingsupdates meer, en WordPress test er dan ook niet meer op. In onze ervaring zit hier de meest voorkomende oorzaak van problemen na een grote update: de site draait op een PHP-versie die de hosting al jaren niet meer had moeten aanbieden. Hoe u dat controleert en verhoogt, beschrijven we in de uitleg over PHP-versies en WordPress.
Prestaties en beveiliging onder de motorkap
Veel veranderingen ziet u niet: slimmer laden van scripts en stijlen, betere caching van databasevragen, lazy loading van afbeeldingen als standaard, en een lange reeks kleine reparaties. Dit is precies waarom een verouderde WordPress-kern niet alleen een beveiligingsrisico is, maar ook trager is dan nodig.
Wat u na een grote update controleert
De update zelf duurt een halve minuut. De controle daarna is waar het om gaat. Loop deze punten na, bij voorkeur in een privévenster van uw browser zodat u geen oude cache ziet:
- Voorpagina en drie belangrijke pagina’s. Laadt alles, kloppen de lettertypen, staan de afbeeldingen op hun plek?
- Menu en footer. Zijn alle menu-items er nog en wijzen ze naar de juiste pagina’s?
- Contactformulier. Stuur een testbericht en controleer of het aankomt.
- De editor. Open een bestaande pagina, wijzig een woord, sla op. Als de editor wit blijft of blokken als “ongeldige inhoud” markeert, is er een conflict.
- Sitegezondheid. Onder Hulpmiddelen ziet u meldingen over PHP, verlopen certificaten en inactieve plugins.
- Webshop. Voeg een product toe aan de winkelwagen en ga tot aan de betaalstap.
- Beheerbalk en dashboard. Vreemde foutmeldingen bovenaan het scherm wijzen op een plugin die nog niet klaar is voor de nieuwe versie.
Kost u een kwartier. Als een van deze punten misgaat, zet u de back-up terug en zoekt u eerst uit welke plugin of welk thema nog niet bijgewerkt is.
Waarom plugins en thema’s het echte risico zijn
De WordPress-kern zelf is bijzonder goed getest. Duizenden sites draaien wekenlang de bètaversie voordat de definitieve release verschijnt. De problemen ontstaan vrijwel altijd in de laag daarboven: een plugin die een functie gebruikt die WordPress als verouderd heeft gemarkeerd, of een thema dat een aanpassing van vijf jaar geleden nog steeds op een oude manier doet.
Daarom is de volgorde bij een grote update belangrijk. Werk eerst plugins en thema bij, controleer of de site nog goed werkt, en installeer daarna pas de nieuwe WordPress-versie. Pluginontwikkelaars publiceren hun compatibele versies meestal al in de weken vóór de WordPress-release. Op de pluginpagina in uw dashboard ziet u onder “Getest tot” welke versie de ontwikkelaar heeft gecontroleerd. Staat daar een versie van twee jaar geleden, dan is dat een signaal om op te letten.
Een kort voorbeeld uit de praktijk. Een fysiotherapiepraktijk in Zwolle werkte WordPress bij naar een nieuwe hoofdversie. De site bleef werken, maar het online afsprakenformulier toonde opeens een lege pagina. De oorzaak: de formulierplugin was in twee jaar niet bijgewerkt en gebruikte een verouderde manier om scripts te laden. Terugzetten van de back-up, de plugin bijwerken, en de update opnieuw uitvoeren loste het op. Zonder back-up was dit een middag zoeken geweest.
Wachten of direct bijwerken?
Sommige beheerders wachten bewust een week of twee na een hoofdversie. Dat is een verdedigbare keuze: de eerste onderhoudsrelease (bijvoorbeeld 6.8.1) verschijnt meestal binnen enkele weken en repareert de kleine dingen die in de praktijk naar boven kwamen. Wachten heeft wel een grens. Een hoofdversie komt vaak samen met beveiligingsreparaties, en die wilt u niet maanden uitstellen.
Onze werkwijze is eenvoudig: onderhoudsreleases zo snel mogelijk, hoofdversies binnen twee weken, en altijd eerst op een testomgeving als de site een webshop is of veel maatwerk bevat. Wie dat liever niet zelf bijhoudt, kan het onderbrengen in een doorlopend onderhoudscontract waarin die controles standaard zitten. Belangrijker dan wie het doet, is dat het gebeurt en dat er iemand na afloop even kijkt.
Conclusie
Een nieuwe hoofdversie van WordPress is geen reden tot zorg, wel tot een kwartier aandacht. Maak een back-up, werk eerst plugins en thema bij, installeer daarna de nieuwe versie en loop de zeven controlepunten hierboven na. Doe dat consequent, en grote updates worden een routine in plaats van een gok. Begin vandaag met een blik op de pagina Sitegezondheid: die vertelt u in één oogopslag of uw PHP-versie en plugins klaar zijn voor de volgende sprong.



