Opdateringspolitik: auto-opdatér det rigtige, test resten

Kort svar: En WordPress opdateringspolitik består af tre klasser og en kalender. Auto-opdatér det, hvor risikoen er lille og sikkerhedsgevinsten stor (WordPress’ mindre versioner og små, veldrevne plugins). Opdatér manuelt med test det, forretningen står på (betaling, booking, sikkerhed, tema, page builder og større kerneversioner) – med backup før og funktionstest efter. Kør offentliggjorte sikkerhedsrettelser straks, uanset klasse, og frys alt andet i højsæsonen.

Fagligt gennemgået: 2. oktober 2026

Opdateringer er både dit vigtigste sikkerhedsværn og en af de hyppigste selvforskyldte årsager til nedbrud. Uden en politik ender de fleste i en af to grøfter: „vi opdaterer aldrig, det kører jo“ – indtil sitet bliver hacket gennem et gammelt hul – eller „vi opdaterer alt med det samme“ – indtil betalingsmodulet knækker en fredag eftermiddag.

Politikken er vejen imellem, og den kan stå på én side. Her er, hvordan du skriver den.

1. Klassificér: auto, manuel eller straks

Gå pluginlisten igennem én gang, og placér alt i tre klasser:

• Auto: WordPress’ mindre versioner (sikkerheds- og vedligeholdelsesudgivelser, fx fra x.y.1 til x.y.2), 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, page builderen og større kerneversioner. Her er en fejl dyrere end nogle dages forsinkelse, så de venter på dit vindue.
• Straks: Offentliggjorte sikkerhedsrettelser. Når et plugin lukker et hul, der aktivt bliver udnyttet, vejer sikkerhedsrisikoen tungere end test-forsigtigheden. Kør dem samme dag – med backup først.

Tommelfingerregel i tvivlstilfælde: jo tættere på penge og login, desto mere manuel.

2. Sæt klasserne op i WordPress

WordPress installerer som standard selv mindre kerneversioner. Siden WordPress 5.5 kan du også slå automatisk opdatering til og fra for hvert enkelt plugin og tema under Plugins og Udseende → Temaer. Brug det til auto-klassen, og lad resten stå på manuel.

Vil du låse kernens adfærd fast, kan du sætte en konstant i wp-config.php. Værdien minor betyder, at kun mindre versioner installeres automatisk:

define( 'WP_AUTO_UPDATE_CORE', 'minor' );

Har du WP-CLI-adgang, får du hurtigt et overblik over, hvad der venter, før du åbner vinduet:

wp core check-update
wp plugin list --update=available
wp theme list --update=available

Sørg for, at politikken ikke modarbejdes af andre lag: nogle hostingpaneler og administrationsværktøjer kan også opdatere automatisk. Tjek, hvem der faktisk opdaterer hvad, så du ikke har to systemer, der hver især tror, de har ansvaret.

3. Rytmen: vinduer og frys

Manuel opdatering uden fast tid ender som aldrig-opdatering. Giv den derfor et fast vindue: 15–30 minutter hver måned som en del af årshjulets månedsrutine.

• Vælg et roligt tidspunkt i åbningstiden. Ikke fredag kl. 16 – fejler noget, vil du have både vågen tid og supportens åbningstid foran dig.
• Opdatér i bidder. Opdatér ét plugin, genindlæs, test, og tag så det næste. En fejl kan da spores til én ændring i stedet for femten.
• Respektér frys-perioderne. I højsæsonen – webshoppens november-december eller kursusudbyderens tilmeldingsuger – kører du kun sikkerhedsrettelser og kritiske fejlrettelser. Nye funktioner venter, til der er roligt igen.

Frys er ikke dovenskab. Det er en erkendelse af, at ændringer skaber risiko, og at højsæsonen er det dårligste tidspunkt at tage den.

4. Testen: før og efter

Før du ændrer noget: Sørg for, at du kan rulle tilbage. Tag en frisk backup, eller bekræft, at nattens automatiske backup findes og kan gendannes. Uden rollback er hver opdatering et væddemål.

Testen skal være lille nok til, at den faktisk bliver gjort:

