Migrering og multisite, avansert WordPress-administrasjon

Migrering og Multisite er to forskjellige beslutninger som ofte blandes sammen. Migrering flytter filer, database og DNS. Multisite endrer hvordan flere nettsteder deler én WordPress-kodebase. Velg feil modell, og du arver nedetid, brukerkaos og staging som aldri speiler produksjon.

Denne veiledningen gir en praktisk rekkefølge: hvordan databasen overlever et domenebytte, hvordan flyttet gjøres uten nedetid, når Multisite faktisk lønner seg, hvordan domenemapping og roller fungerer, hvordan du flytter mellom enkeltinstallasjon og nettverk, og hvilke staging-feller som koster mest tid på norske .no-oppsett. Offisiell referanse: WordPress Multisite-håndboken.

#Hvordan bevare databasens integritet ved WordPress-migrering

De fleste migreringer feiler ikke på grunn av manglende filer, men på grunn av ødelagte databaseposter. WordPress lagrer en stor del av temainnstillinger, widget-oppsett og plugin-data (for eksempel Advanced Custom Fields eller sidebyggeroppsett) som serialiserte PHP-strenger.

#Hvorfor en SQL-erstatning ødelegger serialiserte PHP-data

Slik kan en innstilling se ut i tabellen wp_options:

a:2:{s:4:"host";s:9:"gammel.no";s:4:"port";i:3306;}

Her sier s:9 at strengen gammel.no er nøyaktig 9 tegn lang. Bytter du domenet med finn/erstatt i en teksteditor eller med en rå UPDATE wp_options SET option_value = REPLACE(...) til nytt-domene.no (14 tegn), står lengdefeltet fortsatt som s:9.

Neste gang WordPress kaller unserialize(), finner PHP 14 tegn der den ventet 9. Parseren gir meldingen unserialize(): Error at offset, gir opp og forkaster hele arrayen. Resultatet er at widgets forsvinner, oppsettvalg faller tilbake til standard og API-nøkler blir borte.

#Hvordan WP-CLI search-replace håndterer serialiserte data

WP-CLI håndterer serialisering selv. Kommandoen henter verdien inn i minnet, deserialiserer den, bytter strengen, regner ut lengdene på nytt og serialiserer igjen før den skriver til MySQL. Referansen for search-replace sier også at primærnøkler aldri endres. La dry-run være identisk med den ekte kjøringen, slik at forhåndsvisningen viser nøyaktig det som vil skje:

# 1. Dry-run: samme tabeller og flagg som den ekte kjøringen, ingenting skrives
wp search-replace 'https://gammel.no' 'https://nytt-domene.no' \
  --all-tables --skip-columns=guid --dry-run

# 2. Utfør erstatningen
wp search-replace 'https://gammel.no' 'https://nytt-domene.no' \
  --all-tables --skip-columns=guid

# 3. Tøm objektcache og generer omskrivingsregler på nytt
wp cache flush
wp rewrite flush --hard

To flagg fra eldre veiledninger trenger en korreksjon. --recurse-objects er allerede standard, så det endrer ingenting å legge det til. --precise er ikke det som gjør serialiserte data trygge: som standard kjører kommandoen raske SQL-spørringer og bytter selv til PHP for kolonner med serialiserte data, mens --precise tvinger PHP på alle kolonner. Det er tregere og bare verdt det for uvanlig komplekse strukturer. --skip-columns=guid betyr mer, av grunnen som forklares i avsnittet om site-URL lenger ned.

#Hvordan migrere WordPress uten nedetid

For nettbutikker og leadsider der hver transaksjon teller, fungerer en rekkefølge i fire faser.

#Fase 1: senk DNS-TTL 48 timer før

Senk TTL på domenets A-poster til 300 sekunder (5 minutter). Da oppdaterer DNS-cacher seg raskt når den nye server-IP-en publiseres. For .no-domener gjøres dette hos registraren eller DNS-leverandøren du bruker.

#Fase 2: inkrementell filsynkronisering med rsync

Klassisk FTP er tregt, ukryptert og feiler stille på store mediebibliotek. Bruk rsync over SSH for å speile filene direkte mellom serverne, og hopp over midlertidige cache-mapper:

rsync -avzP --delete \
  --exclude 'wp-content/cache/*' \
  --exclude 'wp-content/uploads/cache/*' \
  --exclude '*.log' \
  [email protected]:/var/www/vhosts/nettsted.no/public/ /var/www/html/

