Sådan kører du WordPress-databasemigreringer uden at ødelægge dit websted 

En WordPress-databasemigrering lyder ligetil: eksporter databasen, importer den et andet sted hen, færdig. I praksis er det det trin, hvor flere WordPress-sider går i stykker end noget andet.

Årsagerne er specifikke. WordPress gemmer serialiserede PHP-objekter i sin database. En simpel find-og-erstat-funktion på en URL afbryder lydløst disse serialiserede data, hvilket efterlader dit websted med et ødelagt udseende på måder, der er vanskelige at spore. Plugin-opdateringer udløser migreringer af databaseskemaer, der ikke kan rulles tilbage med en filgendannelse. Det forkerte databasepræfiks, en manglende tabel eller en wp-config.php- fil, der ikke er synkroniseret, kan hver især producere en forskellig fejl, der peger i en anden retning.

Denne guide dækker alle scenarier, hvor du har brug for at køre en WordPress-databasemigrering, hvordan du gør hver enkelt uden datatab, og hvordan du retter de fejl, der ofte opstår, når noget går galt.

Typer af WordPress-databasemigreringer

Ikke alle databasemigreringer er ens. Metoden, risikoen og forberedelsen varierer afhængigt af migreringstypen.

Flytning af databasen til en ny vært eller et nyt domæne

Dette er det mest almindelige scenarie. Du skifter hostingudbyder, flytter fra HTTP til HTTPS eller omdøber domænet med et nyt. Databasens indhold er intakt, men alle URL'er, der er gemt i databasen, skal opdateres for at afspejle den nye placering.

Udfordringen: WordPress gemmer URL'er flere steder i databasen, inklusive serialiserede arrays i tabellerne wp_options og wp_postmeta. En manuel find-and-erstat-funktion på tværs af disse tabeller, der ikke tager højde for serialisering, vil uopmærksomt beskadige dataene.

Går fra iscenesættelse til produktion

Når du bygger et websted på staging og pusher det til produktion, skal databasen flyttes med den, og alle staging-URL'er skal erstattes med produktions-URL'er. Dette er en af ​​de mest almindelige kilder til problemer med migrering fra staging til live, fordi udviklere ofte pusher en fil uden at opdatere databasen.

Plugin-udløste skemamigreringer

Når plugins ændrer databasestrukturen under en opdatering, kører de en skemamigrering: en ændring af databasestrukturen i stedet for blot dataene i den. WooCommerces HPOS-migrering (High-Performance Order Storage) er et aktuelt eksempel. Medlemskabsplugins , der flytter medlemsdata til nye tabelstrukturer, er et andet.

Disse migreringer kører som en del af plugin-opdateringsprocessen. Du udløser dem ikke manuelt. Derfor kræver de forberedelse af staging, før opdateringen anvendes i produktionen.

  

Hvad du har brug for før enhver databasemigrering?

Færdiggør alle punkter på denne liste, før du kører en enkelt kommando eller klikker på Eksporter.

Fuld databasebackup. Eksporter hele MySQL-databasen fra dit nuværende miljø ved hjælp af phpMyAdmin, WP-CLI eller din hostingudbyders backupværktøj. Bekræft, at backupfilen åbnes og indeholder data, før du fortsætter. En beskadiget eksportfil, der opdages, efter at du allerede har overskrevet den oprindelige database, kan ikke gendannes uden en backup på hostingniveau.

Fuld filbackup. Din database kan ikke fungere uden de tilhørende WordPress-filer. Sikkerhedskopier hele din WordPress-installation sammen med databasebackupen.

wp-config.php-oplysninger for destinationen. Notér databasenavnet, brugernavnet, adgangskoden og værten for destinationsmiljøet. Disse er nødvendige for at forbinde dine WordPress-filer til den importerede database.

Et staging-miljø. Enhver databasemigrering bør testes i staging, før den køres i produktion. Dette gælder både for host-to-host-migreringer og migreringer af plugin-opdateringsskemaer.

Kompatibilitet med PHP-version bekræftet. Hvis du migrerer til en ny vært, der kører en anden PHP-version, skal du kontrollere, at dine plugins og temaer er kompatible med den nye version, før migreringen. Uoverensstemmelser mellem PHP-versioner efter migrering giver fejl, der ser ud til at være databaseproblemer, men som i virkeligheden er kompatibilitetsproblemer.

Sådan migrerer du en WordPress-database: 3 metoder

Den rigtige metode afhænger af dit tekniske niveau og størrelsen på din database. Alle tre håndterer serialiserede data korrekt, når de bruges som beskrevet nedenfor.

Metode 1: Migreringsplugin (nemmest)

Migrerings-plugins håndterer eksport, import, filoverførsel og URL-erstatning i én proces. De er det rigtige valg for de fleste webstedsejere uden kommandolinjeerfaring.

