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

#Multisite eller separate installasjoner

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.

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.

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

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.

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

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

#Migrering: enkeltinstallasjon til Multisite

Å aktivere nettverk på en eksisterende installasjon er beskrevet i Create a Network: backup, WP_ALLOW_MULTISITE, Network Setup, deretter wp-config.php og .htaccess/nginx-regler fra veiviseren.

Det 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.
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' --precise med dry-run først.

#Migrering: Multisite tilbake til enkeltinstallasjon

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

1. Identifiser blog_id og tabellprefiks (wp_5_ osv.).
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 lenkjekapital og får 404-støy i Search Console.

#Staging-feller i 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.

#Beslutningstabell

#Sjekkliste før go-live

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.
4. Innlogging som Super Admin og som site-Administrator.
5. Media-URL-er laster over HTTPS på alle mapped domener.
6. DNS-TTL senket; rollback-plan skrevet (hvem snur A-record, hvor ligger forrige SQL).
7. 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, single↔multi-flytt eller dry-run før DNS-bytte, tar vi det under WordPress-utvikling.