WordPress Multisite Netzwerk administrieren

Viele (angehende) WordPress-Multisite Betreiber kommen mit dem Netzwerkprinzip und der Rolle des Netzwerk-Administrators und seinen weitreichenden Befugnissen sowie Aufgaben nicht zurecht. ich versuche deshalb hier aufzuzeigen, wie man ein paar Fallstricke umgeht und was es Grundlegendes zu beachten gilt.

Sobald ihr eine WordPress Multisite Installation und mehrere Sites darauf eingerichtet habt tauchen die ersten Fragen auf.

Wo finde ich das Netzwerk einer WordPress Multisite?

Egal wieviele Subblogs ihr später in der Multisite betreibt – die Domain, unter der ihr das WordPress zuerst aufgesetzt habt, ist eure Basis- oder Primärinstallation. In den englischsprachigen Foren findet ihr es unter der Phrase primary domain wordpress multisite.
Obwohl die Primäradresse in der MS eine besondere Rolle spielt, ist sie nicht mit dem Netzwerkbereich identisch!
Ihr könnt das Netzwerk-Dashboard entweder durch Eingabe eines URLs oder aus dem Backend heraus erreichen.

Netzwerk URL aufrufen

Nehmen wir an, ihr habt die WordPress Multisite unter installiert, dann erreicht ihr das Netzwerk über den Link: https://mein-neuer-garten.de/wp-admin/network/

https://lars-mielke.de/wp-admin/ würde euch nur zum Backend der Primarinstallation führen. Das ist noch eine Ebene zu hoch und was immer ihr dann dort administriert, hat keine Auswirkungen auf die gesamte Multisite.

Welche Menüpunkte befinden sich im Netzwerk-Dashboard?

Abgesehen von irgendwelchen nachträglich installierten Plugins, die sich hier reindrängen werden, findet ihr im Netzwerk-Backend die folgenden Menüpunkte:

• Seiten
  • Alle Seiten
  • Hinzufügen
• Benutzer
  • Alle Benutzer
  • Neu hinzufügen
• Themes
  • Installierte Themes
  • Neu hinzufügen
  • Editor
• Plugins
  • Installierte Plugins
  • Installieren
  • Editor
• Einstellungen
  • Netzwerkeinstellungen
  • Netzwerk-Einrichtung
  • (Domain Mapping)
  • (Domains)
• Updates
  • Verfügbare Updates
  • Netzwerk aktualisieren

Die in Klammern stehenden Punkte erscheinen nur, wenn ihr Domain Mapping auf der Multisite betreibt.

Was macht der Netzwerk Admin eigentlich?

Da der Netzwerk- oder Supderadministrator per se Herr über die gesamte Installation ist, „gehören“ ihm damit auch alle Subblogs in der Multisite. Blogartikel schreiben oder Bilder posten gehört dennoch nicht zu seinen Aufgaben.
Er ist eher für folgendes zuständig:

• Subblogs oder Sites einrichten/löschen
• Installation/Deinstallation von Plugins und Themes
• Globale oder Subblog-bezogene Einstellungen tätigen (z.B. Speicherplatz für den Blog-Content)
• WordPress Nutzer anlegen/löschen und den Subblogs zuweisen

Das alles können lokale Admins (die nur für einen jeweiligen Subblog zuständig sind) nicht. Wenn sie die Möglichkeit haben, auf ihrer Site Plugins zu aktivieren/deaktivieren – dann nur, weil es ihnen vom Netzwerkadmin gestattet wurde. Er kann Plugins (und auch Themes) entweder netzwerkweit aktivieren oder es den lokalen Admins überlassen, was sie an Plugins für ihren Blog einsetzen oder welches Theme sie aktivieren möchten.

Bei den Themes kann man als Netzwerkadmin sogar festlegen, dass bestimmte Themes nur für bestimmte Site zur Verfügung stehen. Andere Subblogs sehen diese Themes nicht und können sie somit auch nicht aktiv schalten.
Dafür lädt man das Theme in die Multisite hoch, schaltet es aber nicht netzwerkweit frei. Solche separaten Themes werden in der Theme-Auflistung von WordPress unsinnigerweise als deaktiviert gekennzeichnet. Dann wechselt man in die Bearbeitungsansicht einer Seite (ja, in der deutschen Übersetzung wird hier wieder ein völlig verwirrender Begriff verwendet. Gemeint sind nämlich Subblogs bzw. Sites.) und dort zum Karteireiter Themes. Dort werden alle Themes angezeigt, die nicht netzwerkweit aktiv sind. Wenn man jetzt hier ein Theme freischaltet, so steht es dem lokalen Admin in seinem Subblog (und auch nur dort) zur Verfügung.

Wie ihr seht, besitzt ein Netzwerkadmin oder Superadministrator eine unglaubliche Machtfülle im System. Beschränkt deshalb die Anzahl der Netzwerk-Administratoren auf das nötige Maß!