Anbefalede plugins:

Duplicator Pro håndterer databaser på op til flere gigabyte, understøtter planlagte migreringer og genererer en installationsfil, der automatisk håndterer URL-udskiftning. Det er den mest pålidelige løsning til store eller komplekse websteder.

All-in-One WP Migration opretter en enkelt arkivfil, der indeholder hele din WordPress-installation, inklusive databasen. Gratisversionen har en importstørrelsesgrænse på 512 MB. Premium-versionen fjerner denne grænse. Plugin'et håndterer udskiftning af serialiseret data under import.

WP Migrate (tidligere WP Migrate DB) er specifikt designet til migrering af kun databaser og push/pull mellem miljøer. Det håndterer serialiseret data korrekt og understøtter selektiv tabelmigrering, hvilket er nyttigt, når du kun vil trække indholdsdatabasen fra produktion til staging uden at overskrive dine staging-plugin-indstillinger.

Trin-for-trin med All-in-One WP-migrering:

• Installer og aktiver All-in-One WP Migration på dit kildewebsted

• Gå til All-in-One WP Migration > Eksport

• Vælg Eksporter til > Fil

• Vent på, at eksporten er færdig, og download .wpress-filen

• Installer All-in-One WP Migration på dit destinationswebsted

• Gå til All-in-One WP Migration > Import

• Træk og slip .wpress-filen, eller klik for at søge efter den

• Bekræft importen, når du bliver bedt om det. Plugin'et advarer dig om, at dette vil overskrive alt eksisterende indhold

• Når importen er færdig, skal du gå til Indstillinger > Permalinks og klikke på Gem ændringer uden at ændre noget. Dette rydder omskrivningsreglerne og løser de fleste 404-fejl, der opstår efter migreringen

Metode 2: phpMyAdmin (Manuel)

phpMyAdmin er den rigtige metode, når du har brug for fuld kontrol over migreringen, migrerer en stor database, som plugin-værktøjer ikke kan håndtere, eller har brug for at migrere en database uafhængigt af WordPress-filerne.

Eksport af databasen:

• Log ind på phpMyAdmin på dit kildehostingmiljø via dit hostingkontrolpanel

• Vælg din WordPress-database i venstre sidepanel

• Klik på fanen Eksporter

• Vælg brugerdefineret eksportmetode

• Sørg for, at alle tabeller er valgt

• Under Formatspecifikke indstillinger skal du markere Tilføj DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT / TRIGGER-sætning. Dette sikrer, at importen overskriver eksisterende tabeller korrekt i stedet for at forårsage fejl ved duplikerede indtastninger

• Under Indstillinger for dataoprettelse skal du markere Komplette indsættelser og Udvidede indsættelser

• Klik på Eksporter og gem .sql-filen

Import af databasen:

• Log ind på phpMyAdmin på dit destinationshostingmiljø

• Vælg eller opret destinationsdatabasen

• Klik på Importér tabellen

• Klik på Vælg fil, og vælg din .sql-fil

• Klik på Gå for at køre importen

Opdatering af URL'erne:

Efter importen skal du opdatere websteds-URL'en, der er gemt i databasen. Den enkleste metode for ikke-tekniske brugere er at køre følgende SQL-forespørgsler i phpMyAdmins SQL-faneblad, hvor du erstatter old-domain.com og new-domain.com med dine faktiske domæner:

UPDATE wp_options SET option_value = replace(option_value, 'https://old-domain.com', 'https://new-domain.com') WHERE option_name = 'websiteurl' ELLER option_name = 'home';

Kør ikke en fuld find-og-erstat-funktion på tværs af alle tabeller udelukkende ved hjælp af SQL. Dette vil beskadige serialiserede data. Brug WP-CLI-metoden nedenfor til den komplette erstatning.

Metode 3: WP-CLI (mest pålidelig for tekniske brugere)

WP-CLI er WordPress' kommandolinjegrænseflade. Dens search-replace-kommando er den mest pålidelige metode til at erstatte URL'er i en WordPress-database, fordi den som standard håndterer serialiserede data korrekt.

Forudsætninger: SSH-adgang til din server og WP-CLI installeret. De fleste administrerede WordPress-hosts (Kinsta, WP Engine, Cloudways) har WP-CLI tilgængelig som standard.

Eksportér databasen:

wp db eksport backup-$(dato +%Y%m%d).sql

Dette eksporterer den komplette database til en dateret .sql-fil i din nuværende mappe.

Importer databasen til destinationen:

wp db import backup-20260101.sql

Erstat backup-20260101.sql med dit faktiske filnavn.

Kør URL-erstatningen:

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

Flaget –precise sikrer, at serialiserede data håndteres korrekt. Flaget –all-tables anvender erstatningen på tværs af alle tabeller i databasen, inklusive tabeller oprettet af plugins.

