Een beschikbare update is geen reden om meteen op bijwerken te klikken. Eerst moet duidelijk zijn wat verandert, welke back-up je werkelijk kunt herstellen en welke functies na afloop moeten werken. Maak van elke update een kleine, omkeerbare wijziging met een controle vóór en na.
Download het invulbare werkblad in CSV. Open het lokaal als UTF-8 met een komma als scheidingsteken en vervang de voorbeeldwaarden door je eigen gegevens.
1. Leg de beginsituatie vast
Noteer WordPress-, PHP-, thema- en pluginversies, het tijdstip en de eigenaar van de update. Maak een korte lijst van bedrijfskritische functies: homepage, contactformulier, beheerlogin, downloads en eventueel betalen of boeken. Een screenshot alleen bewijst de achterliggende functie niet.
2. Controleer de back-up als herstelset
Een WordPress-site gebruikt doorgaans bestanden én een database. Leg vast welke set bij elkaar hoort, waar die buiten de live omgeving staat en wie hem kan terugzetten. Een melding dat een back-up klaar is, bewijst geen herstel. Gebruik zo nodig eerst de gids websiteback-up testen.
Controleer of bestanden, uploads, configuratie en database uit hetzelfde tijdvak komen. Bewaar de terugzetinstructie en zorg dat een tweede bevoegde persoon erbij kan. Een archief op alleen dezelfde server, of een database zonder uploads, is geen bruikbaar herstelpad voor deze update.
3. Kies één afgebakende updategroep
Werk niet tegelijk WordPress, PHP, thema en alle plugins bij als je de oorzaak van een fout wilt kunnen aanwijzen. Groepeer alleen onderdelen die aantoonbaar bij elkaar horen. Lees wijzigingsinformatie en compatibiliteitsmeldingen, maar behandel die niet als bewijs voor jouw combinatie.
Een begrensde volgorde is: beginsituatie vastleggen, herstelset controleren, testkopie maken, één updategroep uitvoeren, dezelfde functies opnieuw testen en pas dan een apart productie-besluit nemen. Noteer na iedere stap stoppen of doorgaan. Zo blijft één oorzaak aan één waarneming te koppelen.
4. Test buiten de live site
Gebruik een afgeschermde testkopie als de site omzet, formulieren of andere belangrijke processen draagt. Voorkom echte mails, betalingen en geplande taken. De exacte bediening hangt af van WordPress-, PHP-, thema-, plugin- en hostingversie; leg die combinatie bovenaan je controleblad vast en volg de documentatie die daarbij hoort.
Controleer vóór de update dat de testkopie naar de testdatabase, testmailbox en testintegraties wijst. Een kopie die ongemerkt de live database wijzigt is geen veilige testomgeving.
5. Vergelijk functies vóór en na
Voer dezelfde controles uit met dezelfde testdata. Noteer niet alleen akkoord, maar ook URL, tijdstip, waarneming en bewijs. Een formulier telt pas als geslaagd wanneer het testbericht op de afgesproken testbestemming aankomt; een groene melding in de browser is onvoldoende.
| Controle | Voor de update | Vereist na de update | Bewijs |
|---|---|---|---|
| Homepage | Status 200 en herkenbare tekst | Dezelfde kerninhoud en geen foutmelding | URL, tijdstip en waarneming |
| Formulier | Testbericht bereikt testmailbox | Nieuw bericht bereikt die mailbox precies één keer | Ontvangsttijd zonder persoonsgegevens |
| Download | Bekend bestand opent | Hetzelfde bestand opent en is niet leeg | URL en bestandsgrootte |
| Beheer | Bevoegde tester kan inloggen | Rechten en gekozen beheerhandeling werken | Tijdstip, zonder wachtwoord |
| Foutpad | Onbekende URL geeft bruikbare 404 | Geen 500 of lege pagina | Status en screenshot |
6. Werkvoorbeeld met een afkeuring
Een fictieve brochuresite heeft vijf controles. Na een pluginupdate slagen homepage, download en beheerlogin. Het formulier toont succes maar levert niets af; de foutpagina geeft status 500. Twee van vijf controles falen en drie slagen, dus 3 + 2 = 5. De eigenaar keurt de update af, herstelt de testkopie en onderzoekt één wijziging tegelijk.
In het werkblad staan dezelfde vijf regels. De eigenaar zet eerst de verwachte uitkomst vast, vult daarna de waarneming in en koppelt elke afkeuring aan een herstelactie. De twee regels blijven open totdat de herstelde testkopie weer vijf van vijf controles haalt en een nieuwe updatepoging afzonderlijk is hertest.
7. Beslis, herstel en leg eigenaarschap vast
Ga alleen verder wanneer alle vooraf vereiste functies slagen en een herstelpad beschikbaar blijft. Bij een fout: stop, bewaar de melding en herstel de testomgeving voordat je een andere hypothese probeert.
Een geslaagde test geeft nog geen toestemming voor productie. Wijs daarvoor een uitvoerder en terugzetbeslisser aan, maak vlak ervoor een actuele herstelset en herhaal de vijf controles na de live wijziging. Faalt één vereiste controle, zet dan terug of houd de wijziging buiten gebruik volgens de vooraf gekozen grens; stapel geen tweede update bovenop de fout.
Voor een nieuwe siteopdracht hoort de keuze bij website laten maken; voor structurele taakverdeling en kosten bij websiteonderhoud. Een geslaagde proef voor één versieset blijft een momentopname.