Ein Plugin ist multisite-kompatibel, wenn es in einem WordPress-Netzwerk sauber zwischen netzwerkweiten und Site-eigenen Daten trennt, sich je nach Bedarf netzwerkweit oder pro Website aktivieren lässt und auf jeder Subsite die nötigen Tabellen und Einstellungen anlegt. Ob das zutrifft, erfährst du aus der Plugin-Beschreibung, beim Entwickler und vor allem durch einen Test auf einer geklonten Staging-Umgebung. In diesem Leitfaden zeigen wir dir, worauf du achtest, welche Fehlerbilder typisch sind und wie du Plugins einführst, ohne dein ganzes Netzwerk zu riskieren.
Kurz gesagt
- Zwei Aktivierungswege: Plugins lassen sich pro Website oder für das gesamte Netzwerk aktivieren. Manche funktionieren nur netzwerkweit, andere besser pro Site.
- Prüfen vor Installieren: Plugin-Seite lesen, beim Entwickler nachfragen, Changelog und Support-Forum auf Multisite-Hinweise durchsehen.
- Typische Fehler: fehlende Tabellen auf Subsites, überschriebene Einstellungen, Admin-Hinweise auf jeder Site.
- Immer erst Staging: Jede Plugin-Änderung testest du auf einem realistischen Klon, nie direkt im Live-Netzwerk.
- Lizenzen klären: Bei Premium- und WooCommerce-Erweiterungen prüfst du vorab, ob die Lizenz pro Site oder pro Netzwerk gilt.
Inhaltsverzeichnis
- Was Multisite-Kompatibilität bei Plugins bedeutet
- Wer im Netzwerk über Plugins entscheidet
- Typische Fehlerbilder bei inkompatiblen Plugins
- Must-Use-Plugins: zentral, dauerhaft, mit Sorgfalt einsetzen
- Vor der Installation prüfen: die Checkliste
- Sicher testen: so führst du ein Plugin ins Netzwerk ein
- WooCommerce und Premium-Lizenzen im Netzwerk
- Wann sich Multisite trotz Plugin-Fragen lohnt
- Dein Multisite-Netzwerk in erfahrenen Händen
- Häufige Fragen
- Quellen
Was Multisite-Kompatibilität bei Plugins bedeutet
In einer WordPress-Multisite teilen sich alle Websites dieselbe Codebasis: einen WordPress-Kern, einen Plugin-Ordner, einen Theme-Ordner. Jede Site behält aber eigene Beiträge, Seiten, Benutzerrollen und Optionen. In der Datenbank werden deshalb einige Tabellen netzwerkweit geteilt, andere pro Website angelegt. Genau an dieser Grenze entscheidet sich, ob ein Plugin im Netzwerk zuverlässig läuft.
Ein Plugin, das nur für eine Einzelinstallation geschrieben wurde, geht oft stillschweigend davon aus, dass es genau eine Optionstabelle und genau einen Satz Einstellungen gibt. Im Netzwerk kann das bedeuten: Eine Einstellung auf Site A taucht plötzlich auf Site B auf, oder eine Subsite findet ihre eigenen Daten nicht. Wenn du das Grundprinzip eines Netzwerks noch einmal nachlesen möchtest, findest du es in unserem Beitrag zum Multisite-Netzwerk in WordPress.
Netzwerkweit oder pro Website aktivieren
WordPress kennt in der Multisite zwei Aktivierungsarten. Laut der offiziellen Dokumentation zur Multisite-Netzwerkverwaltung können Plugins pro Website oder für das gesamte Netzwerk aktiviert werden, und einige Plugins funktionieren nur, wenn sie netzwerkweit aktiv sind. Umgekehrt arbeiten manche Plugins am besten mit Einzel-Site-Aktivierung, weil sie dann Daten und Einstellungen in der Tabelle der jeweiligen Site speichern statt in den Netzwerktabellen.
Technisch steuert WordPress das über die Funktion activate_plugin mit dem Parameter $network_wide. Die Funktion lädt das Plugin bei der Aktivierung zunächst in einer Art Sandbox und bricht ab, wenn dabei ein Fehler auftritt. Für dich als Betreiber heißt das:
- Netzwerkweit aktivieren eignet sich für Funktionen, die jede Site braucht: Sicherheits-Plugins, Caching-Lösungen, Werkzeuge für Backups oder Formulare, die überall gleich laufen sollen.
- Pro Website aktivieren eignet sich für Funktionen, die nur einzelne Sites betreffen: ein Shop-Plugin auf der Shop-Site, ein Buchungstool auf der Standort-Site, ein Spezial-Plugin für eine Kampagnen-Landingpage.
Passive und aktive Kompatibilität
In der Praxis hilft eine einfache Unterscheidung. Passiv kompatibel ist ein Plugin, das ohne besondere Multisite-Logik funktioniert, etwa weil es nur Inhalte ausgibt und keine eigenen Tabellen anlegt. Aktiv kompatibel ist ein Plugin, das Multisite gezielt unterstützt: Es erkennt die Netzwerkaktivierung, richtet Tabellen für jede Subsite ein, trennt Netzwerk- und Site-Einstellungen und reagiert, wenn eine neue Site angelegt wird.
Für einfache Plugins reicht passive Kompatibilität meist aus. Je mehr ein Plugin speichert, synchronisiert oder verwaltet, desto wichtiger ist aktive Multisite-Unterstützung. Gute Plugin-Entwickler werten bei der Aktivierung aus, ob netzwerkweit oder für eine einzelne Site aktiviert wird, und legen Daten entsprechend in den Netzwerk-Metadaten oder in den Optionen der jeweiligen Site ab.
Wer im Netzwerk über Plugins entscheidet
Eine Multisite hat eine klare Rechteverteilung. Nach der offiziellen Übersicht zu Rollen und Berechtigungen in WordPress liegen Netzwerkverwaltung, Plugin-Verwaltung für das Netzwerk und Netzwerk-Upgrades beim Super Admin. Site-Administratoren haben diese Rechte nicht automatisch.
Das ist ein Sicherheitsgewinn: Nicht jede Abteilung oder jeder Standort kann eigenmächtig Plugins installieren, die das ganze Netzwerk betreffen. Es bedeutet aber auch, dass die Verantwortung für Kompatibilitätsprüfungen zentral liegt. Wenn einzelne Site-Admins mehr Spielraum brauchen, lässt sich das gezielt regeln. Welche Wege es dafür gibt, zeigen wir in unserem Beitrag WordPress-Benutzerrechte erweitern.
Multisite selbst wird übrigens nicht per Klick eingeschaltet. Laut der Dokumentation zum Netzwerk-Einrichtungsbildschirm setzt die Aktivierung eine manuelle Konfiguration in der wp-config.php voraus. Erst danach steht die Netzwerkverwaltung zur Verfügung, in der du Plugins zentral steuerst.
Typische Fehlerbilder bei inkompatiblen Plugins
Die meisten Multisite-Probleme folgen wiederkehrenden Mustern. Wenn du sie kennst, erkennst du die Ursache schneller.
| Fehlerbild | Woran du es erkennst | Wahrscheinliche Ursache |
|---|---|---|
| Fehlende Tabellen auf Subsites | Plugin läuft auf der Hauptsite, auf anderen Sites erscheinen Datenbankfehler oder leere Bereiche | Das Plugin legt bei Netzwerkaktivierung Tabellen nur für eine Site an |
| Überschriebene Einstellungen | Änderungen auf Site A wirken sich auf Site B aus | Einstellungen werden ohne Site-Kontext gespeichert |
| Admin-Hinweise überall | Jede Subsite zeigt Lizenz-, Update- oder Werbehinweise | Hinweise sind nicht auf den Super Admin beschränkt |
| Neue Sites ohne Funktion | Frisch angelegte Sites haben das Plugin aktiv, aber ohne Daten | Plugin reagiert nicht auf das Anlegen neuer Sites |
| Abbruch bei Aktivierung | Fehlermeldung, Plugin bleibt inaktiv | Fataler Fehler im Plugin-Code, WordPress stoppt die Aktivierung |
| Plugin plötzlich deaktiviert | Nach Update oder Umzug ist ein Plugin inaktiv | Plugin-Datei fehlt oder ist ungültig |
Den letzten Punkt beschreibt die Entwicklerreferenz zu validate_active_plugins: WordPress prüft aktive Plugins, deaktiviert ungültige und gibt die Fehler zurück. In der Multisite werden dabei auch netzwerkweit aktive Plugins berücksichtigt, wenn der angemeldete Benutzer die passende Berechtigung hat.
Bei mehrsprachigen Netzwerken kommt ein weiteres Feld dazu, denn Übersetzungs-Plugins greifen tief in Inhalte und URLs ein. Typische Stolpersteine dort beschreiben wir im Beitrag zu Problemen mit Mehrsprachigkeit in WordPress.
Must-Use-Plugins: zentral, dauerhaft, mit Sorgfalt einsetzen
Must-Use-Plugins, kurz MU-Plugins, liegen in einem eigenen Ordner und sind im Netzwerk ein beliebtes Werkzeug für Funktionen, die überall gelten sollen. Laut der offiziellen Dokumentation zu Must-Use-Plugins werden sie automatisch auf allen Sites der Installation geladen und lassen sich nicht über wp-admin deaktivieren. Sie führen keine Aktivierungs-Hooks aus und zeigen keine normalen Update-Hinweise.
Daraus ergeben sich drei Regeln für den sicheren Einsatz:
- Kein Ersatz für normale Plugins mit Installationsroutine. Ein Plugin, das bei der Aktivierung Tabellen oder Optionen anlegt, gehört nicht ungeprüft in den MU-Ordner, weil diese Routine dort nicht läuft.
- Gründlich testen. WordPress empfiehlt, MU-Plugins vor dem Live-Einsatz sorgfältig zu prüfen. Ein fehlerhaftes MU-Plugin kann die gesamte Installation beeinträchtigen.
- Updates selbst im Blick behalten. Da keine Update-Hinweise erscheinen, braucht es einen festen Prozess, etwa über Versionskontrolle.
Gerade für netzwerkweite Logik wie Sicherheitsregeln, zentrale Einstellungen oder Anpassungen an Benutzerrollen sind schlanke MU-Plugins oft die eleganteste Lösung, wenn sie sauber entwickelt und versioniert sind.
Vor der Installation prüfen: die Checkliste
Bevor ein neues Plugin ins Netzwerk kommt, gehst du diese Punkte durch. Die offizielle Multisite-Dokumentation rät ausdrücklich, die Repository-Seite des Plugins zu prüfen oder den Entwickler zu kontaktieren. Wir ergänzen das um die Punkte, die sich in der Praxis bewährt haben.
- Plugin-Beschreibung lesen. Suche nach Hinweisen wie „Multisite“, „Network“ oder „Netzwerk“. Fehlt jeder Hinweis, ist das kein Ausschluss, aber ein Grund für einen besonders gründlichen Test.
- Changelog durchsehen. Einträge zu Multisite-Fehlerbehebungen zeigen, dass der Entwickler das Szenario kennt und pflegt.
- Support-Forum durchsuchen. Offene Threads zu Netzwerkproblemen verraten dir mehr als jede Werbeaussage.
- Beim Entwickler nachfragen. Frag konkret: Netzwerkweit oder pro Site aktivieren? Was passiert bei neuen Subsites? Wo werden Einstellungen gespeichert?
- Lizenzmodell klären. Gilt die Lizenz pro Domain, pro Site oder für das ganze Netzwerk?
- Dateien verifizieren. Mit WP-CLI lassen sich laut Dokumentation zu wp plugin verify-checksums Plugin-Dateien gegen die von WordPress.org erwarteten Prüfsummen prüfen. Mit –all prüfst du alle installierten Plugins, mit –url legst du in der Multisite die Ziel-Site fest.
- Aktivierungsart festlegen. Entscheide vorab, ob das Plugin netzwerkweit oder nur auf bestimmten Sites laufen soll, und dokumentiere die Entscheidung.
Sicher testen: so führst du ein Plugin ins Netzwerk ein
Ein Fehler in einer Multisite betrifft im schlimmsten Fall nicht eine Website, sondern alle. Deshalb testest du jede Plugin-Einführung und jedes größere Update in einer geschützten Umgebung. Bewährt hat sich, Änderungen zuerst auf einer geklonten Staging-Website zu testen und Konflikte systematisch einzugrenzen.
So sieht ein bewährter Ablauf aus:
- Realistischen Klon erstellen. Kopiere das komplette Netzwerk mit Datenbank, Plugins, Themes und mehreren repräsentativen Subsites auf einen Staging-Server oder in eine lokale Umgebung.
- Plugin installieren und gezielt aktivieren. Teste beide Varianten, die infrage kommen: netzwerkweit und pro Site.
- Jede Subsite-Art prüfen. Hauptsite, eine Shop-Site, eine mehrsprachige Site, eine frisch angelegte Site. Neue Sites decken viele Fehler auf.
- Fehlerprotokolle auswerten. Debug-Log aktivieren und ein Diagnose-Plugin wie Query Monitor nutzen, um PHP-Fehler, Datenbankabfragen und Hooks pro Site zu sehen.
- Konflikte eingrenzen. Tritt ein Problem auf, wechselst du auf Staging testweise auf ein Standard-Theme, deaktivierst die anderen Plugins und aktivierst sie einzeln wieder.
- Rollback planen. Lege fest, wie du im Live-Netzwerk zurückgehst, wenn doch etwas schiefgeht: Backup, Versionsstand, Verantwortliche.
- Live ausrollen und beobachten. Nach dem Rollout prüfst du die wichtigsten Seiten aller Sites und behältst die Logs in den ersten Tagen im Blick.
Taucht im Live-Betrieb ein Konflikt auf, deaktivierst du das betroffene Plugin und wendest dich an den Entwickler. Wer mit Agentur-Teams arbeitet, verankert diesen Ablauf am besten fest im Release-Prozess. Wie das aussieht, zeigen unsere Beiträge zu Deployment-Workflows für Agenturen und zum sicheren WordPress-Update-Prozess.
WooCommerce und Premium-Lizenzen im Netzwerk
WooCommerce in einer Multisite ist möglich und für manche Unternehmen sehr sinnvoll, etwa für Länder-Shops oder getrennte Marken unter einem Dach. Gerade hier lohnt sich aber besondere Sorgfalt, denn ein Shop bringt viele Erweiterungen mit: Zahlungsanbieter, Versand, Rechnungen, Rechtstexte, Steuern.
Achte bei WooCommerce im Netzwerk auf diese Punkte:
- Pro Site aktivieren, wo nur ein Shop gebraucht wird. Nicht jede Subsite braucht WooCommerce. Aktivierst du es gezielt nur auf den Shop-Sites, bleiben die übrigen Sites schlank.
- Kontoverbindung pro Shop klären. Laut der WooCommerce-Marketplace-Dokumentation ermöglicht die Verbindung des Shops mit dem WooCommerce.com-Konto automatische Installationen, Produktupdates und Support. Kläre vorab, wie das bei mehreren Shops im Netzwerk gehandhabt wird.
- Lizenzanzahl prüfen. Viele Premium-Erweiterungen werden pro Site lizenziert. Zehn Shop-Sites können also zehn Lizenzen bedeuten. Lies die Lizenzbedingungen jedes Anbieters, bevor du planst.
- Steuern und Rechtliches je Shop. Jeder Shop braucht eine korrekte Steuerkonfiguration. Für den deutschen Markt haben wir das im Leitfaden zu Steuern in WooCommerce zusammengefasst. Bei grenzüberschreitendem Verkauf stimmst du die Einstellungen mit deiner Steuerberatung ab.
- Performance testen. Mehrere aktive Shops mit vielen Erweiterungen fordern Server und Datenbank. Lasttests auf Staging zeigen dir früh, wo es eng wird.
Wann sich Multisite trotz Plugin-Fragen lohnt
Plugin-Kompatibilität ist kein Argument gegen Multisite, sondern eine Frage der Planung. Ein Netzwerk spielt seine Stärken aus, wenn mehrere Websites derselben Organisation gemeinsame Themes und Plugins nutzen und zentral aktualisiert werden sollen. Typische Beispiele:
- Unternehmensgruppen mit einheitlichem Design für Tochterfirmen oder Marken.
- Filialnetze und Standorte, die gleiche Funktionen mit lokalen Inhalten brauchen.
- Länder- und Sprachversionen mit zentraler Steuerung.
- Agenturen, die viele ähnlich aufgebaute Projekte einheitlich pflegen.
Entscheidend ist, dass du den Plugin-Bestand bewusst kuratierst: eine geprüfte Liste erlaubter Plugins, klare Regeln für die Aktivierungsart und ein fester Testprozess für Updates. Benötigen einzelne Sites dagegen völlig andere Plugins, eigene Sicherheitsanforderungen oder eine strikte Trennung, planen wir gemeinsam mit dir die passende Architektur. Mehr dazu liest du in unserem Beitrag WordPress Multisite für Unternehmen.
Fehlt für eine wichtige Funktion ein Plugin, das im Netzwerk zuverlässig läuft, ist ein eigenes Plugin oft der sauberste Weg. Es wird von Anfang an für deine Netzwerkstruktur gebaut, trennt Daten korrekt und enthält nur das, was du brauchst. Mit welchem Aufwand du rechnen kannst, erklären wir im Beitrag zu den Kosten eines eigenen WordPress-Plugins.
Dein Multisite-Netzwerk in erfahrenen Händen
Seit über 14 Jahren entwickeln und betreuen wir WordPress- und WooCommerce-Projekte. Wir prüfen deinen Plugin-Bestand, testen neue Erweiterungen auf Staging, lösen bestehende Konflikte und entwickeln bei Bedarf eigene Plugins, die sauber im Netzwerk laufen. Du bekommst transparente Kommunikation und eine Betreuung, die auch nach dem Projekt weitergeht.
Hast du schon ein konkretes Problem im Netzwerk? Dann ist unsere WordPress Problemlösung der schnellste Weg. Für ein Plugin, das genau zu deiner Multisite passt, sprich uns zur individuellen Pluginentwicklung an. Und wenn Updates und Kompatibilitätstests künftig regelmäßig und zuverlässig laufen sollen, übernimmt das unsere WordPress Wartung.
Häufige Fragen
Woran erkenne ich, ob ein Plugin multisite-kompatibel ist?
Den ersten Hinweis gibt die Plugin-Beschreibung, gefolgt von Changelog und Support-Forum. Sicherheit bekommst du durch eine Rückfrage beim Entwickler und einen Test auf einem Staging-Klon deines Netzwerks. Prüfe dabei auch eine neu angelegte Subsite, denn dort zeigen sich viele Fehler zuerst.
Soll ich Plugins netzwerkweit oder pro Website aktivieren?
Netzwerkweit aktivierst du Plugins, die jede Site braucht, etwa für Sicherheit, Caching oder Backups. Pro Website aktivierst du Plugins, die nur bestimmte Sites betreffen, zum Beispiel WooCommerce auf der Shop-Site. Manche Plugins funktionieren nur netzwerkweit, andere besser pro Site, deshalb lohnt der Blick in die Dokumentation des Plugins.
Können Site-Administratoren in einer Multisite selbst Plugins installieren?
Standardmäßig nicht. Die Plugin-Verwaltung für das Netzwerk liegt beim Super Admin, Site-Administratoren haben dieses Recht nicht automatisch. So bleibt die Kontrolle über alles, was das ganze Netzwerk betrifft, an einer Stelle, und Kompatibilitätsprüfungen laufen zentral.
Was mache ich, wenn ein Plugin nach einem Update das Netzwerk stört?
Deaktiviere das betroffene Plugin, prüfe das Fehlerprotokoll und stelle bei Bedarf den letzten funktionierenden Stand aus dem Backup wieder her. Grenze die Ursache auf Staging ein und melde den Fehler dem Entwickler. Wenn du dabei Unterstützung brauchst, helfen wir dir mit unserer WordPress Problemlösung.
Quellen
- Multisite Network Administration – WordPress.org
- activate_plugin() – WordPress Developer Resources
- Roles and Capabilities – WordPress.org Documentation
- Tools Network Screen – WordPress.org Documentation
- validate_active_plugins() – WordPress Developer Resources
- Must-Use Plugins – WordPress Developer Resources
- wp plugin verify-checksums – WP-CLI Commands
- Woo Marketplace Documentation – WooCommerce
