Oppdatere WordPress trygt: backup, staging og rollback

Offisiell veiledning: Updating WordPress. For herding av miljøet rundt: Hardening WordPress.

#Hva oppdateringer faktisk gjør

Hver WordPress-utgivelse er mer enn et versjonsnummer i dashbordet.

#Sikkerhet

Core, plugins og temaer får rettelser for sårbarheter som allerede er offentlige. Når en CVE er kjent, skanner roboter nettet etter nettsteder som fortsatt kjører den gamle versjonen. Å «vente til det er roligere» er ofte det samme som å gi skannerne mer tid. Threat-intel fra blant andre Wordfence viser samme mønster om og om igjen: utdatert programvare er den vanligste inngangen, ikke et avansert zero-day-angrep mot akkurat din bedrift.

#Ytelse og PHP

Nyere core bruker nyere PHP-funksjoner mer effektivt og fjerner gammel kode. Hosting i Norge (Domene.no, Domeneshop, Loopia, Contabo/VPS, egne servere) skrur jevnlig av eldre PHP. Blir du stående på WordPress som krever 7.4 mens hosten bare tilbyr 8.2, får du fatal errors uten at noen «angrep» deg.

#Funksjoner og blokker

Block editor, patterns og theme.json endrer seg mellom major-versjoner. Plugins som antar gamle APIer begynner å advare eller krasje. Oppdaterer du jevnlig, er hoppene små. Oppdaterer du to år i strekk, blir det ett stort sjansespill.

#Hva som skjer når du lar det ligge

Typisk forløp på norske SMB-sider vi ser i support:

1. Core er 18 måneder gammel, WooCommerce tre minor bak, Elementor eller et skjemaplugin er «pinnnet» fordi «det funket».
2. Hosten varsler PHP-oppgradering. Noe knekker.
3. Noen trykker Oppdater alt. Hvit skjerm. Ingen fersk backup.
4. Gjenoppretting tar en helg og koster mer enn et år med rolig vedlikehold.

Konkrete konsekvenser:

• Innbrudd og spam - bakdører i wp-content/uploads, spam-kontoer, SEO-spam i sider du ikke redigerer.
• Kompatibilitetsbrudd - én plugin oppdateres (sikkerhetskrav fra leverandør), resten er gamle, fatal error i autoload.
• Tap av tillit - Vipps-checkout eller Contact Form 7 som feiler midt i kampanje.
• Dyrere fix - jo flere versjoner du hopper, jo flere migreringer i databasen må du forstå samtidig.

#Oppdateringsrekkefølge som reduserer drama

En fornuftig rekkefølge på produksjon (etter staging):

1. Backup - filer + database. Verifiser at filen lar seg pakke ut / importere, ikke bare at den ligger i «Backups»-mappen.
2. Core til siste stabile (eller sist testede på staging).
3. Plugins - sikkerhetskritiske først, deretter betaling og medlemskap, til slutt «kosmetikk».
4. Tema - child theme sist hvis det avhenger av parent-oppdateringer.
5. Smoke-test - forside, /wp-admin/, ett skjema, én handlekurv/Vipps eller Klarna hvis du har nettbutikk, eventuell innlogging for medlemmer.

Unngå «Oppdater alle» på travle butikker. Batch i grupper, med fem minutter observasjon mellom.

#Backup, staging og rollback

Backup: UpdraftPlus, BlogVault, hostens snapshot, eller wp db export + rsync av wp-content. Det som teller er at du har prøvd en restore én gang i året. Utestet backup er et håp, ikke en plan.

Staging: Samme PHP-versjon som produksjon, samme plugins. Oppdater der først. Mange norske byråer kjører staging som underdomene (staging.bedrift.no) med HTTP-auth slik at Google ikke indekserer den.

Rollback:

• Plugin/tema: WP Rollback eller last opp gammel ZIP.
• Core: wp core update --version=x.y.z --force eller filer fra wordpress.org/releases uten å overskrive wp-content.
• Database allerede migrert: full restore av dump fra før oppdateringen.

Les mer om nedgradering i søsterartikler om rollback hvis du står midt i en krise - poenget her er at rollback er del av oppdateringsvanen, ikke noe du finner opp når alt ligger nede.

#Automatiske oppdateringer: hva som er greit

WordPress kan auto-oppdatere mindre core-releases. Det er ofte fornuftig på brosjyre-sider.

La stå manuelt:

• WooCommerce og betalingsplugins (Vipps, Klarna, Nets)
• Page builders
• Membership / LMS
• Alt som rører ordre, persondata eller booking

Skru av auto-update for plugins du har sett knuse staging. Dokumenter i en enkel vedlikeholdslogg: dato, versjon fra/til, hvem som godkjente.

