Hvordan nedgradere WordPress? (Plugin, FTP, wp-CLI)

Denne guiden dekker tre nedgraderingsveier (panel med WP Rollback, WP-CLI og FTP/SFTP) og tilfellet der ingen av dem holder: skjemamigrasjoner. Offisiell oppdateringsdokumentasjon finnes i Updating WordPress. Eldre kjerneversjoner ligger under Releases.

Før ethvert steg: eksporter databasen og kopier wp-content til et trygt sted. En rollback uten backup bytter bare én hendelse mot en annen.

#Hvordan finne ut hva som ødela WordPress-siden

Anta ikke at det var kjernen. På norske nettsteder og WooCommerce-butikker er det vanligste mønsteret:

1. Utvidelse oppdatert (skjema, SEO, page builder, Vipps/Klarna-gateway).
2. Tema eller child theme inkompatibelt med ny kjerne-API.
3. WordPress-kjerne (sjeldnere alene, oftere sammen med gammel PHP hos hostingleverandøren).
4. Database allerede migrert av en WooCommerce-oppgradering eller en membership-utvidelse.

Hvis admin fortsatt åpner: deaktiver utvidelser én og én (eller gi mapper nytt navn via SFTP) - da isolerer du synderen på minutter. Hvis admin ikke åpner: gi wp-content/plugins nytt navn til plugins.off, lag en tom plugins-mappe, og se om siden kommer tilbake. Deretter aktiverer du mapper én og én.

Slå midlertidig på WP_DEBUG_LOG i wp-config.php (aldri WP_DEBUG_DISPLAY i produksjon) og les wp-content/debug.log - stack trace forteller fil og linje, ikke magetfølelse.

#Hva du bør sjekke før du nedgraderer WordPress

En rollback sletter spor. Før du bytter én eneste fil, noter hva siden kjører akkurat nå. Da kan du gå fremover igjen når feilen er rettet, og du kan sammenligne to tilstander hvis rollbacken ikke hjelper.

Med WP-CLI tar det under ett minutt:

wp core version --extra
wp plugin list --fields=name,status,version,update_version --format=csv > utvidelser-for.csv
wp theme list --fields=name,status,version --format=csv > temaer-for.csv
wp db export backup-for-rollback.sql

wp core version --extra viser kjerneversjonen sammen med databaserevisjonen som den kjørende koden forventer. Sammenlign den med wp option get db_version, revisjonen som faktisk ligger i databasen. Er det lagrede tallet høyere enn det målversjonen forventer, er databasen allerede migrert fremover, og en ren filnedgradering passer ikke lenger til den. De to CSV-filene gir deg de eksakte versjonene du skal tilbake til senere, i stedet for gjetting fra hukommelsen midt på natten.

To utvidelseshoder avgjør om en kjernenedgradering i det hele tatt er mulig. En utvidelse kan oppgi Requires at least og Requires PHP i hovedfilen, og der hodene finnes, blokkerer WordPress aktivering når kjerne- eller PHP-versjonen ikke oppfyller dem. Krever en utvidelse WordPress 6.6 og du går tilbake til 6.4, kan du ikke aktivere den igjen etter nedgraderingen, og koden kan kalle kjernefunksjoner som den eldre utgivelsen ikke har. Les hodene før du velger målversjon:

