Kort svar: En opdateringspolitik er tre lister og en kalender: AUTO-OPDATÉR det, hvor risikoen er lille og sikkerhedsgevinsten stor (WordPress’ mindre versioner, små veldrevne plugins), OPDATÉR MANUELT MED TEST det, forretningen står på (betaling, booking, sikkerhedsplugins, temaet og større kerneversioner – med backup før og et minutters funktionstjek efter), og kør SIKKERHEDSRETTELSER straks uanset listen. Læg de manuelle i et fast månedligt vindue, frys alt undtagen kritisk i højsæsonen – og notér hver kørsel i ændringsloggen. Så er du hverken den, der aldrig opdaterer, eller den, hvis checkout døde af et ureflekteret klik.
Opdateringer er både dit vigtigste sikkerhedsværn og din største selvforskyldte nedbrudskilde – og uden en politik ender de fleste i en af to grøfter: „vi opdaterer aldrig, det kører jo“ (indtil sitet hackes gennem et to år gammelt hul) eller „vi opdaterer alt med det samme“ (indtil betalingsmodulet knækker en fredag). Politikken er vejen imellem – og den fylder én side.
Gå pluginlisten igennem ÉN gang og placer alt i tre klasser. AUTO: WordPress’ mindre versioner (sikkerheds- og vedligeholdelsesudgivelser – de er konservative og bør køre selv), oversættelser og små plugins uden forretningskritisk rolle fra veldrevne udviklere. MANUEL MED TEST: alt, forretningen står på – WooCommerce og betalingsgateways, booking, formularer, sikkerheds- og cacheplugins, temaet og page builderen samt større kerneversioner; her er en fejl dyrere end fem dages forsinkelse, så de venter på dit vindue. STRAKS: offentliggjorte sikkerhedsrettelser – når et plugin lukker et aktivt udnyttet hul, slår sikkerhedsrisikoen enhver test-forsigtighed, så de køres samme dag, bare med backup først. Tommelfingerregel for tvivlstilfælde: jo tættere på penge og login, desto mere manuel.
Manuel opdatering uden fast tid bliver aldrig-opdatering, så giv den et VINDUE: et månedligt kvarter-til-en-halv-time i årshjulets månedsrutine – læg det på et roligt tidspunkt i ÅBNINGSTIDEN (ikke fredag kl. 16: fejler noget, vil du have både vågen tid og support-åbningstider foran dig). Kør opdateringerne i bidder frem for alle på én gang – opdaterér, genindlæs, næste – så en fejl kan spores til én ændring i stedet for femten. Og respektér FRYS-PERIODERNE: i højsæsonen (webshoppens november-december, kursusudbyderens tilmeldingsuger) køres kun sikkerhedsrettelser og kritiske fejl – nye funktioner og „nice to have“-versioner venter, til stilheden er tilbage. Frys er ikke dovenskab; det er respekt for, at ændringer er største nedbrudskilde, og at højsæson er dårligste tidspunkt.
Testen skal være lille nok til at blive gjort: FØR vinduet sikrer du dig ROLLBACK-PARATHED – en frisk backup (eller vished om, at nattens automatiske findes og kan gendannes; selve øvelsen står i backup-testen) – og skimmer changelog-noterne for de kritiske plugins: står der „major“, „breaking“ eller „ny arkitektur“, planlægges den særskilt. EFTER hver bid kører du minimumstesten: forsiden, én indholdsside og forretningens NØGLEFUNKTION (læg en vare i kurven og nå betalingssiden; send testformularen; book en testtid) – to minutter, der fanger næsten alt. Driver du noget større eller mere skrøbeligt, så løft de kritiske opdateringer til et STAGING-miljø først; til de fleste små sites er disciplinen backup + bidder + minimumstest den rigtige balance mellem grundighed og gennemførlighed.
Politikken virker først, når den ligger UDEN FOR dit hoved: skriv de tre klasser, vinduet og frys-perioderne ind i driftsdokumentationen (så en vikar eller aflaster følger samme linje), og notér hver kørsel i ændringsloggen med dato og hvad der blev opdateret – når noget fejler „ud af det blå“ tre dage senere, er den notits fejlfindingens første og ofte sidste opslag. Sæt samtidig plugin-HYGIEJNEN i system: inaktive plugins og temaer er angrebsflade uden funktion – de SLETTES, ikke bare deaktiveres – og hvert nyt plugin optages kun efter site-inventarets spørgsmål: vedligeholdt? nødvendigt? hvem betaler licensen?
Halvdelen af politikken kan flyttes ned i fundamentet: på WordPress-hosting hos Hostious håndteres opdateringer og daglig backup som en del af driften, så auto-klassen kører uden dig, rollback altid er mulig – og din egen indsats koncentreres om det, kun du kan: at teste NØGLEFUNKTIONEN efter de kritiske opdateringer og beslutte, hvornår frysen gælder. Detaljerne i selve opdaterings-håndværket – staging, rollback-teknik, fejlfinding når en opdatering går galt – ligger i sikkerheds- og backup-hubben; denne politik er laget over: beslutningerne, taget én gang, så hver opdatering derefter bare er rutine.
Nej – kun for små, ukritiske plugins og WordPress’ mindre versioner. Betaling, booking, sikkerhed, tema og page builder opdateres manuelt i et fast vindue med backup før og funktionstest efter.
Auto-klassen løbende, det manuelle vindue månedligt – og offentliggjorte sikkerhedsrettelser samme dag, uanset kalenderen. I højsæson fryses alt undtagen det kritiske.
Minimum: forsiden, én indholdsside og forretningens nøglefunktion (kurv-til-betaling, formular eller booking). To minutter pr. bid fanger næsten alle fejl, mens årsagen stadig er indlysende.
