Kort svar: Gik siden i stykker efter en opdatering, er der tre veje tilbage: installér den tidligere version af det plugin eller tema, der blev opdateret, rul PHP-versionen tilbage, eller gendan hele sitet fra en backup. Rul kun det tilbage, der faktisk blev ændret. Har opdateringen ændret databasen – typisk WordPress-kernen eller WooCommerce – er en fuld backup fra før opdateringen den eneste rene vej, og så skal nye ordrer og indhold reddes først.
Fagligt gennemgået: 2. oktober 2026
Hvilken metode der er rigtig, afhænger af hvad der blev opdateret, og af hvad der er sket på sitet siden. Start med at afgøre det. Kig under Kontrolpanel → Opdateringer, i pluginlisten eller i din opdateringslog. Notér navn, gammel og ny version for alt, der blev opdateret i samme omgang.
En tilbagerulning er en nødløsning, der køber dig tid. Den gamle version mangler de rettelser, den nye indeholdt, så planen skal altid være at komme frem igen – bare kontrolleret.
Før du ændrer noget: Tag en backup af den nuværende tilstand, også selvom den er i stykker. Den indeholder ordrer, kommentarer og indhold, der er kommet til siden sidste backup, og som du ellers mister ved en gendannelse.
Vælg metode ud fra, hvad der blev opdateret
| Hvad blev opdateret | Første valg | Bemærk |
|---|---|---|
| Ét plugin | Installér den tidligere version | Indstillinger bliver liggende i databasen |
| Temaet | Installér den tidligere temaversion | Ændringer i child-temaet påvirkes ikke |
| Flere ting på én gang | Gendan filer fra backup, opdater derefter én ad gangen | Databasen kun med, hvis det er nødvendigt |
| PHP-versionen | Skift tilbage i kontrolpanelet | Midlertidigt – sæt en dato for at komme frem igen |
| WordPress-kernen | Find og ret det plugin, der ikke er kompatibelt | Rul kernen tilbage kun som nødløsning |
| WooCommerce med databaseopdatering | Ret fremad, eller fuld gendannelse | En fuld gendannelse sletter ordrer siden backuppen |
1. Få sitet op at køre igen – så find fejlen

