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. WordPress kjører på 40,0 % av alle nettsteder ifølge W3Techs (lest 14.10.2026), så skannerne har mange mål å velge blant. Å «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 skjer hvis du ikke oppdaterer WordPress

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.

#Hvor sårbarhetene i WordPress faktisk ligger

Patchstacks årsrapport for 2024, State of WordPress Security in 2025, teller 7966 nye sårbarheter i WordPress-økosystemet det året. Fordelingen viser hvor risikoen sitter:

Den samme rapporten påpeker at 33 % av sårbarhetene ikke hadde noen rettelse da de ble offentliggjort, mange av dem i forlatte plugins som sannsynligvis aldri blir rettet, og at det er vanlig at en sårbarhet utnyttes i løpet av timer etter at den ble kjent.

To praktiske konklusjoner. For det første: å oppdatere bare core er ikke nok, fordi nesten all risiko ligger i utvidelsene. For det andre: en plugin som ikke har fått en ny versjon på lenge er ikke «stabil», den er en kandidat for en sårbarhet som aldri blir rettet. Å sjekke datoen for siste utgivelse av hver plugin er like mye vedlikehold som å trykke Oppdater.

#Hvilke WordPress-versjoner får sikkerhetsoppdateringer

Sikkerhetssiden til WordPress.org (About security) sier at bare den nyeste versjonen av WordPress er offisielt støttet. Sikkerhetsteamet tilbakefører rettelser til eldre grener som en tjeneste, slik at nettsteder som ikke har tatt steget til siste hovedversjon likevel får kritiske patcher via automatiske oppdateringer.

To eksempler med dato viser hvordan det fungerer:

• WordPress 6.4.3 (30. januar 2024) rettet en omgåelse av PHP-filopplasting via plugin-installasjonen (krevde administratorrettigheter) og en RCE-sårbarhet via POP-kjeder. Utgivelsen hadde også 5 core-rettelser og 16 rettelser i blokkredigeringen, og patchene ble tilbakeført til alle grener fra 4.1 og nyere (utgivelsesnotat).
• WordPress 6.5.5 (24. juni 2024) rettet to XSS-sårbarheter (i HTML API og i blokken Template Part) og et path traversal-problem på nettsteder som kjører på Windows (utgivelsesnotat).

Begge utgivelsesnotatene minner om at oppdateringen starter av seg selv på nettsteder med automatiske bakgrunnsoppdateringer. Det er det sterkeste argumentet for aldri å skru av mindre oppdateringer: patchen kommer fram selv om ingen logger inn i dashbordet.

#I hvilken rekkefølge oppdatere WordPress og plugins

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.

#Visuell regresjonstest

På forretningskritiske nettsteder holder det ikke å kikke raskt over forsiden. Verktøy for visuell regresjonstest som Percy eller BackstopJS sammenligner skjermbilder før og etter oppdateringen og fanger små endringer i layouten som et raskt blikk overser: en knapp som har flyttet seg noen piksler, en endret marg, en annen farge. Det er særlig viktig etter oppdatering av tema eller page builders som Elementor, Divi eller WPBakery, fordi de styrer utseendet på hver eneste side.

#Hva WordPress gjør når en plugin-oppdatering feiler

De siste versjonene har core fått to egne sikkerhetsnett for oppdateringer av utvidelser. Det lønner seg å vite hva de dekker og ikke dekker, fordi ingen av dem erstatter backup.

WordPress 6.3: gjenoppretting etter mislykket manuell oppdatering. Ifølge utviklernotatet for 6.3 flytter WordPress den installerte versjonen til wp-content/upgrade-temp-backup/plugins/ eller wp-content/upgrade-temp-backup/themes/ før en plugin eller et tema oppdateres. Feiler installasjonen av pakken (tom pakke, målmappen kan ikke tømmes eller opprettes), flyttes forrige versjon tilbake. Går oppdateringen bra, slettes kopien. Funksjonen oppdager ikke en fatal PHP-feil som dukker opp etter en vellykket installasjon, og mappen er ikke en vei tilbake senere.

WordPress 6.6: tilbakerulling av automatiske plugin-oppdateringer. Feltguiden for 6.6 lister automatisk tilbakerulling av automatiske plugin-oppdateringer når en fatal PHP-feil oppdages. Forslaget om innlemming i core beskriver mekanismen: etter oppdateringen sender WordPress en loopback-forespørsel til forsiden; oppdages en fatal feil, gjenopprettes forrige versjon av pluginen, og administrator-e-posten får beskjed. Nettstedet står i vedlikeholdsmodus mens de automatiske oppdateringene kjører, og pluginen som ble rullet tilbake prøves på nytt ved neste sjekk.

Den viktige begrensningen er selve loopback-forespørselen. Blokkerer serveren den (for eksempel en brannmurregel eller HTTP-autentisering), behandles det ifølge forslaget som en fatal feil, og oppdateringen rulles tilbake. En plugin som bare ødelegger checkout eller en underside blir heller ikke oppdaget, fordi sjekken går mot forsiden. Derfor trenger nettbutikker fortsatt manuell test av betalingen.

#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.

#Slik konfigurerer du automatiske oppdateringer

Den offisielle dokumentasjonen (Upgrading WordPress) forklarer at automatiske bakgrunnsoppdateringer kom med WordPress 3.7, og skiller mellom fire typer: core (utvikling, mindre og store versjoner), plugins, temaer og oversettelsesfiler. Mindre core-oppdateringer og oversettelser er på som standard. Fra WordPress 5.6 får nye installasjoner også store versjoner automatisk, med mindre en versjonskontroll-checkout oppdages. Plugins og temaer oppdateres bare av seg selv i spesialtilfeller som WordPress.org-APIet bestemmer, eller når administratoren slår det på.