Flagget -a bevarer filrettigheter og tidsstempler, -z komprimerer dataene underveis, og -P lar en avbrutt overføring fortsette.

#Fase 3: byttevinduet

1. Slå på vedlikeholdsmodus på kildeserveren: wp maintenance-mode activate.
2. Lag en ren databasedump: wp db export bytte.sql --add-drop-table.
3. Overfør og importer dumpen på den nye serveren: wp db import bytte.sql.
4. Kjør wp search-replace for nye URL-er, HTTPS eller endrede stier.
5. Test lokalt ved å peke domenet mot den nye IP-en i din egen hosts-fil.

#Fase 4: DNS-bytte og kontroll

Pek A-posten til den nye IP-en. Siden TTL ble senket i fase 1, flytter trafikken seg i løpet av minutter. Når DNS har slått gjennom overalt, setter du TTL tilbake til normal verdi (86400 sekunder).

#Hvordan WordPress multisite er bygget opp

Multisite (nettverk) betyr én WordPress-installasjon, én filstruktur for core/temaer/plugins, og én database med egne tabeller per nettsted (wp_2_posts, wp_3_options, osv.). Super Admin styrer nettverket; hver site har egne Administratorer for innhold.

#Databasetabeller i WordPress multisite

En vanlig enkeltinstallasjon har 12 kjernetabeller. I Multisite skiller WordPress mellom globale data og data per nettsted:

• Globale nettverkstabeller: wp_users og wp_usermeta (én konto per person i hele nettverket, med ulike roller per site), og wp_blogs, wp_site og wp_sitemeta for nettverksinnstillinger, registrering og listen over nettsteder.
• Tabeller per nettsted: hvert nytt nettsted får sitt eget sett merket med site-ID, for eksempel wp_2_posts, wp_2_options og wp_2_comments.

+-----------------------------------------------------+
|             WordPress Multisite-skjema              |
+-----------------------------------------------------+
| Globale tabeller:                                   |
| - wp_users / wp_usermeta                            |
| - wp_blogs / wp_site / wp_sitemeta                  |
+-----------------------------------------------------+
| Hovedside (ID 1):                                   |
| - wp_posts, wp_options, wp_terms...                 |
+-----------------------------------------------------+
| Underside (ID 2, f.eks. oslo.merke.no):             |
| - wp_2_posts, wp_2_options, wp_2_terms...           |
+-----------------------------------------------------+
| Underside (ID 3, f.eks. bergen.merke.no):           |
| - wp_3_posts, wp_3_options, wp_3_terms...           |
+-----------------------------------------------------+

#Multisite eller separate installasjoner

Separate installasjoner betyr én kodebase og én database per nettsted. Oppdateringer, feil og plugins er isolert.

Velg Multisite når:

• Nettstedene er relaterte: franchise (oslo.merke.no, bergen.merke.no), campus, avdelinger under samme organisasjon, eller produktvarianter under samme merke.
• Dere vil dele temaer og plugins sentralt, og godta at en dårlig plugin-oppdatering treffer hele nettverket.
• Dere trenger én innlogging på tvers av flere sites (felles wp_users).

Velg separate installasjoner når:

• Kundene er urelaterte juridiske enheter. Isolasjon er da et krav, ikke en preferanse.
• Dere trenger ulike PHP-versjoner, ulike hosting-planer eller ulike sikkerhetssoner.
• Et team skal kunne ødelegge staging på prosjekt A uten å påvirke prosjekt B.

Flerspråk alene er sjelden nok begrunnelse for Multisite. WPML, Polylang eller egne språkvarianter på én installasjon er ofte enklere å drifte enn et språk-per-site-nettverk. Håndboken peker på det samme: må nettstedene dele mye data eller brukere, eller trenger de bare ulike temaer per seksjon, kan ett nettsted med en plugin passe bedre enn et nettverk.

#Krav før du oppretter et WordPress multisite-nettverk

Kapittelet Before you create a network lister begrensninger som skjermen Network Setup håndhever, og de fleste mislykkede konverteringer kolliderer med en av dem.

Nettverket kan ikke opprettes når WordPress-adressen bruker en annen port enn 80 eller 443. Undernett-installasjon (sub-domains) blokkeres når WordPress-URL-en inneholder en sti (WordPress ligger ikke i dokumentroten), når adressen er localhost, eller når den er en IP-adresse som 127.0.0.1. For lokal testing foreslår håndboken å peke et eget vertsnavn mot 127.0.0.1 i hosts-filen. Underkatalog-installasjon (sub-directories) blokkeres når installasjonen er eldre enn én måned, fordi innleggene på hovedsiden ville kollidert med stiene til undersidene. I et stibasert nettverk får innleggene på hovedsiden i tillegg prefikset /blog/.