1. Før vinduet: Sikr rollback (se boksen ovenfor – selve øvelsen står i backup-testen), og skim changelog-noterne for de kritiske plugins. Står der „major“, „breaking change“ eller „ny arkitektur“, planlægger du den opdatering særskilt.
2. Efter hver bid: Kør minimumstesten – forsiden, én indholdsside og forretningens nøglefunktion. Læg en vare i kurven og gå til betaling, send testformularen, eller book en testtid.
3. Efter vinduet: Tjek fejlloggen eller Site Health for nye advarsler, og tøm cachen, hvis siden viser gammelt indhold.

Driver du noget større eller mere skrøbeligt, så kør de kritiske opdateringer i et staging-miljø først. Til de fleste små sites er backup, bidder og minimumstest den rette balance mellem grundighed og gennemførlighed.

5. Når en opdatering går galt

Selv med en god politik knækker en opdatering engang imellem. Så gælder rækkefølgen:

1. Stop og notér. Hvilken opdatering kom sidst, og hvad er symptomet? Det er grunden til, at du opdaterer i bidder.
2. Rul tilbage. Installér den forrige version af pluginnet, eller gendan backuppen. Med WP-CLI kan du installere en bestemt version direkte, fx wp plugin install pluginnavn --version=1.2.3 --force.
3. Kan du ikke komme ind i wp-admin, så omdøb pluginmappen via SFTP eller filhåndtering, så WordPress deaktiverer pluginnet.
4. Find årsagen bagefter – i fejlloggen, i pluginnets changelog eller hos udvikleren – og kør opdateringen igen, når der er en rettelse.

Detaljerne står i guiden om at rulle en WordPress-opdatering tilbage.

6. Dokumentér politikken

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 et bureau følger samme linje.
• Notér hver kørsel i ændringsloggen med dato og hvad der blev opdateret. Fejler noget „ud af det blå“ tre dage senere, er den notits fejlfindingens første opslag.
• Hold plugin-hygiejnen i system: inaktive plugins og temaer er angrebsflade uden funktion. Slet dem i stedet for blot at deaktivere dem.
• Optag kun nye plugins efter site-inventarets spørgsmål: Er det vedligeholdt? Er det nødvendigt? Hvem betaler licensen?

Et eksempel på en politik på fem linjer kan se sådan ud:

Klasse	Hvad	Hvornår
Auto	Mindre kerneversioner, oversættelser, små hjælpeplugins	Løbende
Manuel med test	WooCommerce, betaling, formularer, tema, page builder, større kerneversioner	Første tirsdag i måneden kl. 10
Straks	Offentliggjorte sikkerhedsrettelser	Samme dag, backup først
Frys	Alt undtagen sikkerhed og kritiske fejl	15. november – 2. januar

Hvad hostingen kan tage

En del af politikken kan flyttes ned i fundamentet. På WordPress hosting hos Hostious er der daglig og manuel backup med selvbetjent gendannelse, så rollback altid er inden for rækkevidde. Fra WP StartUp er WordPress serviceaftalen inkluderet, og du får staging til at teste de kritiske opdateringer først.

Din egen indsats kan så koncentreres om det, kun du kan: at teste nøglefunktionen efter de kritiske opdateringer og beslutte, hvornår frysen gælder. Selve håndværket omkring sikkerhed og backup finder du i sikkerheds- og backup-hubben.

Læs også

• Hub: Driftshåndbogen
• Årshjulet for en sund hjemmeside: 12 måneders rutiner
• Fortryd en WordPress-opdatering – tre måder at rulle tilbage
• Staging i WordPress: test ændringer før de går live
• WordPress hosting hos Hostious – staging og serviceaftale fra WP StartUp

Ofte stillede spørgsmål om opdateringspolitik

Skal jeg slå auto-opdatering til for alle plugins?

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.

Hvor ofte skal der opdateres?

Auto-klassen kører løbende, det manuelle vindue månedligt – og offentliggjorte sikkerhedsrettelser samme dag, uanset kalenderen. I højsæsonen fryses alt undtagen det kritiske.

Hvad tester jeg efter en opdatering?

Minimum forsiden, én indholdsside og forretningens nøglefunktion (kurv til betaling, formular eller booking). Et par minutter pr. opdatering fanger de fleste fejl, mens årsagen stadig er åbenlys.

Hvad gør jeg, hvis en opdatering ødelægger sitet?

Rul den seneste opdatering tilbage ved at installere den forrige version eller gendanne backuppen. Kan du ikke komme ind i wp-admin, kan du omdøbe pluginmappen via SFTP, så pluginnet deaktiveres.