Bekræft udskiftningen:

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

Kørsel med –dry-run viser dig, hvor mange udskiftninger der ville blive foretaget uden faktisk at foretage dem. Kør dette først for at kontrollere, at antallet ser korrekt ud, før du kører den live udskiftning.

Ryd cachen og omskriv reglerne:

wp cache-tømning

wp omskrivning flush

Hvordan håndteres serialiserede data under migrering?

Dette er den mest misforståede del af WordPress-databasemigrering og den mest almindelige årsag til brud efter migrering.

Hvorfor ødelægger Simple Find-Erstat WordPress?

WordPress gemmer nogle data i et serialiseret PHP-format. En serialiseret streng ser sådan ud:

a:2:{s:4:"hjem";s:22:"https://gammelt-domæne.com";}

s:22-delen betyder "en streng på 22 tegn". Hvis du kører en find-and-erstat-funktion, der ændrer old-domain.com til new-domain.com, ændres strenglængden, men antallet af s:22 opdateres ikke. WordPress forsøger at læse en streng på 22 tegn, finder en streng med en anden længde og producerer en fejl.

Fejlen viser sig ofte som en blank, hvid skærm, ødelagte widget-områder eller plugin-indstillinger, der ser tomme ud efter migrering. Det er vanskeligt at spore uden at kende til serialiserede data.

Hvordan kører man en sikker søgning-erstatning?

Brug en af ​​disse serialiseringsbevidste metoder:

WP-CLI (anbefales):

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

Better Search Replace-plugin: Installer Better Search Replace-plugin'et i WordPress. Det håndterer serialiseret data som standard og giver en testmulighed for at forhåndsvise ændringer, før de anvendes. Dette er den rigtige mulighed, hvis du ikke har WP-CLI-adgang.

Interconnect/it Search Replace DB: Et PHP-script, du uploader til din servers rod, kører via browser og sletter efter brug. Det håndterer serialiserede data og understøtter live- eller dry-run-tilstande.

Hvordan verificerer man, at søgning og erstatning har virket?

Efter udskiftningen skal du kontrollere disse steder:

• Gå til Indstillinger > Generelt i dit WordPress-dashboard. Bekræft, at WordPress-adressen og webstedsadressen viser dit nye domæne

• Besøg frontend'en på dit websted, og tjek browserens udviklerkonsol for advarsler om blandet indhold (HTTP-ressourcer indlæses på et HTTPS-domæne)

• Tjek dit mediebibliotek: Vises den korrekte URL, når du klikker på et billede?

• Kør en Screaming Frog-crawl eller brug Broken Link Checker til at scanne efter resterende URL'er fra gamle domæner

Plugin-udløste databasemigreringer i WordPress

I modsætning til host-to-host-migreringer udløser du ikke disse manuelt. De kører som en del af plugin-opdateringsprocessen, hvilket er grunden til, at forberedelse af staging er vigtigere her end andre steder.

Hvordan fungerer WooCommerce-databasemigreringer?

WooCommerce introducerede HPOS (High-Performance Order Storage) som en større strukturel ændring i, hvordan ordrer opbevares. Når du migrerer til HPOS, opretter WooCommerce nye dedikerede ordretabeller og flytter alle historiske ordredata til dem.

Denne migrering kører automatisk, når du aktiverer HPOS i WooCommerce-indstillingerne, eller når du opdaterer WooCommerce på et websted, hvor migreringen afventer. Den kan ikke fortrydes ved at rulle filer tilbage. Hvis migreringen kører på et websted, hvor nogle plugins ikke er HPOS-kompatible, vil disse plugins holde op med at fungere korrekt.

Sådan forbereder du dig: Før du aktiverer HPOS eller opdaterer WooCommerce på tværs af større versioner, skal du køre WooCommerces kompatibilitetstjekker ved at gå til WooCommerce > Status > HPOS. Den viser alle installerede plugins og om de er HPOS-kompatible. Løs ukompatibiliteter, før migreringen kører.

Hvordan fungerer migreringer af medlemskabsplugins?

Medlemskabs-plugins, herunder MemberPress, Paid Memberships Proog Restrict Content Pro, opretter deres egne brugerdefinerede databasetabeller til medlemsregistreringer, abonnementsdata og transaktionshistorik. Når disse plugins opdateres på tværs af større versioner, ændrer de nogle gange disse tabelstrukturer.

Da medlemsdata gemmes i brugerdefinerede tabeller i stedet for standard WordPress-tabeller, inkluderer migrerings-plugins muligvis ikke altid disse data i deres eksport som standard. Bekræft eksplicit, at dit backupværktøj dækker brugerdefinerede plugin-tabeller, før du migrerer et medlemswebsted.

Hvordan forbereder man sig, inden et plugin udløser en migrering?

• Opsæt et staging-miljø , der præcist afspejler din produktionsdatabase

