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.

#Rask diagnose: hva gikk galt?

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.

#Metode 1: WP Rollback (panel tilgjengelig)

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 fra Utvidelser → Legg til ny.
2. Under 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.
• Premium-utvidelser utenfor wordpress.org lister ofte ikke utgivelser.
• Å 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.

#Metode 2: WP-CLI (SSH)

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=6.4.3 --force

Rull tilbake en utvidelse:

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

Rull tilbake et tema:

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

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.

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.

#Metode 3: Manuell filutskifting (FTP/SFTP)

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

For én utvidelse: last ned ZIP av den gamle versjonen (utvidelsessiden → Advanced → 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.

#Når bare databasebackup hjelper

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.

#Premium-utvidelser og norsk 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

En nedgradering til en kjerne som krever PHP 8.1 på en server som fortsatt kjører 7.4 redder ikke siden - den bare bytter fatal error. Les kravene for versjonen under Releases før du velger nummer.

#Staging og hvordan unngå neste hvite skjerm

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.

#Sjekkliste for nød (foreslått rekkefølge)

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 - vi jobber med WordPress og WooCommerce med denne typen gjenoppretting i det daglige.