grep -RE "Requires (at least|PHP)" wp-content/plugins/*/*.php

Sett til slutt siden i vedlikeholdsmodus, slik at besøkende og crawlere får 503 i stedet for en halvveis byttet installasjon: wp maintenance-mode activate, og wp maintenance-mode deactivate når arbeidet er ferdig.

#Hvordan rulle tilbake utvidelser og temaer med WP Rollback

Hvis du kommer inn i wp-admin, er den enkleste veien for utvidelser og temaer fra depotet WP Rollback.

1. Installer og aktiver WP Rollback via Utvidelser > Legg til utvidelse.
2. Under Installerte utvidelser (eller Temaer) dukker lenken Rollback opp ved hvert støttede element.
3. Velg den eldre versjonen du vet fungerte på siden din.
4. Bekreft og test den kritiske siden (kasse, kontaktskjema, medlemsområde).

Reelle begrensninger:

• Erstatter ikke en databasebackup.
• Gratisversjonen dekker ifølge utvidelsessiden utvidelser og temaer fra wordpress.org. Premium-utvidelser krever den betalte Pro-versjonen.
• For selve kjernen finnes en egen utvidelse, Core Rollback av Andy Fragen, som legger seg under Verktøy.
• Å rulle tilbake en page builder uten å rulle tilbake maler lagret i databasen kan etterlate ødelagte layouter.

Etter rollback: noter den dårlige versjonen og blokker automatiske oppdateringer for den utvidelsen til du har testet på staging.

#Nedgradere WordPress med WP-CLI

Med SSH og WP-CLI installert hos hostingleverandøren er rollback raskt og gjentakbart. Referanse: wp core update.

Rull kjernen tilbake til en konkret versjon:

wp core update --version=7.0.7 --force

Rull tilbake en utvidelse:

wp plugin install woocommerce --version=8.5.0 --force

Rull tilbake et tema:

wp theme install twentytwentyfour --version=1.0 --force

Flagget --force hører til wp plugin install og wp theme install: ifølge dokumentasjonen overskriver det en installert versjon uten å spørre. wp plugin update har ikke dette flagget, men godtar også --version. For kjernen betyr --force i wp core update at oppdateringen kjøres selv når installert versjon er høyere enn den du ber om.

Gode vaner på serveren:

• Kjør kommandoene fra WordPress-roten (wp core is-installed skal svare positivt).
• Kjør wp db export backup-for-rollback.sql umiddelbart før.
• Bekreft versjon med wp core version / wp plugin list etter kommandoen.
• Tøm object cache hvis den finnes (wp cache flush) - OPcache og Redis liker å servere gammel kode noen minutter.

#Hvilken WordPress-versjon du bør rulle tilbake til

Ikke alle eldre utgivelser er et trygt mål. WordPress.org publiserer sikkerhetsstatusen til hver kjerneversjon i API-et stable-check. Den samme listen styrer utvidelsen Core Rollback, som ifølge beskrivelsen bare tilbyr siste utgivelse og eldre, men sikre utgivelser. 14. oktober 2026 merker API-et 7.1.3 som latest, den siste vedlikeholdsutgivelsen i hver eldre gren (7.0.7, 6.9.10, 6.8.11 osv.) som outdated og alle tidligere vedlikeholdsutgivelser i de grenene som insecure. Versjon 6.4.3, som denne guiden brukte som eksempel frem til denne oppdateringen, står på listen over usikre.

Regelen blir derfor: gå tilbake til den siste vedlikeholdsutgivelsen i grenen som fungerte, ikke til det nøyaktige nummeret du kjørte før. Ødela 7.1.x siden, er målet 7.0.7, ikke 7.0.2. Sjekk statusen før du kjører kommandoen:

curl -s https://api.wordpress.org/core/stable-check/1.0/ | grep '"7.0.7"'

Den andre sjekken gjelder PHP. Kompatibilitetstabellen til kjerneteamet viser hvilke PHP-versjoner hver utgivelse er testet med. En rollback kan flytte deg ut av tabellen:

Har verten allerede flyttet serveren til PHP 8.5, havner en rollback til 6.8 på en kombinasjon kjerneteamet aldri har oppført som støttet. Grensen gjelder også motsatt vei: WordPress 7.0 avsluttet støtten for PHP 7.2 og 7.3, så på en slik server er 6.9 den nyeste utgivelsen du kan kjøre. Velg målet som består begge sjekkene: trygt ifølge stable-check og oppført for PHP-versjonen serveren kjører. Hvilken versjon WordPress faktisk ser, viser wp eval 'echo PHP_VERSION;'.

#WP-CLI på delt hosting

Har du delt hosting uten SSH, eksponerer mange paneler (cPanel Terminal, RunCloud, GridPane, Plesk) WP-CLI likevel. Spør support før du går blindt til FTP. Hos norske leverandører med «WordPress-administrert»-planer er det verdt å sjekke om panelbackup allerede har et gjenopprettingspunkt fra før oppdateringen - det flytter både filer og database i sync.

#Nedgradere WordPress via FTP

Når panelet er dødt og WP-CLI mangler, laster du opp kjernefiler fra den offisielle pakken.

1. Last ned ønsket versjon fra wordpress.org/download/releases. Har du WP-CLI på egen maskin, gjør wp core download --version=7.0.7 --skip-content --path=wp-7.0.7 det samme uten standardtemaene og standardutvidelsene, ifølge dokumentasjonen.
2. Pakk ut på datamaskinen.
3. Slett wp-content-mappen og wp-config-sample.php fra pakken. Last aldri opp en ren wp-content over den ekte siden - da mister du opplastinger, utvidelser og temaer.
4. Koble til med SFTP og last opp wp-admin, wp-includes og rotfilene (wp-login.php, wp-settings.php, osv.) med overwrite.
5. Overskriv ikke wp-config.php eller tilpasset .htaccess.

Åpner du /wp-admin etterpå og ser meldingen Databaseoppdatering nødvendig, bekrefter du med Oppdater WordPress-databasen.

For én utvidelse: last ned ZIP av den gamle versjonen (på utvidelsessiden under Advanced, feltet Previous versions), slett mappen i wp-content/plugins/slug og last opp den gamle. Eller gi den aktuelle mappen nytt navn til slug.broken og last den gamle opp ved siden av.

#Hvordan gjenopprette WordPress fra hostingens backup

Før du rører en eneste fil, sjekk om verten kan angre oppdateringen for deg. På administrert WordPress-hosting er det ofte den raskeste veien, og den krever ingen kommandolinje.

De fleste administrerte verter tar automatiske daglige gjenopprettingspunkter og tilbyr gjenoppretting med ett klikk i kontrollpanelet, som regel under en fane kalt noe som “Backup” eller “Gjenopprett”. Du velger et øyeblikksbilde fra før oppdateringen og bekrefter. Verten setter filer og database sammen tilbake til det tidspunktet. Fordi begge lagene flyttes synkront, unngår du skjemafellen som beskrives i neste avsnitt.

To ting å sjekke først. Noen verter gjenoppretter filer og database hver for seg, så les etikettene og velg det fullstendige øyeblikksbildet, ikke bare filene. Og en gjenoppretting overskriver alt etter øyeblikksbildet, så ordrer, kommentarer og innlegg som kom til etter det tidspunktet, går tapt. På en butikk med løpende salg veier du det mot en målrettet rollback av én utvidelse. For en firmaside der ingenting endret seg i løpet av natten, er gjenoppretting med ett klikk som regel det reneste valget.

#Hvordan sjekke at WordPress-rollbacken virket

“Forsiden laster” er ikke verifisering. En rollback kan etterlate et halvt kopiert filtre, en utdatert bytekode-cache eller en ødelagt admin-sti mens forsiden fortsatt serveres fra cache.

Sjekk først hvilken versjon som faktisk er på plass, ikke den du hadde tenkt å installere:

wp core version
wp plugin get woocommerce --field=version
wp core verify-checksums
wp plugin verify-checksums --all

verify-checksums sammenligner hver fil på disken med sjekksummene wordpress.org publiserer for akkurat den utgivelsen. Det er den raskeste måten å fange den klassiske FTP-feilen på: en overføring som hoppet over eller kuttet noen filer uten å melde feil. En ren kjøring betyr at filtreet matcher versjonen du ville ha. Utvidelsesvarianten dekker bare utvidelser fra wordpress.org, så premium-utvidelser trenger fortsatt manuell filsammenligning.

Tøm deretter hver cache som kan fortsette å servere koden du nettopp fjernet:

• Objektcache: wp cache flush (Redis eller Memcached holder serialiserte objekter laget av den nyere koden).
• Sidecache og CDN: tøm hele cachen, ikke én URL, fordi en fatal error kan ha blitt cachet som et 500-svar.
• PHP OPcache: den de fleste glemmer. På servere med opcache.validate_timestamps=0 blir den kompilerte bytekoden fra de nyere filene liggende i minnet til PHP-FPM-poolen lastes på nytt. De eldre filene ligger da på disk, mens den nyere koden fortsatt kjøres. Last PHP på nytt i hostingpanelet, eller kjør et skript som kaller opcache_reset().

Test så mer enn forsiden. Fatale feil etter en oppdatering sitter som regel i admin-ajax, REST API-et eller kassen, ikke på en cachet forside:

curl -o /dev/null -s -w "%{http_code}\n" https://ditt-domene.no/
curl -o /dev/null -s -w "%{http_code}\n" https://ditt-domene.no/wp-json/

Logg inn, åpne innstillingssiden til utvidelsen du rullet tilbake, og gjør én skriveoperasjon: lagre et innlegg, send kontaktskjemaet, legg inn en testordre. Leseoperasjoner går gjennom på mange ødelagte installasjoner.

Tøm wp-content/debug.log før testrunden og les den igjen etterpå. En logg som forblir tom, er et sterkere signal enn en side som bare ser riktig ut, fordi den også utelukker advarslene og deprecation-meldingene som blir fatale feil i neste utgivelse. Avslutt i Verktøy > Nettstedshelse, der testene flagger en kjerneversjon som mangler sikkerhetsutgivelser og en PHP-versjon WordPress ikke lenger regner som støttet.

#Hvordan gjenopprette databasen etter en mislykket oppdatering

Enkelte oppdateringer kjører SQL-migratorer. Typiske eksempler:

• WooCommerce major (nye HPOS-/ordre-tabeller)
• Membership- eller LMS-utvidelser som endrer meta og egne tabeller
• Enkelte builders som skriver om post meta i bulk

Da forstår ikke den gamle koden det nye skjemaet. Symptomer: SQL-feil i loggen, manglende produkter, kasse som feiler, hvit skjerm bare på butikk-URL-er.

Fremgangsmåte:

1. Sett siden i vedlikehold eller steng betalt trafikk.
2. Gjenopprett SQL-dumpen fra før oppdateringen (phpMyAdmin, wp db import, hostingpanelet).
3. Gjenopprett filene (kjerne + utvidelser) til samme tidspunkt - ideelt samme backup.
4. Først deretter undersøker du på staging hvorfor oppdateringen feilet og forbereder en ren oppgradering.

Hvis databasebackupen er tre uker gammel og det finnes nye ordrer, trenger du en merge-strategi (eksporterte ordrer, delvis gjenoppretting) - det er gjenopprettingsarbeid, ikke en fem-minutters rollback. På norske WooCommerce-butikker med Vipps: noter også webhooks og ventende betalingsreferanser før du rører databasen.

#Hvordan hindre at en tilbakerullet utvidelse oppdateres igjen

Ingenting ved en nedgradering forteller WordPress at den skal bli værende. Automatiske oppdateringer kjøres av cron-hendelsene wp_version_check, wp_update_plugins, wp_update_themes og wp_maybe_auto_update, så en utvidelse du rullet tilbake om morgenen, kan være tilbake på den ødelagte utgivelsen samme dag. Det er den vanlige forklaringen når en side “ryker igjen av seg selv” timer etter en vellykket rollback. Å følge med på dette er en del av WordPress-oppdateringene jeg tar for kunder.

Lås den aktuelle utvidelsen først:

wp plugin auto-updates disable woocommerce
wp plugin auto-updates status

Innstillingen lagres i opsjonen auto_update_plugins som en liste over filstier til utvidelser. Det betyr noe av én grunn: gjenoppretter du senere en databasebackup tatt før du satte låsen, forsvinner låsen med den. Sett den på nytt etter hver databasegjenoppretting.

For kjernen bruker du wp-config.php:

define( 'WP_AUTO_UPDATE_CORE', 'minor' );

WP_AUTO_UPDATE_CORE godtar true, false eller 'minor'. Med 'minor' slipper sikkerhetsutgivelser gjennom, mens hovedversjonen som ødela siden, blokkeres. Det er innstillingen du lander på når nødsituasjonen er over. AUTOMATIC_UPDATER_DISABLED og filteret automatic_updater_disabled slår av hele oppdateringsmekanismen, oversettelser inkludert, så bruk dem bare de timene du feilsøker.

Bekreft med wp cron event list at ingenting fortsatt står i kø, og sjekk panelet også: administrerte verter kjører sin egen oppdateringsplanlegger utenfor WordPress, og den ignorerer konstantene i wp-config.php. Bygges siden med Composer, låser du den eksakte versjonen der ("wpackagist-plugin/woocommerce": "8.5.0"), slik at selve utrullingen håndhever låsen og ikke en innstilling noen kan fjerne i kontrollpanelet.

Behandle hver lås som midlertidig. Noter versjonen du unngår og hvorfor, følg endringsloggen til utvidelsen, og fjern låsen så snart en rettet utgivelse er ute. En utvidelse som er låst for alltid, blir selve sikkerhetshullet oppdateringen skulle tette.

#Hvilken metode for WordPress-rollback du bør velge

Riktig metode avhenger av tilgangen du har og av hva som gikk i stykker:

Passer to rader, velg den øverste: en målrettet rollback av én utvidelse griper alltid mindre inn enn en full gjenoppretting, og full gjenoppretting er sikkerhetsnettet for tilfellene der en målrettet rollback ikke kan virke.

#Hvordan nedgradere PHP i hostingpanelet

Ikke alle feil etter en oppdatering er WordPress sin skyld. Verter oppgraderer PHP-versjonen på serveren med jevne mellomrom, noen ganger automatisk, og en utvidelse eller et tema som aldri er testet på nyere PHP, kan ryke i det øyeblikket byttet skjer. Symptomet er en fatal error som nevner en utdatert eller fjernet funksjon, selv om du ikke har oppdatert noe i WordPress.

Løsningen er da ingen WordPress-nedgradering, men et bytte av PHP-versjon i hostingpanelet. De fleste paneler (cPanel, Plesk og dashbordene til administrerte verter) har et verktøy for å velge PHP-versjon. Bytt tilbake til versjonen siden kjørte på før, last siden på nytt og bekreft at feilen forsvinner.

Se på det som pusterom, ikke som løsning. En PHP-versjon uten sikkerhetsstøtte holder sikkerhetshull åpne. Bruk tiden til å oppdatere utvidelsen eller temaet til en utgivelse som støtter nyere PHP, test på staging og flytt produksjonen fremover igjen.

#Hvordan nedgradere premium-utvidelser på delt hosting

Mange norske sider blander wordpress.org-utvidelser med lisenser fra Elegant Themes, WPML, Gravity Forms eller lokale betalingsløsninger. WP Rollback lister ikke private utgivelser. For dem:

1. Lagre ZIP av produksjonsversjonen i et internt depot eller på prosjektets disk (versjonert utenfor webroot).
2. Før du oppdaterer i panelet: last ned den nye ZIP-en, men behold den gamle komprimert med versjonsnummer i filnavnet (gravityforms-2.8.0.zip).
3. Hvis oppgraderingen feiler: slett den nye mappen i wp-content/plugins/ og pakk ut den gamle ZIP-en.

På delt hosting i Norge (klassisk cPanel, Domeneshop, One.com, Loopia og lignende «WordPress-klare» planer) bekreft at du har:

• SFTP med nøkkel (ikke bare passord i FileZilla på laptopen)
• phpMyAdmin eller wp db export for dumpen
• PHP-versjon som matcher kravene til kjernen du skal gjenopprette

Sjekk også PHP-kombinasjonen før du velger nummer. WordPress 7.0 og nyere krever PHP 7.4, og eldre kjerneversjoner er ikke oppført som støttet på de nyeste PHP-versjonene. Tabellen i avsnittet om hvilken versjon du bør rulle tilbake til, viser grensene ifølge kjerneteamets oversikt.

#Hvordan unngå hvit skjerm etter WordPress-oppdatering

Nedgradering er plan B. Plan A:

• Staging-kopi med samme utvidelser og samme PHP-versjon som produksjon (norske verter blander fortsatt ofte 8.0/8.1/8.2 mellom planer).
• Oppdater først på staging, test kasse og skjemaer, deretter produksjon.
• Daglige automatiske backups som er testet (faktisk gjenoppretting én gang i kvartalet, ikke bare en .sql-fil som fyller disk).
• Automatiske oppdateringer bare for minor/patch av kjernen hvis du stoler på hosten; majors og WooCommerce forblir manuelle.

Bruker du Git og CI, er kode-rollback et commit-revert - men databasen trenger samme forsiktighet som beskrevet over.

#Hva du gjør når en WordPress-oppdatering ødela siden

1. Fersk backup (filer + DB), selv om siden allerede er nede.
2. Isoler utvidelse/tema (gi mapper nytt navn).
3. Rollback av synderen (WP Rollback eller WP-CLI eller gammel ZIP).
4. Hvis det feiler: full gjenoppretting av backup før oppdateringen.
5. Åpne staging, reproduser oppgraderingen, rett konflikten, planlegg vedlikeholdsvindu.

#Vanlige spørsmål

#Angrer filnedgradering endringer i databasen

Nei. Kjernen og mange utvidelser kjører oppgraderingsrutiner i databasen når en ny versjon aktiveres. Å bare bytte filene etterlater databasen på nytt skjema med gammel kode - hvit skjerm, SQL-feil eller inkonsistente data. Da gjenoppretter du en full backup tatt før oppdateringen.

#Kan jeg nedgradere WooCommerce trygt

Bare hvis du har databasebackup fra tidspunktet før oppdateringen. Major WooCommerce-versjoner migrerer ordre- og produkttabeller. Å rulle tilbake utvidelsen uten å gjenopprette databasen ødelegger ofte butikken. På butikker med salg er trygg vei staging + testet backup, ikke improvisert rollback midt på natten.

#Fungerer WP Rollback på WordPress-kjernen

WP Rollback fokuserer på utvidelser og temaer listet i depotet. For kjernen bruker du WP-CLI (wp core update --version=... --force) eller manuell filutskifting fra wordpress.org/releases, uten å røre wp-content.

#Hva gjør jeg hvis både panelet og SSH er utilgjengelige

Bruk filbehandleren hos hostingleverandøren eller FTP/SFTP. Gi mistenkelige utvidelser i wp-content/plugins et nytt navn (for eksempel legg til .off) for å få tilbake admin. Deretter gjør du kontrollert rollback. Hvis problemet er kjernen, last opp en eldre stabil versjon over kjernefilene uten å slette wp-content.

#Bør jeg oppdatere igjen etter en nedgradering

Ja, men med plan: finn utvidelsen eller versjonen som ødela siden, test oppdateringen på staging, rett konflikten (child theme, snippet, PHP-inkompatibilitet) og først deretter oppgrader produksjon. Å bli værende på gammel programvare uten CVE-patch er permanent risiko.

#Oppsummering

Nedgradering i WordPress er overlevelsesrutine, ikke skam. Panel med WP Rollback for utvidelser, WP-CLI når du har SSH, FTP bare på kjernen uten å røre wp-content, og full backup når databasen allerede har migrert. Målet er ikke å leve for alltid på en gammel versjon - det er å få siden opp og oppdatere på nytt med staging og backups du allerede har bevist at kan gjenopprettes.

Se også vår WordPress-sikkerhetsrevisjon. Trenger du hjelp til å sette opp staging- og gjenopprettingsflyt før neste oppdatering tar ned butikken, kontakt oss - jeg jobber med WordPress og WooCommerce med denne typen gjenoppretting i det daglige.