WordPress Multisite-myter — avkreftet

WordPress Multisite har drevet alt fra personlige bloggnettverk til massive publiseringsplattformer som WordPress.com. Likevel, selv etter mer enn et tiår i kjernen, vedvarer myter om det. La oss skille fakta fra fiksjon — med virkelige eksempler og data som støtter det.

Myte 1: «Multisite er tregt.»

Virkelighet: Multisite kan være like raskt som enkeltstående WordPress — forutsatt at du følger de samme beste praksisene. Hastighet avhenger av caching, spørringer og vertskvalitet, ikke selve Multisite-funksjonen.

• Sidecaching og vedvarende objektcaching (Redis eller Memcached) reduserer databaselasten drastisk.
• WordPress 6.1+ inkluderer nå Site Health-sjekker for både sidecache og objektcache på grunn av deres store ytelsespåvirkning.

Kilde: WordPress Performance Team (Make/Core)

Konklusjon: Multisite er ikke tregt — dårlig caching eller ineffektiv kode er det.

Myte 2: «Multisite er vanskelig å sette opp.»

Virkelighet: Det tar bare noen få trinn:

1. Legg til define('WP_ALLOW_MULTISITE', true); i wp-config.php.
2. Gå til Verktøy → Nettverksoppsett.
3. Velg underdomener eller underkataloger.
4. Lim inn de genererte reglene og logg inn på nytt.

Kilde: Learn WordPress — Sett opp et Multisite-nettverk

Konklusjon: Multisite er ikke «vanskelig», det er bare et engangsoppsett med et nytt administrasjonslag kalt Nettverksadministrasjon.

Myte 3: «Multisite fungerer bare med underdomener eller undermapper.»

Virkelighet: Siden WordPress 4.5 er domenekartlegging innebygd i kjernen. Du kan tilordne egendefinerte domener til hvert underside uten ekstra utvidelser.

Kilde: WordPress Multisite-dokumentasjon

Konklusjon: Du kan bruke underkataloger, underdomener eller helt egendefinerte domener naturlig.

Myte 4: «Alle sider deler én databasetabell.»

Virkelighet: Hver side i et Multisite-nettverk får sitt eget sett med tabeller (som wp_2_posts, wp_2_options, osv.). Bare noen få tabeller — som sideregisteret og brukere — deles.

Kilde: Learn WordPress — Multisite-databasetabeller

Konklusjon: Sider er isolert på tabellnivå, ikke alle samlet.

Myte 5: «Utvidelser og temaer må være aktive overalt.»

Virkelighet: Multisite lar deg installere én gang, deretter velge:

• Nettverksaktiver for alle sider
• Aktiver for sideadministratorer å aktivere individuelt

Konklusjon: Du kontrollerer omfang — globalt når nødvendig, lokalt når ikke.

Myte 6: «Multisite er bare for store bedrifter.»

Virkelighet: Multisite hjelper alle som administrerer flere relaterte sider — enten det er et universitetsnettverk, SaaS-plattform eller markedsføringsbyrå som administrerer kunder. Størrelsen spiller ingen rolle; behovet for sentralisert administrasjon gjør det.

Konklusjon: Selv små team kan dra nytte av delte brukere, oppdateringer og utvidelser.

Myte 7: «Multisite er en sikkerhetsrisiko.»

Virkelighet: Sentralisert styring forbedrer ofte sikkerheten. Multisite legger til en spesiell Super Admin-rolle som kontrollerer endringer på nettverksnivå, mens vanlige administratorer bare administrerer sine egne sider.

Konklusjon: Riktig konfigurert Multisite kan redusere avdrift i angrepsflaten på tvers av mange sider.

Myte 8: «Multisite skalerer ikke.»

Virkelighet: WordPress.com, Edublogs og store mediemerker beviser det motsatte. Ytelse avhenger av caching, effektive utvidelser og infrastruktur — ikke om det er Multisite eller ikke.

Kilde: WordPress Performance Field Guide

Konklusjon: Skalering av et Multisite-nettverk følger samme oppskrift som skalering av en hvilken som helst moderne WordPress-side.

Virkelige eksempler på WordPress Multisite i aksjon

Kilder: Elegant Themes, WP Engine, Pantheon og WP Cloud multisite case-studier.

Den skjulte faren: Dårlig skrevne utvidelser

Selv et perfekt konfigurert Multisite-nettverk kan bli bremset av dårlige utvidelser. Fordi alle sider deler samme utvidelseskodebase, kan én feiloppførende utvidelse påvirke ytelsen på tvers av nettverket.

Vanlige problemer forårsaket av dårlige utvidelser

• Tunge databasespørringer eller uindekserte JOIN-er som kjøres på hver sideinnlasting.
• Ukontrollerte cron-jobber som utløses for ofte på tvers av alle undersider.
• Minnelekkasjer og overdreven objektoppretting i løkker eller hooks som init.
• Opsjonstabelloppblåsing og autolastede data som bremser hver forespørsel.
• Enkeltstående sideantagelser (hardkodede tabellnavn, manglende switch_to_blog()-logikk).

Hvordan forhindre utvidelsesrelaterte nedbremsinger

• Test i staging før nettverksaktivering.
• Profiler spørringer med verktøy som Query Monitor eller New Relic.
• Begrens nettverksaktivering — aktiver utvidelser per side når mulig.
• Bruk vedvarende objektcaching (Redis eller Memcached).
• Unngå store autolaster i opsjoner og rydd opp gamle data.
• Vurder utvidelseskvalitet — se etter aktivt vedlikehold og multisite-støtte i dokumentasjonen.

Kilder: WPMU DEV — Forbedre ytelse på store sider,
Multidots — Multisite beste praksis

Konklusjon: Dårlig skrevne utvidelser er den virkelige fienden av ytelse — ikke Multisite i seg selv.

Når Multisite ikke er det riktige valget

• Du trenger helt forskjellige utvidelses-/temastabler per side uten delt kode.
• Du ønsker separate vertsmiljøer eller fysisk isolasjon.
• Du er avhengig av nisjeutvidelser som ikke er Multisite-kompatible.

Tommelfingerregel: Multisite utmerker seg når du ønsker delt styring, kode og effektivitet — ikke når hver side må leve i sin egen silo.

Avsluttende tanker

WordPress Multisite er en av de mest misforståtte, men likevel kraftfulle funksjonene i WordPress. Det er bevist i stor skala av store merkevarer, universiteter og SaaS-leverandører. Med riktig caching, utvidelsesstyring og testing gir det uovertruffen effektivitet for å administrere mange sider samtidig.

I stedet for å frykte Multisite, omfavn det som det virkelig er: en kraftmultiplikator for ditt WordPress-nettverk.

Kilder: WordPress.org-dokumentasjon, Learn WordPress, WP Engine, Elegant Themes, WPMU DEV, Multidots, Pantheon og WP Cloud.