WordPress Multisite-myter — afkræftet

WordPress Multisite har drevet alt fra personlige blog-netværk til massive publiceringsplatforme som WordPress.com. Alligevel, selv efter mere end et årti i kernen, består myter om det. Lad os adskille fakta fra fiktion — med virkelige eksempler og data til at understøtte det.

Myte 1: “Multisite er langsomt.”

Virkelighed: Multisite kan være lige så hurtigt som enkelt-site WordPress — forudsat at du følger de samme bedste praksisser. Hastighed afhænger af caching, forespørgsler og hosting-kvalitet, ikke af Multisite-funktionen selv.

• Side-caching og vedvarende objekt-caching (Redis eller Memcached) reducerer databasebelastningen drastisk.
• WordPress 6.1+ inkluderer nu Site Health-tjek for både side-cache og objekt-cache på grund af deres store præstationspåvirkning.

Kilde: WordPress Performance Team (Make/Core)

Konklusion: Multisite er ikke langsomt — dårlig caching eller ineffektiv kode er.

Myte 2: “Multisite er svært at opsætte.”

Virkelighed: Det tager kun få trin:

1. Tilføj define('WP_ALLOW_MULTISITE', true); til wp-config.php.
2. Gå til Værktøjer → Netværksopsætning.
3. Vælg underdomæner eller underkataloger.
4. Indsæt de genererede regler og log ind igen.

Kilde: Learn WordPress — Opsætning af et Multisite-netværk

Konklusion: Multisite er ikke “svært,” det er bare en engangsopsætning med et nyt admin-lag kaldet Netværksadmin.

Myte 3: “Multisite fungerer kun med underdomæner eller undermapper.”

Virkelighed: Siden WordPress 4.5 er domænekortlægning indbygget i kernen. Du kan tildele brugerdefinerede domæner til hvert undersite uden ekstra plugins.

Kilde: WordPress Multisite Dokumentation

Konklusion: Du kan bruge underkataloger, underdomæner eller helt brugerdefinerede domæner indbygget.

Myte 4: “Alle sites deler én databasetabel.”

Virkelighed: Hvert site i et Multisite-netværk får sit eget sæt tabeller (som wp_2_posts, wp_2_options osv.). Kun få tabeller — såsom site-registret og brugere — deles.

Kilde: Learn WordPress — Multisite Database Tabeller

Konklusion: Sites er isolerede på tabelniveau, ikke alle blandet sammen.

Myte 5: “Plugins og temaer skal være aktive overalt.”

Virkelighed: Multisite lader dig installere én gang, og derefter vælge:

• Netværksaktiver for alle sites
• Aktiver for site-admins at aktivere individuelt

Konklusion: Du styrer omfang — globalt når det er nødvendigt, lokalt når det ikke er.

Myte 6: “Multisite er kun for store virksomheder.”

Virkelighed: Multisite hjælper alle, der administrerer flere relaterede sites — uanset om det er et universitetsnetværk, SaaS-platform eller marketingbureau, der administrerer kunder. Størrelsen betyder ikke noget; behovet for centraliseret styring gør.

Konklusion: Selv små teams kan drage fordel af delte brugere, opdateringer og plugins.

Myte 7: “Multisite er en sikkerhedsrisiko.”

Virkelighed: Centraliseret styring forbedrer ofte sikkerheden. Multisite tilføjer en særlig Super Admin-rolle, der styrer netværksniveauændringer, mens almindelige admins kun administrerer deres egne sites.

Konklusion: Korrekt konfigureret Multisite kan reducere angrebsfladedrift på tværs af mange sites.

Myte 8: “Multisite skalerer ikke.”

Virkelighed: WordPress.com, Edublogs og store mediemærker beviser det modsatte. Ydeevne afhænger af caching, effektive plugins og infrastruktur — ikke af om det er Multisite eller ej.

Kilde: WordPress Performance Field Guide

Konklusion: Skalering af et Multisite-netværk følger samme spillebog som skalering af ethvert moderne WordPress-site.

Virkelige eksempler på WordPress Multisite i aktion

Kilder: Elegant Themes, WP Engine, Pantheon og WP Cloud multisite casestudier.

Den skjulte fare: Dårligt skrevne plugins

Selv et perfekt konfigureret Multisite-netværk kan blive langsommere af dårlige plugins. Fordi alle sites deler den samme plugin-kodebase, kan ét fejlbehæftet plugin påvirke ydeevnen på tværs af netværket.

Almindelige problemer forårsaget af dårlige plugins

• Tunge databaseforespørgsler eller uindekserede JOINs, der kører ved hver sideindlæsning.
• Ukontrollerede cron-job, der affyrer for ofte på tværs af alle undersites.
• Hukommelseslækager og overdreven objektoprettelse i løkker eller hooks som init.
• Option-tabel oppustning og autoloadede data, der sænker hver anmodning.
• Enkelt-site antagelser (hårdkodede tabelnavne, manglende switch_to_blog()-logik).

Sådan forhindrer du plugin-relaterede langsommeligheder

• Test i staging før netværksaktivering.
• Profilér forespørgsler med værktøjer som Query Monitor eller New Relic.
• Begræns netværksaktivering — aktiver plugins per site når det er muligt.
• Brug vedvarende objekt-caching (Redis eller Memcached).
• Undgå store autoloads i indstillinger og ryd op i gamle data.
• Vurder plugin-kvalitet — se efter aktiv vedligeholdelse og multisite-support i dokumentationen.

Kilder: WPMU DEV — Forbedr ydeevne på store sites,
Multidots — Multisite bedste praksisser

Konklusion: Dårligt skrevne plugins er den sande fjende af ydeevne — ikke Multisite selv.

Når Multisite ikke er det rigtige valg

• Du har brug for helt forskellige plugin-/temastakke per site uden delt kode.
• Du ønsker separate hostingmiljøer eller fysisk isolation.
• Du er afhængig af nicheplugins, der ikke er Multisite-kompatible.

Tommelfingerregel: Multisite udmærker sig, når du ønsker delt styring, kode og effektivitet — ikke når hvert site skal leve i sin egen silo.

Afsluttende tanker

WordPress Multisite er en af de mest misforståede, men alligevel kraftfulde funktioner i WordPress. Det er bevist i skala af store mærker, universiteter og SaaS-udbydere. Med ordentlig caching, plugin-styring og testning tilbyder det uovertruffen effektivitet til at administrere mange sites på én gang.

I stedet for at frygte Multisite, omfavn det som det, det virkelig er: en kraftmultiplikator for dit WordPress-netværk.

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