WordPress-oppdateringer gjør jeg som del av det tekniske vedlikeholdet, etter en fast tidsplan: først en full sikkerhetskopi, så oppdatering på en testkopi av nettstedet (staging), tester, sammenligning av skjermbilder fra før og etter endringen, og først da publisering i produksjon i et avtalt vindu. Jeg installerer ikke hver ny versjon automatisk. Kritiske sikkerhetsrettinger går foran i køen, men også de går gjennom testmiljøet.
Denne siden viser hvor ofte jeg oppdaterer hva, hvordan én oppdateringsrunde foregår, hva jeg gjør når noe slutter å virke etter en oppdatering, og hvordan oppdateringer fungerer i en butikk med Vipps og EHF-fakturering, på en sidebygger og i systemer utenfor WordPress. Hele vedlikeholdstjenesten, med sikkerhetskopier og overvåking, er beskrevet på siden om vedlikehold av WordPress-nettsider.
Hvor ofte jeg oppdaterer WordPress
Tidsplanen ved vedlikehold av ett nettsted. For en nettbutikk avtaler jeg vinduene separat.
Hver uke
- Mindre rettinger og sikkerhetsutgivelser for kjerne, utvidelser og temaer
- Oppdatering via WP-CLI på en klon i testmiljøet
- Test av de viktigste flytene og sammenligning av skjermbilder
- Publisering i produksjon i et avtalt vindu
Hver måned
- Gjennomgang av hovedversjoner av utvidelser og endringsloggene deres
- Beslutning: oppdatere nå eller holde versjonen tilbake
- Gjennomgang av administratorkontoer
- Måling av Core Web Vitals etter endringene
Hvert kvartal og hvert halvår
- Kvartalsvis: gjennomgang av listen over utvidelser og fjerning av forlatte
- Hvert halvår: sikkerhetsgjennomgang av filintegritet, administratorkontoer, rettigheter og eksponerte endepunkter
- Hvert halvår: sammenligning av testmiljø og produksjon
- Overgang til nyere PHP-versjon: etter plan, når utvidelser og tema er klare
WordPress-oppdatering utenom tidsplanen: sikkerhetsrettinger
En kritisk sikkerhetsretting venter ikke på den ukentlige syklusen. Den går først, for seg selv, men samme vei: kopi, testmiljø, test, publisering. Det nøyaktige vinduet for slike rettinger skriver jeg inn i tilbudet, fordi det avhenger av hvilken responstid planen din har.
Kunnskapen om sårbarheter henter jeg fra sårbarhetsdatabaser, blant annet Patchstack og WPScan. Når en sårbarhet dukker opp i en utvidelse du har på nettstedet, sjekker jeg om det finnes en rettet versjon, og om sårbarheten treffer ditt oppsett.
Sikkerhetsteamet i WordPress består av mer enn 50 betrodde eksperter, blant dem hovedutviklere og sikkerhetsforskere. Ifølge den samme siden er det bare den nyeste versjonen av WordPress som er offisielt støttet, og rettinger til eldre grener overføres som en tjeneste. Et nettsted som står flere versjoner bak, kan derfor bli stående uten retting.
Slik foregår én oppdateringsrunde
Samme rekkefølge for kjerne, utvidelser, temaer og PHP. Det er bare omfanget av testene som endrer seg.
Full sikkerhetskopi
Før noen endring tar jeg en full kopi av database og filer. Kopien er punktet jeg går tilbake til hvis noe går galt i produksjon.
Oppdatering i testmiljø
Oppdateringene går først til en klon av nettstedet, via WP-CLI. Hovedversjoner av utvidelser går først etter at jeg har lest endringsloggen.
Tester på klonen
Jeg sjekker de viktigste flytene på nettstedet: skjemaer, innlogging, og i en butikk handlekurv og betaling. Når en test feiler, går endringen ikke videre.
Sammenligning av skjermbilder
Jeg tar skjermbilder av utvalgte undersider før og etter oppdateringen og sammenligner dem. En forskjøvet layout, en knapp som er borte eller en annen skrifttype ser jeg her, før en besøkende gjør det.
Publisering i vedlikeholdsvindu
Endringen går til produksjon i et avtalt vindu, med et øyeblikksbilde og en ferdig plan for tilbakerulling.
Oppfølging etter publisering
I 24 timer etter publisering følger jeg ekstra godt med på bivirkninger. Oppetidsovervåkingen sjekker nettstedet hvert 1. til 5. minutt.
Ført inn i rapporten
Oppdateringer, feil som ble oppdaget og eventuelle tilbakerullinger kommer med i den månedlige rapporten.
Et eksempel fra i år: WP Rocket 3.23.2.2 gikk på klonen før jeg oppdaterte nettstedet til WordPress 7.1. Feilen og løsningen er beskrevet i artikkelen WP Rocket, fatal feil i WordPress 7.1 og Cloudflare.php.
Sammenligning av skjermbilder etter oppdatering
En funksjonstest sjekker at skjemaet sendes og at handlekurven tar imot en vare. Den legger ikke merke til at headeren dekker menyen på mobil etter en temaoppdatering, eller at sidebyggeren har endret avstandene i prisseksjonen. Derfor sammenligner jeg etter hver oppdatering skjermbilder av utvalgte undersider fra før og etter endringen. Listen over undersider avtaler vi ved oppstart av vedlikeholdet: forsiden, de viktigste tjenestesidene, skjemaet, og i en butikk produktsiden, handlekurven og kassen.
Når sammenligningen viser en forskjell, sjekker jeg om den kommer av en planlagt endring. Hvis ikke, blir oppdateringen liggende i testmiljøet mens jeg finner årsaken. Til produksjon går bare en versjon som ser lik ut, eller som skiller seg ut på en måte du vet om.
Oppdatering av PHP i vedlikeholdet
Overgang til en nyere PHP-versjon er del av vedlikeholdet, uten eget tilbud. Jeg planlegger den i god tid, fordi den avhenger av tre ting: om webhotellet tilbyr den nyere versjonen, om alle utvidelser og temaet støtter den, og om nettstedets egen kode bruker funksjoner som er fjernet i nyere PHP. Først kjører jeg en klon av nettstedet på den nyere PHP-versjonen, så går jeg gjennom tester og sammenligning av skjermbilder, og først deretter bytter jeg versjon i produksjon, i et avtalt vindu.
WordPress anbefaler PHP 8.3 eller nyere, MariaDB 10.11 eller MySQL 8.0, og støtte for HTTPS. Ifølge versjonstjenesten til WordPress.org er minste PHP-versjon for gjeldende WordPress 7.4. Overgangen til nyere PHP kobler jeg med en gjennomgang av listen over utvidelser, fordi en utvidelse som ikke er oppdatert på lenge, er den første kandidaten til å feile på en nyere versjon.
Hva som knekker etter en oppdatering, og hva jeg gjør da
De vanligste symptomene etter oppdatering av kjerne, utvidelse, tema eller PHP.
- Symptom: Kritisk feil eller hvit skjerm etter oppdatering av en utvidelse
- Hva jeg gjørJeg går tilbake til tilstanden før endringen fra øyeblikksbildet. Årsaken finner jeg på klonen, og den rettede versjonen publiserer jeg i neste vindu.
- Symptom: En underside ser annerledes ut enn før oppdateringen
- Hva jeg gjørSammenligningen av skjermbilder stopper en slik endring i testmiljøet. Har forskjellen kommet til produksjon, ruller jeg tilbake oppdateringen og retter stilen eller holder versjonen tilbake.
- Symptom: Handlekurven eller Vipps-betalingen i butikken slutter å virke
- Hva jeg gjørJeg publiserer ikke en endring som ikke har bestått testen av handlekurven. Dukker feilen opp først i produksjon, ruller jeg tilbake og går tilbake til testmiljøet.
- Symptom: Bestillinger kommer ikke lenger fram til ERP eller regnskapssystemet
- Hva jeg gjørJeg sjekker datautvekslingen mellom butikken og det andre systemet i testmiljøet og holder koblingen på forrige versjon til dataene går riktig gjennom.
- Symptom: EHF-fakturaen blir ikke laget eller avvist etter en oppdatering
- Hva jeg gjørJeg ruller tilbake fakturakoblingen og sender en testfaktura i leverandørens testmiljø til den går gjennom, før versjonen går til produksjon igjen.
- Symptom: En ny versjon av en utvidelse krever endringer i temakoden
- Hva jeg gjørJeg holder versjonen tilbake og beskriver hva som må bygges om. Ombyggingen ligger utenfor vedlikeholdet og får et eget tilbud.
- Symptom: Utvikleren har sluttet å videreutvikle en utvidelse
- Hva jeg gjørVed den kvartalsvise gjennomgangen av utvidelser foreslår jeg en erstatning eller å fjerne den.
- Symptom: Nettstedet endret seg i natt uten at noen bestemte det
- Hva jeg gjørJeg sjekker hvilke automatiske oppdateringer som er slått på, og setter dem opp slik at kritiske deler går gjennom testmiljøet.
Drift av WooCommerce: oppdateringer med Vipps, EHF og ERP
I en WooCommerce-butikk handler oppdateringen om mer enn selve butikken. Betalingsutvidelsen, fraktutvidelsen, koblingen til ERP og fakturautvidelsen har hver sine utviklere og sin egen utgivelsesrytme, og hver av dem snakker med et system utenfor serveren din. Etter en oppdatering av en slik kobling sjekker jeg i testmiljøet at dataene fortsatt går begge veier: bestillingen kommer til ERP, lagerstatusen kommer tilbake til butikken, fakturaen blir laget.
EHF er et godt eksempel. Fra 1. januar 2027 skal norske bokføringspliktige utstede elektronisk faktura ved salg til andre bokføringspliktige, og frem til 1. januar 2030 gjelder plikten i praksis når kjøperen er registrert for å motta i Peppol. WooCommerce lager ingen fakturaer, så EHF-en kommer fra en utvidelse, en fakturatjeneste eller regnskapssystemet, slik jeg beskriver i artikkelen om EHF-faktura i WooCommerce. En oppdatering av fakturakoblingen går gjennom testmiljøet som alle andre, men testen omfatter også en testfaktura i leverandørens testmiljø. Arkitekturen for koblinger mellom butikken og andre systemer beskriver jeg i guidene om integrasjon mellom WooCommerce og ERP og API-first-utvikling med WordPress.
Betalingsløsninger tester jeg med hele kjøpet, fra handlekurv via kundedata og frakt til betaling, uten å legge inn en ekte bestilling. En butikk der dette skal skje hele tiden, ikke bare etter oppdateringer, drifter jeg på Store Reliability Plan. I den planen avhenger oppdateringsrytmen av nivået: fra månedlige oppdateringer gjennom testmiljø, via oppdateringer annenhver uke, til et ukentlig oppdateringsvindu.
Typisk situasjon: butikk med Vipps MobilePay og kobling til regnskapssystemet
En typisk butikk som eiere kommer med, har Vipps MobilePay i kassen, en fraktutvidelse, en fakturakobling mot regnskapssystemet og et dusin andre utvidelser. I samme uke kan både WooCommerce og betalingsutvidelsen få en oppdatering. Da oppdaterer jeg dem hver for seg innenfor den samme uken: først WooCommerce, test av handlekurv og faktura, deretter Vipps-utvidelsen, og ny test. Går noe galt, er det med en gang klart hvilken endring som skyldes det.
Oppdateringer på sidebygger
Nettsteder bygget med Elementor, Divi eller WPBakery har et ekstra lag som må oppdateres: selve sidebyggeren, tilleggene og ofte et eget tema. Sidebyggeren lagrer layouten i sitt eget format, så en oppdatering av den kan endre utseendet på mange undersider samtidig. Forskjellene mellom sidebyggerne beskriver jeg i sammenligningen av Gutenberg, Elementor og Divi.
Et typisk bedriftsnettsted med 30 utvidelser og sidebygger får flere oppdateringer de fleste uker. På et slikt nettsted gjør sammenligningen av skjermbilder mest av jobben, fordi funksjonstesten passerer selv når en seksjon på forsiden har falt fra hverandre.
Oppdatere selv eller sette det bort
Svaret avhenger av hva som knekker på nettstedet ditt når en oppdatering går galt.
Du har et enkelt nettsted med noen få utvidelser, en sikkerhetskopi som virker, og tid til å se over nettstedet etter oppdateringen.
Du kan oppdatere selv. Ta en kopi før hver oppdatering, og slå på automatiske mindre kjerneoppdateringer.
Nettstedet går på en sidebygger og har flere titalls utvidelser.
Du driver en butikk med Vipps, ERP eller EHF-fakturering.
Nettstedet står flere versjoner bak WordPress eller PHP.
En oppdatering har allerede ødelagt nettstedet, og du har ingen vedlikeholdsavtale.
Automatiske oppdateringer i WordPress og oppdateringer i vedlikeholdet
WordPress kan oppdatere seg selv. Ifølge dokumentasjonen for administratorer får eksisterende installasjoner som standard mindre kjerneoppdateringer automatisk, og nye installasjoner fra versjon 5.6 får både mindre oppdateringer og hovedversjoner. Oppførselen styres av konstanten WP_AUTO_UPDATE_CORE i wp-config.php: verdien 'minor' beholder bare de mindre oppdateringene, verdien true slår på alle.
Utvidelser og temaer fungerer annerledes. Fra WordPress 5.5 slår administratoren på automatiske oppdateringer for hver utvidelse og hvert tema for seg. Ifølge den samme siden kjører WordPress dem to ganger i døgnet og bruker WP-Cron til det.
En automatisk oppdatering installerer den nye versjonen uten kopi og uten test i testmiljø. For mindre kjerneoppdateringer er det en akseptabel risiko. For en butikk, en betalingsutvidelse eller en utvidelse som bestillingsskjemaet er avhengig av, er risikoen for stor. Derfor lar jeg automatikken gå der endringen er liten, og håndterer de kritiske delene manuelt gjennom testmiljøet.
Nettsted som ikke er oppdatert på et år: slik får jeg orden på det
En typisk situasjon ved oppstart: et bedriftsnettsted som ingen har oppdatert på et år, med flere titalls utvidelser, en eldre PHP-versjon og én sikkerhetskopi fra noen måneder tilbake. På et slikt nettsted oppdaterer jeg ikke alt samtidig, fordi det da er umulig å vite hvilken endring som forårsaket en feil.
Jeg starter med oppstartsrevisjonen, som er inkludert i den første måneden: en liste over utvidelser med versjoner, en sjekk av hvilke som fortsatt blir videreutviklet, PHP-versjonen og om den eksisterende kopien kan gjenopprettes. Så tar jeg en ny full kopi og setter opp en klon i testmiljøet. På klonen oppdaterer jeg i puljer: først kjernen, så utvidelsene fra de enkleste til dem som skjemaet eller butikken er avhengig av, og til slutt temaet. Etter hver pulje kommer tester og sammenligning av skjermbilder. Forlatte utvidelser blir erstattet eller fjernet. Overgang til nyere PHP planlegger jeg som et eget steg når alle utvidelsene er oppdatert.
Først når klonen består alle testene, fører jeg endringene over til produksjon i et avtalt vindu. Fra da av går nettstedet inn i den vanlige ukentlige rytmen. Dukker det opp noe underveis som trenger ny kode, beskriver jeg det og gir et eget tilbud.
Oppdateringer i et Multisite-nettverk
I et WordPress Multisite-nettverk installeres utvidelser og temaer én gang for hele nettverket, så oppdateringen treffer alle nettstedene samtidig. Hvert nettsted kan likevel bruke utvidelsen på sin måte: ett har bestillingsskjemaet sitt i den, et annet bare et banner. Derfor tester jeg de viktigste flytene på hvert nettsted som bruker den aktuelle utvidelsen, i testmiljøet for nettverket, og sammenligningen av skjermbilder omfatter undersider fra flere nettsteder. Et Multisite-nettverk priser jeg individuelt, etter antall nettsteder og krav.
Hovedversjon av WordPress: slik innfører jeg den
En hovedversjon av kjernen, som WordPress 7.1, endrer mer enn en feilrettingsversjon og avslører oftere uforenlighet i utvidelser. Ifølge versjonstjenesten til WordPress.org er gjeldende versjon 7.1.3 (per 28. oktober 2026). En hovedversjon installerer jeg aldri samme dag som den kommer ut. Først sjekker jeg i testmiljøet om utvidelsene og temaet fungerer med den nye versjonen, sammenligner skjermbilder og leser endringsloggene for utvidelser som ennå ikke har erklært at de er kompatible. Til produksjon går hovedversjonen i et avtalt vindu, når klonen består testene.
Det var på en slik klon feilen i WP Rocket 3.23.2.2 med WordPress 7.1 dukket opp, som beskrevet over. Når én utvidelse blokkerer en hovedversjon, lar jeg nettstedet stå på forrige gren til utvikleren kommer med en retting eller jeg finner en midlertidig løsning, og skriver det i rapporten.
Hva fra oppdateringene som havner i rapporten
Hver oppdateringsrunde etterlater spor i den månedlige rapporten: hva som ble oppdatert, hvilke feil som dukket opp i testmiljøet, hvilke versjoner jeg holdt tilbake og hvorfor, og om noen endring ble rullet tilbake fra produksjon. Etter en feil vet du dermed hva som endret seg på nettstedet og når, og bytter du leverandør, har du en historikk du kan gi videre.
Endringer i egen kode ved oppdateringer
Noen ganger krever en oppdatering en liten retting i nettstedets egen kode: i et barnetema, i en utvidelse som er skrevet for bedriften, eller i en funksjon som sluttet å virke på nyere PHP. Hver slik endring legger jeg i versjonskontroll, så det er kjent hva som ble endret, når og hvorfor, og endringen kan reverseres. Koden sjekker jeg mot WordPress Coding Standards med PHP_CodeSniffer og WPCS-reglene, og statisk analyse med PHPStan fanger opp typefeil og kall til funksjoner som nyere PHP ikke lenger har. Før publisering går jeg gjennom min egen endring en gang til, adskilt fra skrivingen. En større ombygging ligger fortsatt utenfor vedlikeholdet og får et eget tilbud.
Oppdateringer av Drupal, TYPO3, Laravel og Symfony
Den samme fremgangsmåten (kopi, testmiljø, tester, vindu, plan for tilbakerulling) bruker jeg i systemer utenfor WordPress. Det som skiller, er verktøyene og utgivelsesrytmen.
Drupal oppdaterer jeg i en fast prosess med Composer og publisering via Drush. Drupal 7 har vært uten sikkerhetsstøtte siden 5. januar 2025, og Drupal 10 mister den 9. desember 2026. Hva det betyr for et nettsted på Drupal 10, beskriver jeg i artikkelen om Drupal 10 og slutt på støtte.
I TYPO3 er overgangene mellom LTS-versjonene det viktigste. Den gratis støtten for TYPO3 12.4 tok slutt 30. april 2026, så et nettsted på den versjonen trenger en plan for overgang til 13 eller 14 LTS.
I en Laravel-applikasjon kommer feilrettingsversjoner så ofte som hver uke, og hver hovedversjon får to år med sikkerhetsrettinger. Rettingene går til produksjon i løpet av noen dager, sammen med oppdatering av Composer-avhengighetene og en kjøring av composer audit, alltid på en testserver først. I Symfony får versjon 6.4 feilrettinger til november 2026 og sikkerhetsrettinger til november 2027, og derfor starter mange prosjekter med en plan for overgang til 7.4.
Hva oppdateringene i vedlikeholdet ikke dekker
I vedlikeholdet oppdaterer jeg kjerne, utvidelser, temaer og PHP-versjon. Utenfor ligger ombygging av noe som trenger ny kode etter en oppdatering, store endringer i tema eller sidearkitektur, bygging av nye integrasjoner og overgang til et annet system, for eksempel migrering til Next.js eller Astro. Slikt arbeid får et eget tilbud og starter når du har bekreftet det. Hva selve vedlikeholdet koster, står på siden vedlikehold av WordPress, pris.
Er nettstedet nede etter en mislykket oppdatering, og du har ingen vedlikeholdsavtale, start med WordPress-reparasjon. Har det dukket opp ukjente filer, viderekoblinger eller en advarsel fra Google etter oppdateringen, gå til siden om å fjerne skadevare fra WordPress.
Neste steg: send adressen til nettstedet og listen over utvidelser du regner som kritiske. Du får svar på hvordan jeg legger opp tidsplanen for dem, og hva vedlikeholdet vil koste.
