Hvordan oppdatere url-er i WordPress-databasen når du flytter domene?

Å flytte et WordPress-nettsted (f.eks. fra dev.site.com til site.com) virker enkelt: bare kjør et “Søk og erstatt” i databasen, ikke sant?

FEIL.

Hvis du prøver å kjøre en rå SQL-spørring som: UPDATE wp_options SET option_value = replace(option_value, 'gammelt.no', 'nytt.no')

…vil du ødelegge nettstedet ditt. Spesifikt vil du miste widgeter, temainnstillinger og konfigurasjonen til mange utvidelser.

#Slik endrer du WordPress-URL i databasen (den trygge måten)

Den trygge måten å endre WordPress-URL-en i databasen på er én enkelt WP-CLI-kommando, kjørt etter at du har tatt backup:

wp search-replace 'https://old.com' 'https://new.com' --all-tables --precise

Kommandoen oppdaterer siteurl og home i wp_options, hver eneste URL i innhold og metadata, og håndterer serialiserte data korrekt. Har du ikke shell-tilgang, er rekkefølgen denne: først en utvidelse som forstår serialisering (Better Search Replace), deretter phpMyAdmin, men kun for de to radene i wp_options (siteurl og home), og aldri en rå SQL REPLACE() på alle tabeller. Resten av guiden forklarer hvorfor den siste metoden ødelegger nettsteder, og går gjennom hvert alternativ steg for steg.

#Den vanlige feilen: Enkel “søk og erstatt”

Mange utviklere (og til og med noen hostingleverandører) foreslår å bruke en enkel SQL REPLACE()-funksjon for å oppdatere URL-er. Denne tilnærmingen virker logisk, men er fundamentalt feil i WordPress-økosystemet.

Fristelsen:

-- Dette ser trygt ut, men det er det IKKE
UPDATE wp_options 
SET option_value = REPLACE(option_value, 'https://gammelt.no', 'https://nytt.no');

Hva som skjer:

• Noen URL-er oppdateres riktig (f.eks. i postinnhold).
• Serialiserte data blir korrupte.
• Widgeter forsvinner.
• Temainnstillinger tilbakestilles.
• Utvidelsesinnstillinger går tapt.
• Nettstedet blir delvis ødelagt.

Hvorfor det feiler: WordPress lagrer ikke alle data som ren tekst. Mye av det lagres som serialiserte PHP-data, noe som krever spesiell behandling.

#Forstå serialisering: Kjerneproblemet

#Hva er serialisering?

WordPress lagrer komplekse data (matriser/arrays, objekter) i databasen som Serialiserte Strenger. Serialisering konverterer PHP-datastrukturer til en streng som kan lagres i databasen.

Eksempel på serialiserte data:

// Original PHP array
array(
    'home' => 'https://gammelt.no',
    'siteurl' => 'https://gammelt.no',
    'admin_email' => '[email protected]'
)

// Serialisert streng (lagret i databasen)
a:3:{s:4:"home";s:18:"https://gammelt.no";s:7:"siteurl";s:18:"https://gammelt.no";s:11:"admin_email";s:18:"[email protected]";}

#Å bryte ned den serialiserte strengen

La oss dekode s:18:"https://gammelt.no":

• s = string (streng)
• 18 = lengde på strengen (antall tegn)
• "https://gammelt.no" = verdien

Det kritiske punktet: Tallet 18 representerer nøyaktig antall tegn i strengen "https://gammelt.no".

#Hva skjer ved enkel erstatning?

Original:

s:18:"https://gammelt.no"

Etter enkel SQL-erstatning (gammelt.no -> nytt-domene.no):

Problemet:

• Strenglengden endret seg fra 18 til 22 tegn.
• Serialiseringen sier fortsatt s:18 (forventer 18 tegn).
• PHP prøver å lese 18 tegn: "https://nytt-domen"
• Mangler slutten.
• Hele arrayen blir ugyldig.
• Data er korrupt.

Resultat: WordPress kan ikke lese innstillingene eller widgetene, så det nullstiller dem.

#Hvor finnes serialiserte data?

#Vanlige steder

1. wp_options-tabellen:

• siteurl og home.
• Widget-data (sidebars_widgets).
• Temamodifikasjoner (theme_mods_*).
• Utvidelsesinnstillinger.

2. wp_postmeta-tabellen:

• Egendefinerte felter (Custom Fields).
• ACF-feltdata.
• Vedleggsmetadata.

3. wp_usermeta-tabellen:

• Brukerpreferanser.

#Løsningen: Serialiserings-bevisste verktøy

Du trenger et verktøy som:

1. Av-serialiserer data (konverterer streng tilbake til PHP-array).
2. Erstatter teksten inne i datastrukturen.
3. Rekalkulerer antall tegn.
4. Re-serialiserer dataene.
5. Oppdaterer databasen.

#Metode 1: Wp-CLI (anbefalt)

Den profesjonelle måten: Hvis du har SSH-tilgang, er WP-CLI det beste verktøyet.

Grunnleggende bruk:

wp search-replace 'https://gammelt.no' 'https://nytt.no' --all-tables

Avanserte alternativer:

## DRY run (se hva som ville endret seg uten å gjøre det)
wp search-replace 'https://gammelt.no' 'https://nytt.no' --all-tables --dry-run

## Eksporter endringer til sql-fil først
wp search-replace 'https://gammelt.no' 'https://nytt.no' --all-tables --export=endringer.sql

Hvorfor WP-CLI er best:

• ✅ Håndterer serialisering korrekt.
• ✅ Raskt og effektivt.
• ✅ CLI-kontroll.
• ✅ Ingen utvidelsesoverhead.

#Metode 2: Better search replace plugin

For ikke-CLI brukere: Hvis du ikke har SSH-tilgang, bruk utvidelsen Better Search Replace.

Bruk:

1. Gå til Verktøy > Better Search Replace.
2. Skriv gammel URL: https://gammelt.no.
3. Skriv ny URL: https://nytt.no.
4. Velg tabeller.
5. Viktig: Merk av for “Run as dry run?” først.
6. Klikk “Run Search/Replace”.
7. Se over resultatene, fjern deretter “Dry run” og kjør på nytt.

#Metode 3: Interconnect/IT search-Replace-DB script

Eksternt PHP-skript: Et frittstående PHP-skript du laster opp via FTP. Nyttig hvis du ikke kommer inn i admin-panelet.

Advarsel:

• ⚠️ Dette skriptet gir full tilgang til databasen.
• ⚠️ Må slettes umiddelbart etter bruk (knappen “Delete Me”).
• ⚠️ Bruk aldri på produksjon med mindre det er absolutt nødvendig, og slett det med en gang.

#Oppsummering

I 2026 er korrekt håndtering av serialiserte data ikke valgfritt ved migrering av WordPress.

• Aldri bruk enkel SQL REPLACE.
• Aldri rediger databasefiler med tekstredigeringsprogram.
• Alltid bruk WP-CLI eller verktøy som Better Search Replace.

Dette sikrer at widgetene dine overlever flyttingen, og at nettstedet fungerer 100% på det nye domenet.

Utforsk våre profesjonell WordPress-utvikling for å ta prosjektet ditt videre.