In einem WordPress Multisite Netzwerk sollte es nur ein oder zwei Netzwerk- oder Super-Admins geben.

Neue Subblogs anlegen

Der Sinn einer WordPress Multisite besteht darin, unter einer Installation mehrere voneinander unabhängige Blogs zu betreiben.
Gottseidank ist die Registrierung neuer Subblogs standardmäßig deaktiviert. Man stelle sich nur vor, jeder könnte Subblogs in eurer Multisite anlegen, wie er lustig wäre.
Also kann das hier nur wieder der Netzwerk-Admin machen. Dazu ruft er den URL https://mein-neuer-garten.de/wp-admin/network/site-new.php auf, wobei ihr beispielseite.de durch den URL eurer Primäradresse ersetzen müsst. Füllt die 3 Formularfelder aus und bestätigt dann durch Seite erstellen.
Meine neue Site zu Demo Zwecken habe ich Tutorial genannt und sie unter der Adresse https://beispielseite.de/test456/ verortet. Der URL kommt deshalb so zustande, weil ich die Multisite in der subdirectory Variante betreibe. Würde ich mit subdomains arbeiten, würde die Adresse https://test456.beispielseite.de/ lauten.

Einen Admin bestimmen

Wenn ihr bei der Email des Admins eine Email-Adresse eingebt, die zu einem im System bereits registrierten Benutzer gehört, wird dieser automatisch zum Admin des neuen Subblogs ernannt. Im anderen Fall legt WordPress von sich aus einen Nutzer mit dem von euch festlegten Kürzel der Seiten-Adresse (in meinem Fall also test456) als Nutzernamen an. Schon mal das ist großer Murks, weil man Nutzernamen nachträglich nicht ändern kann. Unglücklicherweise wird dem neuen Administrator dieser Seite auch noch eine unverschlüsselte Mail mit den Zugangsdaten (inklusive Passwort!) zugesandt. Es ist also weitaus sinnvoller, die benötigten Benutzer vorher anzulegen und dann einfach dem Subblog zuzuweisen.

Site Settings ändern

Ihr erhaltet dann auf derselben Seite eine Bestätigung über die erfolgte Anlage einer neuen Site und werdet vor die Wahl gestellt, entweder ins Dashboard dieser Seite oder in die Einstellungen (Seite bearbeiten) zu wechseln. Ich rate zu den Einstellungen, damit ihr auch mal diesen Bereich gesehen habt.

Diese Site Settings unterteilen sich in die Bereiche Info, Benutzer, Themes und Einstellungen. Hierbei sind gerade die Einstellungen der Bereich mit den größten Änderungs- und Anpassungsmöglichkeiten. Leider ist das auch der benutzerunfreundlichste und sträflichst vernachlässigste Bereich im ganzen WordPress System. Gerade für ein System wir WordPress, dass sich seiner einfachen und intuitiven Bedienung rühmt, ist das kein Ruhmesblatt. Es geht damit los, dass die Formularlabels auf englisch gehalten sind, größtenteils durch boolesche Werte (o und 1) gesteuert werden und nicht durch einen Mouse-Hover-Tip erklärt werden. Optionen, die ihre Daten in serialisierter Form abspeichern, können überhaupt nicht bearbeitet werden.

WordPress Multisite updaten

Zugegeben, so einfach und unkompliziert der Updatemechanismus in WordPress auch arbeitet – wenn es mit einem Plugin, einem Theme oder einem WordPress Update Ärger gibt, wirkt sich das gleich auf die geamte Multisite aus.

Aus diesem Grund rate ich immer wieder dazu, nur etablierten Plugins oder Themes zu vertrauen. Es macht aus Sicherheitsgründen überhaupt keinen Sinn, WordPress nicht zu aktualisieren, weil dann irgendein Plugin nicht mehr funktioniert. Dann muss es eben ersetzt werden.

Wer auf Nummer Sicher gehen will, macht vor dem Update ein Datenbank-Backup.

Updates kann nur ein Netzwerk-Admin oder Superadmin einspielen. Je nachdem, wofür Updates vorhanden sind, spielt man erst die neuen Plugins oder Themes ein, danach das WordPress Update. Bei Gino Cremer habe ich gelesen, dass jedes Update einzeln eingespielt und danach jeweils auf Unverträglichkeiten kontrolliert werden soll. Kann man so machen.

Nach einem Update der WordPress Kerndateien müssen die Neuerungen allen Subblogs mitgeteilt werden. Ruft den Punkt Netzwerk aktualisieren unter Updates auf. Hier geht WordPress dann durch die Datenbank und bringt alle Sites auf den neuesten Stand. Da diese Funktion nur 5 Subblogs auf einmal bearbeiten kann, wird dieser Prozess bei sehr vielen Subblogs etwas dauern.