På serversiden trenger Apache mod_rewrite med støtte for .htaccess, FollowSymLinks som ikke er slått av, og AllowOverride satt til All eller Options All for vhosten. Pene permalenker må allerede virke på enkeltinstallasjonen. Bestem domenet, også spørsmålet om www, før aktivering. Skal WordPress ligge i egen katalog, gjøres også det først. Wildcard-DNS trengs bare når brukere selv oppretter undernett-sites; sites du legger til manuelt kan bruke egne DNS-poster eller virtuelle verter.

#Slik oppretter du et WordPress multisite-nettverk steg for steg

Prosedyren i Create a Network har en rekkefølge som betyr noe. Ta backup av database og filer. Deaktiver alle plugins; de kan aktiveres igjen når nettverket finnes. Legg deretter bryteren inn i wp-config.php over linjen /* That's all, stop editing! Happy publishing. */:

// Steg 1: vis menyen for nettverksoppsett i kontrollpanelet
define('WP_ALLOW_MULTISITE', true);

Gå til Verktøy > Nettverksoppsett, velg undernett (site.domene.no) eller underkatalog (domene.no/site/), og lim inn de genererte konstantene i wp-config.php rett etter linjen med WP_ALLOW_MULTISITE:

// Steg 2: aktiver nettverket (undernett-variant)
define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', true);
define('DOMAIN_CURRENT_SITE', 'domene.no');
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);

Samme skjerm viser omskrivingsregler. De erstatter den eksisterende WordPress-blokken i .htaccess (på Nginx blir de regler i server-blokken). Ta kopi av begge filene før du endrer dem. Logg deretter inn på nytt via lenken WordPress viser; noen ganger må nettleserens cookies tømmes. «Mine nettsteder» får da menyen Network Admin. Å bytte mellom undernett og underkatalog senere er mulig, men håndboken advarer om at det kanskje ikke blir enkelt, så velg før første underside finnes.

#Domenemapping og .no-DNS

Nettverket kan kjøre i underkatalog (example.no/site2/), undernett (site2.example.no) eller med egne toppdomener per site. Domenemapping er dokumentert i Multisite domain mapping, og siden WordPress 4.5 er det en innebygd funksjon uten egen plugin.

For undernett må DNS og server støtte wildcard (*.example.no) eller eksplisitte A/AAAA/CNAME-poster per site. På norske registrarer: sjekk at wildcard faktisk propageres, og at Let’s Encrypt-utstedelse dekker alle hostnavn du peker inn. Håndboken anbefaler TLS på hoveddomenet og SNI-sertifikater for de andre, slik at all innlogging i admin er kryptert.

For egne .no-domener per site:

1. Senk TTL (f.eks. til 300-600 sekunder) minst ett døgn før bytte.
2. Pek domenet til samme origin som nettverket (proxy/CDN eller direkte til host).
3. Oppdater site-URL i Network Admin (Nettsteder > Rediger nettsted, feltet Site Address med full URL som https://merke.no) etter at HTTP svarer med riktig vhost, ikke før.
4. Kjør serialiserings-sikker search-replace for gamle URL-er i innlegg, media og options.

Cookie-domene og COOKIE_DOMAIN i wp-config.php må matche innlogging på tvers av sites. Feil cookie-domene gir «innlogget på hovedsiden, utlogget på filialen», en klassiker etter domenemapping. Får du feilmelding om blokkerte cookies, eller innloggingen feiler uten melding, er håndbokens løsning denne linjen etter nettverkskonstantene:

define( 'COOKIE_DOMAIN', $_SERVER['HTTP_HOST'] );

Offentlige .no-nettverk: felles tema må møte WCAG-kravene Digdir/uutilsynet forventer, ellers arver alle sites samme feil i kontrast, tastatur og skjemaer.

#Brukerroller på tvers av sites

I Multisite ligger brukere i én tabell. Medlemskap og roller er per nettsted.

Konsekvenser i praksis:

• En Administrator på bergen.merke.no kan ikke installere plugins. Det er Super Admin-jobb.
• Sletting av en bruker i nettverket fjerner kontoen overalt, ikke bare på én filial.
• SSO-ønsker (én innlogging til flere merkevarer) er naturlig i Multisite; isolasjon mellom kunder er det ikke.

Dokumenter hvem som er Super Admin, og begrens antallet. For mange Super Admins er den vanlige årsaken til «noen aktiverte en plugin i Network Admin og tre sites falt».

#Slik slår du sammen WordPress-sider til Multisite

Å aktivere nettverk på en eksisterende installasjon, som beskrevet over, er ikke det samme som å slå sammen fem enkeltinstallasjoner. Hver ekstra site må inn via eksport/import (WXR), WP-CLI, eller et verktøy som forstår Multisite-tabellprefiks.

Anbefalt rekkefølge for sammenslåing:

1. Ta full fil- og databasebackup av alle kilder (3-2-1: tre kopier, to medier, én off-site).
2. Bygg nettverket på staging med samme PHP-versjon som produksjon.
3. Opprett tomme sites i Network Admin med endelige domener/undernett.
4. Importer innhold per site. Kjør deretter search-replace for gamle URL-er inne i den site-spesifikke tabellsettet, med --url=<site> og uten --network.
5. Map brukere: felles e-poster blir én konto; roller må tildeles per site.
6. Verifiser media (uploads-stier i Multisite ligger under wp-content/uploads/sites/{id}/).
7. Senk DNS-TTL, bytt, og ha rollback-SQL klar.

Amatørfeil: å bytte gammel.no til ny.no i SQL-dumpen med finn/erstatt. Serialiserte arrays lagrer strengelengde; når den ikke stemmer, dør widgets og plugin-innstillinger stille. Bruk wp search-replace 'https://gammel.no' 'https://ny.no' --skip-columns=guid med dry-run først.

#Flytte ett nettsted ut av WordPress Multisite

Noen ganger er nettverket feil modell. Da eksporterer du ett nettsted ut:

1. Identifiser blog_id og tabellprefiks (wp_5_ osv.), for eksempel med wp site list --fields=blog_id,url.
2. Eksporter innhold (WXR) eller klon tabellene til en ny database med standard wp_-prefiks.
3. Kopier media fra uploads/sites/{id}/ til vanlig uploads/.
4. Oppdater siteurl og home, deretter search-replace.
5. Installer bare de plugins/temaene site faktisk brukte, ikke hele nettverkskatalogen blindt.

Planlegg redirects fra gamle undernett-URL-er til det nye toppdomenet. Ellers mister du lenkekapital og får 404-støy i Search Console.

#Hvordan endre site-URL i WordPress etter en flytting

Innstillinger > Generelt har to felt: WordPress-adresse (URL), der kjernefilene ligger, og Nettstedsadresse (URL), adressen besøkende skriver inn. Når en flytting gjør admin utilgjengelig, beskriver migreringskapittelet fire måter å rette dem på. De gjelder enkeltinstallasjoner; for Multisite viser håndboken til databasen, som neste avsnitt tar for seg.

1. wp-config.php: define( 'WP_HOME', 'https://example.no' ); og define( 'WP_SITEURL', 'https://example.no' );. Det hardkoder verdiene, og feltene i Generelt kan ikke lenger redigeres.
2. functions.php: to kall til update_option() for siteurl og home i det aktive temaet, lastet én gang og så fjernet. Håndboken sier tydelig at koden ikke skal bli liggende.
3. RELOCATE: define('RELOCATE', true); i wp-config.php, åpne deretter wp-login.php på den nye adressen. Det retter bare site-URL-en og ingenting annet, og å la konstanten stå er usikkert fordi den i enkelte oppsett lar en angriper endre adressen. Fjern den med en gang.
4. Database eller WP-CLI: rediger siteurl og home i wp_options, eller kjør wp option update home 'https://example.no' og wp option update siteurl 'https://example.no'.

Samme kapittel har en regel som tåler gjentakelse: endre aldri kolonnen guid i wp_posts. Feedlesere bruker GUID for å kjenne igjen innlegg de allerede har vist, så en omskriving får gamle innlegg til å dukke opp som nye. Derfor bruker WP-CLI-eksempelet i dokumentasjonen --skip-columns=guid. Gamle adresser kan også ligge i transients; de kan trygt slettes i den migrerte kopien (wp transient delete --all) fordi WordPress bygger dem opp igjen ved behov.

Flytting til en annen katalog på samme server har sin egen rekkefølge: endre begge URL-ene i Innstillinger først, flytt filene etterpå. Er filene flyttet først, er håndbokens løsning en midlertidig symlenke fra gammel til ny sti (ln -s /path/to/new /path/to/old), og deretter fungerer de vanlige stegene.

#Hvordan kjøre wp search-replace i et multisite-nettverk

I Multisite berører wp search-replace bare tabellene til gjeldende nettsted, med mindre du sier noe annet. Kommandoreferansen definerer omfangene:

• uten flagg: tabeller registrert i $wpdb for nettstedet angitt med --url (hovedsiden som standard),
• --network: alle tabeller registrert i $wpdb i hele nettverket,
• --all-tables-with-prefix: alle tabeller med WordPress-prefikset, registrert eller ikke,
• --all-tables: alle tabeller i databasen uansett prefiks. Flagget overstyrer --network, så i en database som deles med andre applikasjoner når det også deres tabeller.

Tabeller uten primærnøkkel hoppes over i stillhet; wp db query 'DESCRIBE <tabell>' viser om PRI finnes. Den dokumenterte måten å gjøre et produksjonsnettverk om til en lokal kopi skriver også om nettverkstabellene eksplisitt:

wp search-replace --url=example.no example.no example.test \
  'wp_*options' wp_blogs wp_site --network --skip-columns=guid

--export=nettverk.sql skriver de omformede dataene til en fil i stedet for den levende databasen, noe som passer når importen skjer på den nye serveren. Før og etter endringen lister du alle nettsteder med wp site list og sammenligner de lagrede adressene:

for url in $(wp site list --field=url); do
  echo "$url $(wp option get siteurl --url="$url")"
done

Håndbokens notater om flytting av Multisite setter rammene. Samme domene på ny server: kopier filer og database akkurat som for en enkeltinstallasjon. Nytt domene: flytt filene, oppdater DOMAIN_CURRENT_SITE i wp-config.php og .htaccess hvis mappen er endret, gå så gjennom wp_site og wp_blogs (domene og sti) og, i hver wp_N_options-tabell, home, siteurl og fileupload_url. Bytte mellom undernett og underkatalog krever i tillegg endret SUBDOMAIN_INSTALL og nye omskrivingsregler.

#Vanlige staging-feil i WordPress Multisite

Staging er der Multisite oftest går galt, ikke i produksjon.

URL-er hardkodet i nettverket. Et kloningsverktøy som bare bytter hoveddomenet, men lar wp_blogs / wp_site peke på produksjon, logger redaktører inn på feil miljø eller blander cookies.

Search-replace uten å ekskludere GUID / uten dry-run. Kjør alltid dry-run. Avgrens tabeller når du bare flytter én site.

Cron og e-post. Nettverkskron (wp-cron.php) og utgående e-post fra staging må ikke treffe ekte kunder. Blokkér utgående SMTP på staging, eller pek til en sink.

.no-DNS og staging-subdomener. staging.merke.no trenger egen DNS og ofte egen TLS. Wildcard-sertifikat som dekker *.merke.no dekker ikke staging.andre.no. Test HTTPS før du inviterer innholdsredaktører.

Plugin-aktivering på nettverksnivå. En test-plugin på staging er greit. Samme handling i prod uten canary-site er ikke greit. Hold minst én canary-site der nye plugins aktiveres først.

WooCommerce i nettverk. Hvis nettverket er en butikkjede, test Vipps-callbacks per site-URL. Webhooks som fortsatt peker til staging etter go-live er dyre. Uten e-handel: hold migreringen til innhold, media og roller.

#Når passer Multisite, migrering eller egen installasjon

#Hva bør stå på sjekklisten før WordPress-migrering

1. Backup verifisert (gjenopprettingstest, ikke bare filstørrelse).
2. PHP-versjon og extensions like på staging og prod.
3. wp search-replace --dry-run uten overraskelser, med samme flagg som den ekte kjøringen.
4. Innlogging som Super Admin og som site-Administrator.
5. Media-URL-er laster over HTTPS på alle mapped domener.
6. wp site list --field=url gir den forventede listen over adresser.
7. DNS-TTL senket; rollback-plan skrevet (hvem snur A-record, hvor ligger forrige SQL).
8. For offentlige .no-sites: rask tastatur- og skjermlesersjekk av felles tema mot gjeldende WCAG-praksis.

Migrering er mekanikk. Multisite er driftsmodell. Bland dem, og du fikser DNS mens du egentlig burde ha skilt kundene, eller omvendt.

Trenger du hjelp til nettverksdesign, flytting mellom enkeltinstallasjon og nettverk eller dry-run før DNS-bytte, tar vi det under WordPress-utvikling.