Een webshop bijwerken voelt anders dan een gewone website bijwerken. Bij een brochuresite is een half uur haperen vervelend; bij een shop die vijftig bestellingen per dag verwerkt, is het direct geld en zijn het boze klanten. Precies daarom stellen veel webshopeigenaren updates uit, en precies daarom wordt het risico met de maand groter.

Deze case gaat over een webshop in kantoor- en horeca-inrichting uit de regio Rotterdam. Zeven maanden geen updates uitgevoerd, want er was altijd wel een actie, een beurs of een drukke week. Toen de teller op 47 stond, was uitstellen geen optie meer. Hieronder de aanpak waarmee die 47 WordPress-updates zonder downtime zijn doorgevoerd, inclusief het moment waarop het bijna misging.

De situatie: waarom het spannend was

De shop draaide op WooCommerce met een pagebuilder, ongeveer 900 producten, een koppeling met een pakketdienst, iDEAL via een betaaldienstverlener en een koppeling naar het boekhoudpakket. Dat is een normale opzet, maar wel eentje met veel raakvlakken.

De 47 updates bestonden uit 41 plugins, drie WordPress-kernupdates, het thema en twee updates van de pagebuilder. Onder die 41 zaten er vier die als riskant golden: WooCommerce zelf, de betaalplugin, de verzendkoppeling en de pagebuilder. Dat zijn precies de vier onderdelen waar een fout direct omzet kost.

Er waren twee harde eisen. De shop mocht geen moment onbereikbaar zijn, en er mocht geen enkele bestelling verloren gaan. Dat tweede is subtieler dan het eerste, en het is waar de meeste fouten worden gemaakt.

De voorbereiding

Voordat er iets gebeurde, is er een week aan voorbereiding gegaan. Die week bestond uit vier dingen.

  1. Een volledige back-up van bestanden en database, weggeschreven naar een externe locatie, en daarna daadwerkelijk teruggezet op een testserver om te controleren dat hij compleet was. Een ongeteste back-up is een aanname.
  2. Een testomgeving die echt een kopie was, inclusief alle producten en instellingen, afgeschermd voor zoekmachines, met de betaaldienst in testmodus. Hoe zo’n omgeving werkt, staat in de uitleg over staging.
  3. Een testscript op papier. Twaalf handelingen die na elke ronde werden doorlopen: product zoeken, filter gebruiken, in de winkelwagen leggen, kortingscode invoeren, afrekenen met iDEAL, bevestigingsmail controleren, bestelling in het beheerscherm terugvinden, verzendlabel aanmaken, factuur naar de boekhouding, contactformulier, inloggen als klant, en alles nog eens op mobiel.
  4. Het changelog van de vier riskante plugins gelezen. Daar stond onder meer dat de betaalplugin een minimale WooCommerce-versie eiste. Dat bepaalde de volgorde.

De uitvoering op de testomgeving

Op de kopie zijn de updates in vijf rondes uitgevoerd, van ongevaarlijk naar spannend.

Ronde één: de 24 kleine, onafhankelijke plugins. Vertaalhulpjes, een cookiemelding, een formulierplugin, dat soort werk. Allemaal tegelijk, daarna het testscript. Geen problemen.

Ronde twee: WordPress zelf, in drie stappen naar de laatste versie. Ook geen problemen, wat gebruikelijk is: de kern is goed getest voordat hij uitkomt.

Ronde drie: WooCommerce, apart en met aandacht. Hier kwam de eerste hobbel. WooCommerce had de opslag van bestellingen veranderd en er moest een migratie draaien. Op 900 producten en enkele duizenden bestellingen duurde dat ruim twintig minuten, met een halve site die intussen vreemd deed. Precies het soort ding dat u niet op een live shop wilt ontdekken.

Ronde vier: de betaalplugin en de verzendkoppeling. De verzendkoppeling gaf na de update een foutmelding bij het aanmaken van labels, omdat de nieuwe versie een andere manier van authenticeren gebruikte. Dat kostte een uur uitzoeken en een nieuwe sleutel bij de vervoerder aanvragen. Op de testomgeving was dat een ongemak; live was het een dag zonder verzendlabels geweest.

Ronde vijf: de pagebuilder en het thema. Dat leverde het klassieke euvel op: op drie categoriepagina’s verschoof de productfilter op mobiel, doordat de nieuwe versie een marge anders berekende. Twee regels aanvullende CSS losten het op.

Tussen elke ronde volgde het volledige testscript. Dat klinkt overdreven bij een update van een vertaalplugin, maar juist door consequent te testen weet u precies welke ronde iets veroorzaakte.

De live-uitvoering

Nadat de testomgeving twee dagen zonder klachten had gedraaid, is de live shop aan de beurt gekomen. Dat gebeurde op een dinsdagochtend om zes uur, het rustigste moment van de week volgens de eigen statistieken. Niet ‘s nachts: er moest wel iemand bereikbaar zijn bij de betaaldienst en de vervoerder.

De shop is niet in onderhoudsmodus gezet. In plaats daarvan zijn dezelfde vijf rondes doorlopen, nu in de wetenschap dat ze werkten en met de oplossingen voor de verzendkoppeling en de CSS al klaar. De hele operatie duurde iets meer dan twee uur. In die tijd zijn er drie bestellingen binnengekomen, die alle drie normaal zijn verwerkt.

Het enige echt spannende moment was de databasemigratie van WooCommerce. Die is bewust als eerste van de ochtend gedraaid, met de shop tijdelijk in de stand waarin klanten wel konden kijken maar de kassa even niet doorliep. Dat duurde achttien minuten en viel binnen een periode waarin er statistisch gezien vrijwel nooit een bestelling binnenkomt.

Wat er te leren valt

Drie dingen maakten het verschil, en ze zijn overdraagbaar naar elke webshop.

De kopie is niet optioneel. Alle drie de problemen zijn op de testomgeving gevonden. Zonder die omgeving waren dit drie storingen op een draaiende shop geweest, met bij elkaar makkelijk een halve dag verstoring en een onbekend aantal afgehaakte klanten.

De volgorde volgt uit de afhankelijkheden. Eerst het onschuldige, dan de kern, dan het platform, dan de koppelingen, dan de opmaak. Wie de betaalplugin bijwerkt voordat WooCommerce bij is, vraagt om problemen.

Zeven maanden wachten was de duurste keuze. Waren die 47 updates verspreid over zeven maandelijkse rondes uitgevoerd, dan was het per keer een halfuur werk geweest met hooguit één ding om uit te zoeken. Nu was het bij elkaar ruim twee dagen. Dat is de rekensom achter structureel onderhoud in een vast ritme, en het is precies waarom WebMaintor bij shops met dagelijkse omzet standaard op een testomgeving werkt.

Heeft u een shop waarvan de updateteller al maanden oploopt, begin dan niet met bijwerken maar met een kopie. Zet uw testscript op papier, al is het maar een lijstje van tien handelingen, en werk daar de eerste ronde af. Wat u daar tegenkomt, komt u anders live tegen. En bedenk hoe vaak u dit ritme wilt herhalen; een realistisch schema staat in het artikel over updatefrequentie.