Den bryteren per plugin og tema kom med WordPress 5.5, utgitt 11. august 2020: siden da slår du automatiske oppdateringer av og på for hver utvidelse på de samme skjermene for Plugins og Temaer (utgivelsesnotat for 5.5).

Vil du låse policyen i kode, godtar wp-config.php disse konstantene:

// Bare mindre core-oppdateringer (sikkerhet og vedlikehold)
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

// true: utvikling, mindre og store; false: ingen av de tre
// define( 'WP_AUTO_UPDATE_CORE', true );

// Slår av alle automatiske oppdateringer (anbefales ikke)
// define( 'AUTOMATIC_UPDATER_DISABLED', true );

For finere styring finnes filtrene auto_update_plugin og auto_update_theme, og for core allow_major_auto_core_updates og allow_minor_auto_core_updates. Slår du av alt med AUTOMATIC_UPDATER_DISABLED, kutter du nettstedet fra patchene sikkerhetsteamet sender ut nettopp den veien.

#Vipps, personvern og cache ved WordPress-oppdatering

• 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.

#Sjekkliste før du oppdaterer WordPress

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.

#Hvor raskt bør du installere WordPress-oppdateringer

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 fra 6.x til 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.

#Sjekk PHP-versjonen hos hosten før oppdatering

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.

Kravene fra WordPress selv er tydelige. Kravsiden til WordPress anbefaler PHP 8.3 eller nyere, MySQL 8.0 eller MariaDB 10.11 eller nyere, og HTTPS. Minimum er lavere: versjons-APIet til WordPress.org tilbyr WordPress 7.1.3 med PHP 7.4 som minimum. At WordPress starter på PHP 7.4, gjør ikke den PHP-versjonen trygg. Den offisielle PHP-kalenderen (støttede versjoner og grener uten støtte) ser slik ut:

I oktober 2026 betyr det at PHP 8.1 ikke lenger får patcher, og at PHP 8.2 får dem bare ut året. Et nettsted som kjører på 8.2 i dag, bør allerede planlegge overgangen til 8.3 eller 8.4 på staging: oppdater WordPress, plugins og tema til versjoner som oppgir kompatibilitet, test på staging med ny PHP, og bytt PHP i produksjon først etterpå.

#Hva nyere WordPress-versjoner har lagt til

Den som blir liggende flere versjoner bak, mister mer enn patcher. Noen endringer med dato og offisiell kilde:

• WordPress 6.5 (2024) fikk støtte for AVIF: bildene kan lastes opp, redigeres, skaleres og lagres hvis bildebiblioteket på serveren (Imagick eller GD) støtter formatet, og Site Health viser om det er tilgjengelig (utviklernotat).
• WordPress 6.6 (16. juli 2024) innførte den automatiske tilbakerullingen av plugin-oppdateringer beskrevet over.
• WordPress 6.8 (2025) slo på spekulativ lasting i frontend: core gjør prefetch av URL-er med konservativ eagerness, unntatt for innloggede brukere og nettsteder uten pene permalenker, og oppførselen justeres med filteret wp_speculation_rules_configuration (utviklernotat).
• WordPress 6.9 (desember 2025) introduserte Abilities API, et register der core og plugins oppgir hvilke handlinger de kan utføre, med skjemaer og tilgangskontroll.

Moderne plugins begynner å bygge på disse APIene. Et nettsted som står fast på en gammel versjon, kan til slutt ikke oppdatere slike plugins og mister dermed også sikkerhetsrettelsene deres.

#Trenger du vedlikeholdsavtale for WordPress

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 (fra hvilken versjon til hvilken)
• 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.

#Hvordan manglende oppdateringer påvirker SEO

Google har bekreftet at sideopplevelse, inkludert hastighet, er en del av rangeringssignalene. Gamle WordPress-versjoner på utdatert PHP er tregere, og det slår ut i Core Web Vitals, særlig LCP (Largest Contentful Paint) og INP (Interaction to Next Paint).

Et nettsted som er hacket fordi det ikke ble oppdatert, kan i tillegg bli merket som kompromittert i Googles søkeresultater, og da faller klikkraten kraftig. Nettlesere viser sikkerhetsadvarsler når de oppdager skadevare, og skremmer bort besøkende før de ser innholdet. SEO-spam i form av tusenvis av skjulte sider kan gi en manuell handling fra Google, og å komme tilbake krever full opprydding, en forespørsel om ny vurdering og uker eller måneder med venting.

#Hvordan oppdatere flere WordPress-nettsteder samtidig

Har du mange nettsteder, går det ikke å oppdatere hvert enkelt for hånd. Disse verktøyene samler oppdateringene:

• ManageWP styrer oppdateringer for titalls eller hundrevis av nettsteder fra ett dashbord, med automatisk backup før hver oppdatering og visuell kontroll etterpå.
• MainWP er et selvhostet alternativ som kjører som plugin på en sentral WordPress-installasjon og styrer oppdateringene på alle tilkoblede nettsteder.
• InfiniteWP har lignende funksjoner, rettet mot byråer med mange nettsteder.

Verktøyene lar deg planlegge oppdateringer, oppdatere selektivt, lage rapporter til kunder og rulle tilbake når noe går galt.

#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.

På leveransesiden holder vi dette temaet under WordPress-utvikler.