#Norske særtrekk verdt å huske

• Vipps og betaling: test alltid etter plugin-oppdatering, ikke bare forsiden.
• Personvern: backup av kundeordrer er personopplysninger - lagre dem etter egen rutine (tilgangsstyring, slettpolicy), ikke i en åpen Google Drive-mappe.
• Bokmål-innhold og caching: etter core-oppdatering, tøm object cache og CDN (Cloudflare) så du ikke debugger gammel HTML.
• Byrå vs in-house: avklar hvem som eier oppdateringsvinduet. «Ingen» er den vanligste årsaken til at sider blir stående to år bak.

#Kort sjekkliste før du trykker Oppdater

1. Backup filer + DB i dag, ikke «i går tror jeg».
2. Staging oppdatert og smoke-testet, eller aksept for risiko på lavtrafikk-side.
3. Vedlikeholdsmodus eller lavtrafikk-vindu for butikk.
4. Liste over kritiske URL-er å klikke etterpå (forside, login, skjema, Vipps/Klarna).
5. Kjent rollback (ZIP / WP-CLI / restore) på samme maskin som du jobber fra.
6. Slack- eller e-postvarsel til den som eier nettstedet når vinduet er ferdig.

#Når det er greit å vente (og når det ikke er det)

Ikke alt haster like mye. Et sikkerhetsfix i et skjemaplugin som er aktivt på forsiden går foran en ny Gutenberg-blokk du ikke bruker. Omvendt: å sitte på en WooCommerce-versjon med kjent sårbarhet fordi «vi har kampanje neste uke» er å gamble omsetning mot innbrudd.

Tommelfingerregler vi bruker på norske driftsavtaler:

• Samme dag / neste vedlikeholdsvindu: CVE med offentlig exploit i aktiv plugin eller core.
• Innen en uke: vanlige plugin-oppdateringer uten breaking changes, testet på staging.
• Planlagt major: core 6.x → 6.y, WooCommerce major, PHP-bytte hos host - egen sak med rollback-plan og gjerne et lavtrafikk-vindu (tirsdag formiddag slår fredag 16:00).

Vipps, Klarna og Nets-plugins: oppdater dem sammen med WooCommerce på staging, ikke hver for seg i produksjon uten smoke-test av betaling. Én mislykket callback etter en stille auto-update er dyrere enn en halvtime med sjekkliste.

#Hosting, PHP og det dashbordet ikke forteller deg

WordPress-dashbordet sier at en oppdatering er tilgjengelig. Det sier sjelden at hosten din slår av PHP 8.0 neste måned. Sjekk kontrollpanelet (eller spør support) hvilken PHP-versjon som kjører, og sammenlign med kravene i Updating WordPress og i plugin-readmes.

Typisk norsk hosting-bilde:

• Delte planer som sakte skyver alle til PHP 8.2/8.3
• VPS der du selv glemmer å oppdatere PHP mens WordPress allerede krever nyere
• Object cache (Redis) som serverer gammel HTML etter oppdatering til du tømmer den

Etter oppdatering: tøm Redis/Memcached hvis du har det, og Cloudflare-cache for HTML hvis CDN står foran. Debug ellers «feil som bare noen ser» i en time. Noter også om WP_DEBUG_LOG sto på under test - glemte debug-logger på produksjon er en klassiker etter hastverk.

#Vedlikeholdsavtale vs. adrenalin

For en brosjyre-side kan en kyndig eier kjøre sjekklisten selv en gang i måneden. For nettbutikk, medlemskap eller sider med persondata lønner det seg å ha:

• fast oppdateringsvindu (for eksempel første tirsdag i måneden)
• staging som speiler produksjon
• logging av hva som ble oppdatert (versjon fra → til)
• en person som eier beslutningen «vent» vs «kjør nå»

Uten eierskap blir oppdateringer noe alle skyver foran seg til noe knekker. Det er den vanligste grunnen til at «er det verdt å oppdatere?» plutselig blir «kan dere fikse dette i helgen?». En skriftlig rutine på én side (backup-sti, staging-URL, rollback-kommando) er billigere enn den helgen.

#Oppsummering

Det er verdt å oppdatere WordPress fordi alternativet er kjente hull, PHP-brudd hos hosten og dyre nødløsninger. Verdien ligger i rutinen: backup, staging, kontrollert rekkefølge, smoke-test og en vei tilbake. La mindre core-fikser gå jevnt; styr store hopp og betalingsstacken selv.

Vil du ha vedlikehold og oppdateringsvindu som en fast del av driften i stedet for adrenalin hver gang dashbordet blinker, ta kontakt - vi setter opp backup, staging og en oppdateringsplan tilpasset WordPress-stacken din.