Viser sitet “Der har været en kritisk fejl på dette websted”, har WordPress sandsynligvis allerede sendt en mail til administratoradressen med et link til gendannelsestilstand. I den tilstand er det fejlende plugin eller tema sat på pause – kun for dig – og du kan gå ind og deaktivere det uden at røre filerne.
Kommer mailen ikke, så omdøb pluginnets mappe via SFTP eller filhåndteringen, fx wp-content/plugins/pluginnavn til pluginnavn_off. WordPress deaktiverer det så med det samme, og sitet svarer igen. Ved du ikke, hvilket plugin det er, står fil og linje i fejlloggen – se kritisk fejl i WordPress.
WordPress har selv et sikkerhedsnet
WordPress tager en midlertidig kopi af et plugin eller tema, før det opdateres. Fejler selve opdateringen undervejs, lægges den gamle version automatisk tilbage. For automatiske plugin-opdateringer går WordPress et skridt videre: giver den nye version en fatal fejl ved en testindlæsning, rulles den automatisk tilbage, og administratoren får besked på mail.
Sikkerhedsnettet fanger dog kun fejl, der viser sig med det samme. En opdatering, der går fint igennem, men brækker kassen eller et layout, skal du selv rulle tilbage.
2. Var det ét plugin
Installér den tidligere version. På WordPress.org kan du hente en ældre version under “Avanceret visning” på pluginnets side, hvor der nederst er en liste over tidligere versioner. Slet det nuværende plugin – indstillingerne bliver i databasen – og upload den gamle zip-fil under Plugins → Tilføj nyt → Upload plugin. Nyere WordPress-versioner tilbyder også at erstatte det installerede plugin direkte, når du uploader en zip-fil med samme plugin.
Har du SSH, går det endnu hurtigere. Se først de installerede versioner, og læg derefter den gamle version tilbage:
wp plugin list --fields=name,status,version
wp plugin install pluginnavn --version=3.4.1 --force
Kommandoen lægger den gamle version tilbage på sekunder – uden at slette indstillinger og uden at skulle finde en zip-fil. Versionsnummeret er et eksempel; brug det, du noterede før opdateringen.
Betalte plugins findes ikke på WordPress.org. Her ligger de tidligere versioner typisk på din konto hos leverandøren, eller i din backup. Gem derfor gerne zip-filen for den version, du kører, inden store opdateringer.
Fortæl derefter udvikleren, hvad der gik galt. Et plugin, der brækker sider ved opdatering, retter sig sjældent af sig selv. Slå automatiske opdateringer fra for netop det plugin, indtil en rettet version er ude, så det ikke opdateres igen i nat.
3. Var det temaet eller flere ting på én gang
Ét tema rulles tilbage på samme måde som et plugin: upload den tidligere version, eller brug wp theme install temanavn --version=x.y.z --force. Har du lavet ændringer direkte i temaets filer i stedet for i et child-tema, er de væk ved en opdatering – og også ved en tilbagerulning. Så skal de hentes fra backuppen.
Er der opdateret mange ting på én gang, er en backup hurtigere end at nisse med enkeltdele. Gendan filerne fra i går, og opdater derefter én ting ad gangen, indtil du finder synderen.
Det forudsætter, at du har en backup fra i går. Daglige backups med selvbetjent gendannelse hører med til WordPress hosting hos Hostious, så du ikke skal huske at tage dem – se også hvordan automatisk backup fungerer og gendan fra backup uden at miste nye ordrer.
4. Var det PHP-versionen
Springer du fra fx PHP 8.1 til 8.4, kan ældre kode holde op med at virke. Fejlloggen viser det typisk som Deprecated, TypeError eller kald til funktioner, der ikke findes længere. PHP-versionen kan skiftes tilbage i kontrolpanelet på under et minut.
Brug tiden derefter på at få opdateret det, der ikke tåler den nye version. At blive på en gammel PHP-version er ikke en løsning – det er udskudt vedligeholdelse, og versioner uden for support får ikke sikkerhedsrettelser. Målet bør i dag være PHP 8.3 eller 8.4. Se fejl efter PHP-opgradering.
5. Var det WordPress selv?
En kerneopdatering kan også gå galt, typisk fordi et gammelt plugin bruger en funktion, som den nye version har fjernet eller ændret. Her er der to veje. Den rigtige er at finde pluginnet (fejlmailen eller fejlloggen nævner det) og opdatere eller erstatte det.
Nødløsningen er at rulle WordPress tilbage. Se først, hvilken version du kører, og installér derefter den forrige:
wp core version
wp core update --version=x.y.z --force
Erstat x.y.z med den version, du kørte før. Uden WP-CLI kan du uploade den gamle versions filer oven i – aldrig mappen wp-content, kun wp-admin, wp-includes og filerne i roden, undtagen wp-config.php.
Husk også databasen. Større kerne- og WooCommerce-opdateringer ændrer tabeller, og en ældre kode kan ikke altid læse den nye struktur. Er databasen opdateret, er en fuld backup fra før opdateringen (filer og database sammen) den eneste rene vej tilbage.
6. Var det WooCommerce?
WooCommerce kører ofte en databaseopdatering efter en ny version, og den kan ikke fortrydes ved blot at installere den gamle pluginversion. Den gamle kode kan møde en database, den ikke forstår, og så får du nye fejl oven i de gamle.
Har shoppen taget imod ordrer siden opdateringen, er det næsten altid bedre at rette fejlen fremad – fx ved at deaktivere det udvidelsesplugin, der ikke er kompatibelt, eller vente på en rettelse. Skal der alligevel en fuld gendannelse til, så eksportér de nye ordrer først, sæt shoppen i vedligeholdelsestilstand, og gennemfør gendannelsen uden for åbningstiden. Bruger shoppen HPOS (High-Performance Order Storage), ligger ordrerne i egne tabeller, som også skal med i backuppen. Se WooCommerce-databaseopdateringen hænger, hvis opdateringen ikke bliver færdig.
Hvad du må og ikke må rulle tilbage
- Plugins og temaer: ja, så længe du kan få fat i den gamle version. Rul tilbage, og hold den gamle version i højst nogle uger – sikkerhedsrettelser mangler i den.
- WooCommerce: med forsigtighed. Har den kørt en databaseopdatering, skal databasen med tilbage, og så mister du ordrer, der er kommet siden.
- Sikkerhedsopdateringer: helst aldrig. Er det en rettelse af et kendt hul, er en side, der virker med hullet åbent, ikke bedre end en side, der er nede.
- PHP-versionen: ja, som midlertidig løsning. Sæt en dato for, hvornår du er tilbage på den nye.
Verificér efter tilbagerulningen
- Åbn forsiden, en underside og wp-admin i et privat vindue.
- Gennemfør det, der fejlede: et testkøb, en formular, en søgning eller en gemning i editoren.
- Ryd cachen i cacheplugin og CDN, så du ikke ser en gammel kopi.
- Tjek fejlloggen for nye fatal-linjer.
- Skriv ned, hvad der blev rullet tilbage, til hvilken version og hvorfor – så den næste opdatering ikke gentager fejlen.
Sådan slipper du for at rulle tilbage
- Opdater i et testmiljø først, og se siden efter. Staging følger med fra WP StartUp hos Hostious.
- Tag fem plugins ad gangen frem for alle på én gang.
- Læs ændringsloggen på større opdateringer.
- Opdater ikke fredag eftermiddag.
- Tag en manuel backup lige før store opdateringer, så tilbagerulning bliver ét klik.
En god opdateringsrutine – uanset om du selv står for den, eller om den ligger i en serviceaftale – tager et øjebliksbillede før opdateringen og tester forsiden, kassen og kontaktformularen bagefter. Så opdages fejlen, mens den stadig er nem at fortryde – ikke af en kunde tre dage senere. Se også opdateringspolitik: auto-opdatér det rigtige, test resten.
Læs også
- Hub: WordPress fejl og fejlfinding
- Kritisk fejl i WordPress
- Gendan fra backup uden at miste nye ordrer og indhold
- Staging i WordPress: test ændringer før de går live
- WP-CLI for begyndere
- WordPress hosting hos Hostious – daglig backup med selvbetjent gendannelse
Ofte stillede spørgsmål om at fortryde en WordPress-opdatering
Mister jeg indhold ved at gendanne fra backup?
Du mister det, der er skrevet siden backuppen blev taget. Har du fået ordrer eller kommentarer i mellemtiden, så gendan kun filerne og lad databasen være.
Kan jeg rulle WordPress-kernen tilbage?
Ja, men gør det kun kortvarigt. Kernen indeholder sikkerhedsrettelser, og en gammel version er en åben dør.
Kan jeg rulle WooCommerce tilbage efter en databaseopdatering?
Kun ved at gendanne både filer og database fra før opdateringen, og så mister du ordrer og ændringer siden. Er der kommet ordrer ind, er det næsten altid bedre at rette fejlen fremad end at rulle tilbage.
Hvad er gendannelsestilstand i WordPress?
En tilstand, WordPress selv tilbyder via mail, når et plugin eller tema giver en kritisk fejl. Linket i mailen logger dig ind med det fejlende plugin sat på pause, så du kan deaktivere eller opdatere det uden filadgang.
Ruller WordPress selv en fejlet opdatering tilbage?
Delvist. Fejler selve opdateringen, lægges den gamle version tilbage automatisk, og automatiske plugin-opdateringer, der giver en fatal fejl, rulles også tilbage. Fejl, der først viser sig senere, fx i kassen, skal du selv rulle tilbage.
Udgivet 28. august 2026Opdateret 3. oktober 2026Fagligt gennemgået 2. oktober 2026
