Veel websites worden met zorg gebouwd en daarna nooit meer aangeraakt. Ze blijven gewoon werken, dus lijkt er niets aan de hand. Tot je onder de motorkap kijkt.
Onlangs kreeg ik zo'n site onder handen: de portfoliosite van een grafisch ontwerper, met een eigen thema op maat. Hieronder lees je hoe ik die update aanpakte, wat ik eerst onderzocht en waarom ik in kleine stappen werkte.
Het vertrekpunt: zeven jaar stilstand
De site zag er voor bezoekers prima uit. Maar achter de schermen draaide ze op software die al lang geen beveiligingsupdates meer kreeg.
| Onderdeel | Stand bij de start |
|---|---|
| WordPress | 5.1, een testversie uit begin 2019 |
| PHP (de programmeertaal op de server) | 7.0, sinds 2019 niet meer ondersteund |
| Advanced Custom Fields Pro | versie uit 2018, alle inhoud draait erop |
| Thema | op maat gemaakt, nooit getest met nieuwere versies |
In de logboeken van de server zag ik bovendien dat er actief geprobeerd werd om binnen te raken: inlogpogingen met brute kracht en pogingen via een recent bekend WordPress-lek. De hosting hield die tegen, maar een site op een zeven jaar oude versie is een makkelijk doelwit.
Eerst onderzoeken, dan pas updaten
Bij een site die lang heeft stilgestaan, klik je niet zomaar op "Nu bijwerken". Hoe groter de sprong, hoe groter de kans dat er iets breekt. Daarom bekeek ik eerst:
- Welke versies er draaien: WordPress, PHP, het thema en elke plugin.
- Waar de inhoud in zit: hier zat alles in Advanced Custom Fields Pro, ook de projecten, de beelden en de teksten van het infoluik. Breekt die plugin, dan is de site leeg.
- Of de code nieuwere PHP aankan: ik liet de pagina's proef draaien op nieuwere PHP-versies, zonder de live site aan te raken.
- Wat de klant wil behouden: een paar oude plugins bleven op vraag van de klant gewoon staan.
Back-up voor elke stap
Voor ik ook maar iets veranderde, maakte ik een volledige back-up van de database en alle bestanden. Die bewaar ik op twee plaatsen: op de hosting zelf en op een aparte server. Loopt de hosting mis, dan is er nog een kopie.
Belangrijker nog: voor elke volgende stap kwam er een nieuwe back-up bij. Zo kan ik altijd terug naar de laatste goede toestand, niet naar die van een week eerder.
De update in vijf kleine stappen
Recente WordPress-versies werken niet meer op PHP 7.0. En een heel oud thema kan haperen op de nieuwste PHP. Daarom ging het niet in één sprong, maar zo:
- WordPress naar 6.5: de hoogste versie die nog op PHP 7.0 draait.
- PHP naar 7.4: ingesteld in het controlepaneel van de hosting.
- WordPress naar de nieuwste versie, inclusief de update van de database.
- PHP naar 8.5, de huidige versie.
- Opslaan testen in de beheeromgeving, door de eigenaar zelf.
Na elke stap testte ik alles en pas na een akkoord ging ik verder. Dat lijkt traag, maar het is net sneller: als er iets misgaat, weet je meteen welke stap de oorzaak is.
Hoe ik test na elke stap
Voor de eerste wijziging maakte ik een nulmeting. Na elke stap draaide ik exact dezelfde controle en vergeleek ik het resultaat:
- de homepage op computer, gsm en tablet, met screenshots;
- of alle projecten en alle beelden er nog staan;
- het infoluik, de links en een losse projectpagina;
- foutmeldingen in de browser en in het foutenlogboek van de server;
- de beheeromgeving: projecten bewerken, de instellingen en de mediabibliotheek.
Tijdens één update gaf de site ongeveer 25 seconden een foutmelding, terwijl de nieuwe bestanden gekopieerd werden. Dat is normaal en het herstelt vanzelf. Daarom werk ik bij voorkeur 's avonds, als er weinig bezoekers zijn.
Het resultaat
In één avond ging de site van WordPress 5.1 en PHP 7.0 naar de nieuwste WordPress en PHP 8.5. Voor bezoekers en in de beheeromgeving ziet alles er exact hetzelfde uit als voordien. Het verschil zit onder de motorkap: de site krijgt weer beveiligingsupdates en is klaar voor de komende jaren.
Wat je zelf kan nakijken
Wil je weten hoe jouw site ervoor staat? Log in op je WordPress en kijk op het dashboard en bij Extra en dan Sitediagnose. Daar zie je je WordPress-versie en krijg je een melding als je PHP-versie verouderd is. Staan er updates klaar die je al maanden uitstelt, dan is het tijd om er iets aan te doen.
Kleine updates kan je vaak zelf doen, zeker als je eerst een back-up neemt. Heeft je site jaren stilgestaan, draait ze op een thema op maat of zit je inhoud in plugins zoals Advanced Custom Fields, dan laat je de sprong beter begeleiden.
Updates voortaan uit handen geven
Zo'n inhaalbeweging is te vermijden. Met maandelijks onderhoud blijven WordPress, je thema en je plugins bij, met een back-up voor elke update. Dat kost € 90 per maand inclusief hosting bij mij, of € 60 per maand als je je eigen hosting houdt.
Is je site meer dan alleen verouderd en wil je ze ook opfrissen? Lees dan wanneer je website toe is aan vernieuwing of bekijk wat ik doe bij een website vernieuwen. Bellen kan ook: 0498/90.37.02.
Veelgestelde vragen
Kan een WordPress-update mijn site kapotmaken?
Dat kan, zeker bij een grote sprong of een thema op maat. Daarom werk ik met een back-up voor elke stap, test ik na elke stap en update ik in kleine stappen. Loopt er iets mis, dan zet ik de vorige toestand terug.
Moet ik mijn PHP-versie ook updaten?
Ja. Een verouderde PHP-versie krijgt geen beveiligingsupdates meer en recente WordPress-versies werken er niet op. Je stelt de PHP-versie in bij je hosting, maar test daarna altijd je site.
Ziet mijn site er na de update anders uit?
Nee, een update verandert de software onder je site, niet het ontwerp of de inhoud. Bij een goede update merken bezoekers niets.