• Anvend plugin-opdateringen på staging først

• Bekræft alle berørte funktioner (betaling, medlemslogin, abonnementsadministration) ved opsætning efter opdateringen

• Hvis stagingen godkendes, skal den samme opdatering anvendes på produktionen i et vindue med lav trafik

• Gem en verificeret sikkerhedskopi fra umiddelbart før produktionsopdateringen

Tjekliste til database efter migrering

Gennemgå alle elementer efter en databasemigrering, før du fortæller nogen, at migreringen er fuldført.

• WordPress-administratoren indlæser uden fejl ved den nye URL

• Webstedets frontend indlæses korrekt ved den nye URL

• Alle mediefiler indlæses korrekt (ingen ødelagte billeder)

• Kontaktformularer sender og sender bekræftelsesmails

• Brugerlogin fungerer for alle kontotyper

• Hvis WooCommerce: udfør en testbetaling fra start til slut

• Hvis medlemswebsted: log ind som medlem og bekræft adgang til indhold

• Google Search Console viser ingen indeksdækningsfejl efter genindsendelse af sitemap

• Ingen advarsler om blandet indhold (HTTP-ressourcer på et HTTPS-websted) i browserkonsollen

• Ingen gamle domæne-URL'er synlige i sidekilden eller browserens netværksfaneblad

• Caching-plugin -cache ryddet

• Permalinkstruktur ryddet: Indstillinger > Permalinks > Gem ændringer

Almindelige WordPress-databasemigreringsfejl og hvordan man retter dem

Forsøg ikke at køre migreringen igen, før du har identificeret fejlen. Hver fejl nedenfor fortæller dig præcis, hvad der gik galt, og hvad du skal ændre, før du prøver igen.

Fejl 1062: Duplikatindtastning for nøglen PRIMARY

Denne fejl vises, når du importerer en database til en destination, der allerede indeholder data. Importscriptet forsøger at indsætte en række med et ID, der allerede findes.

Rettelse: Før import skal du enten slette alle eksisterende tabeller i destinationsdatabasen eller sørge for, at din eksportfil indeholder DROP TABLE-sætninger. I phpMyAdmin skal du markere muligheden for at inkludere DROP TABLE-sætninger, når du eksporterer. I WP-CLI: wp db reset –yes, then wp db import backup.sql.

Fejl 2002: Kan ikke oprette forbindelse til MySQL-server

Denne fejl indikerer, at WordPress ikke kan oprette forbindelse til databaseserveren. Den vises normalt efter en migrering, når databaseværtsnavnet i wp-config.php ikke matcher det faktiske værtsnavn på den nye server.

Rettelse: Åbn wp-config.php og tjek DB_HOST-værdien. På de fleste delte hosts er det localhost. På administrerede WordPress-hosts kan det være et specifikt værtsnavn angivet i dit hosting-dashboard. Opdater DB_HOST-værdien, så den matcher din destinationsservers MySQL-værtsnavn.

Fejl 1045: Adgang nægtet for bruger

Denne fejl betyder, at brugernavnet eller adgangskoden til databasen i wp-config.php ikke stemmer overens med legitimationsoplysningerne til databasen på destinationsserveren.

Rettelse: Åbn wp-config.php og bekræft, at DB_USER og DB_PASSWORD matcher databasebrugerens legitimationsoplysninger på din destinationsserver. Gå til MySQL-databaser i cPanel, og bekræft, at brugeren er tildelt den korrekte database med Alle Privilegier.

Afsluttende tanker om WordPress-databasemigreringer

WordPress-databasemigreringer går oftest i stykker på grund af to ting: serialiserede data, som en simpel find-and-erstat-funktion korrumperer lydløst, og plugin-udløste skemamigreringer, der kører automatisk under opdateringer på uforberedte websteder.

Begge problemer har klare løsninger. Brug WP-CLI eller et serialiseringsbevidst søgning-erstatningsværktøj i stedet for SQL find-and-erstat. Forbered et staging-miljø, før du anvender plugin-opdateringer, der udløser skemamigreringer. Tag en verificeret sikkerhedskopi før hvert migreringstrin, og test den, før du bruger den.

De tre ovenfor omtalte migreringsmetoder dækker alle færdighedsniveauer: plugins til dem, der ønsker en guidet proces, phpMyAdmin til dem, der har brug for detaljeret kontrol, og WP-CLI til dem med kommandolinjeadgang. Vælg den metode, der passer bedst til dit miljø, og følg tjeklisten efter migreringen, før du lukker projektet.

Hvis du har brug for en WordPress-databasemigrering håndteret af et erfarent team, har Seahawk håndteret migreringer for hundredvis af WordPress-websteder på tværs af alle kompleksitetsniveauer.

Ofte stillede spørgsmål om WordPress-databasemigreringer