Troubleshooting Multisite: Wenn Benutzer keine Benutzerrolle haben

In deiner WordPress Multisite haben Benutzerinnen plötzlich ihre Benutzerrolle verloren. Was ist passiert und wie repariert man das?

Manchmal kommt es in einer WordPress Multisite-Installation vor, dass auf einer der Sites die Benutzer:innen nicht mehr auf das Dashboard dieser Site zugreifen können. Dies betrifft dann alle Benutzer:innen mit Ausnahme der SuperAdmins der Multisite. Das ist insofern tückisch, als man als SuperAdmin diesen Fehler leicht übersieht.

Alle anderen sehen das hier:

Screenshot Fehlermeldung: "Du bist leider nicht berechtigt, auf diese Seite zuzugreifen."

Wenn man sich die Profile der Benutzer:innen anschaut, fällt auf, dass man ihnen keine Benutzerrolle zuweisen kann:

Screenshot Benutzerprofil: Es kann keine Benutzerrolle zugewiesen werden.

Wie können Benutzerrollen plötzlich weg sein?

Mir ist das bisher dann passiert, wenn ich eine komplette Multisite umgezogen habe. Also ein Transfer von einem Serverspace in einen anderen, mit neuer Datenbank und neuem Datenbank-Präfix. Es kann auch passieren, wenn man eine einzelne Site neu in die Multisite einfügt. Dieses Szenario ist bei mir noch nicht vorgekommen.

Der Fehler liegt in der Datenbank

Die Benutzerrollen (user_roles) werden in der Datenbank, konkret in der Tabelle wp_options festgelegt.

Kleiner Exkurs Datenbank und Multisite

Die gesamte Multisite nutzt dieselbe Datenbank. Wenn man sich die Datenbank-Tabellen anschaut, gibt es einige, die für die gesamte Installation gelten, z.B. wp_site. Die jeweiligen Sites haben aber auch eigene Tabellen. Die Hauptsite, aus der heraus die Multisite-Installation erzeugt wurde, hat einfach die ganz normalen Tabellenbezeichnungen: wp_options, wp_posts, wp_comments usw.
Für die zusätzlichen Sites werden die Tabellen dann durchnummeriert: also wp_2_options, wp_2_posts, wp_2_comments, usw. oder wp_3_options, wp_3_posts, wp_3_comments,…

Bitte beachten:
Als Datenbank-Präfix habe ich hier aus Gründen der Übersichtlichkeit wp_ benutzt. Im echten Leben würde ich hier etwas benutzen, das nicht so offensichtlich ist: Eine zufällige Folge von Buchstaben, z.B. khwr_

Welche Datenbank-Tabellen sind die richtigen?

Aber zurück zu unserem Fehler. Ich muss herausfinden, welche Nummer die Site hat, in der der Fehler vorkommt. In meiner Beispiel-Multisite war’s einfach, da es hier nur zwei Sites gibt. Falls die Multisite aber aus mehreren Sites besteht und möglicherweise auch schon mal Sites gelöscht wurden, ist das nicht mehr so einfach nachzuvollziehen.
Die ID der Site findet man genauso heraus, wie man in WordPress eigentlich immer die ID findet, egal ob Kategorie, Beitrag, Seite oder eben eine Site in der Multisite:

In der Übersicht „Alle Websites“ in der Netzwerkverwaltung sind alle Websites aufgelistet. Wenn man mit der Maus über den Namen der entsprechenden Site fährt, wird unten links im Browserfenster ein Link angezeigt. Der sieht etwa so aus: https://deine-domain.com/wp-admin/network/site-info.php?id=2

Uns geht es um das „id=2“. Du musst also in den Datenbanktabellen mit der „2“ suchen, konkret für unseren Fall in der wp_2_options.

Den Fehler reparieren

Auf die Datenbank zugreifen

In deinem Hosting-Paket hast du normalerweise eine Möglichkeit, die Datenbank anzuschauen und die Tabellen zu bearbeiten. Meistens hat man PHPMyAdmin zur Verfügung.
An dieser Stelle die Warnung: Bitte erstelle ein Backup der Datenbank, ehe du anfängst, Tabellen zu bearbeiten. Es gibt innerhalb von PHPMyAdmin die Möglichkeit, die komplette Datenbank oder auch einzelne Tabellen zu exportieren. Das genügt für den Notfall.

Die Datenbank durchsuchen

In PHPMyAdmin kannst du nun deine Datenbank durchsuchen. Da wir bereits wissen, dass wir in die Tabelle wp_2_options schauen müssen, können wir uns auf diese Tabelle beschränken. Wir suchen also nach dem Begriff „user_roles“:

Screenshot Suchmaske PHPMyAdmin: Ich kann einen Begriff eingeben, eine Regel auswählen, nach der gesucht werden soll, und bestimmen, in welcher Tabelle gesucht werden soll.

In meinem Fall gab es nur einen Treffer. PHPMyAdmin listet genau auf, welche Befehle ausgeführt wurden.

Die fehlerhafte user_roles Zeile reparieren

Weiter unten wird die Zeile, die „user_roles“ enthält, angezeigt. Wenn man genau hinschaut, erkennt man sofort, was schiefgelaufen ist in meiner Datenbank:

Screenshot des Suchergebnisses für den Begriff user_roles in der Tabelle wp_options.

Die Zeile wp_2_user_roles heißt hier nn_2_user_roles. So wird auf die Informationen aus der Zeile user_roles einfach gar nicht zugegriffen. Die Folge davon ist, dass es für diese Site mit der ID 2 tatsächlich keine Benutzerrollen gibt.

Aber ich habe die Möglichkeit, die Zeile zu editieren. Ich muss nur das Datenbank-Präfix ändern in das, was ich für meine Multisite benutzt habe, nämlich „wp_“.

Screenshot PHPMyAdmin: Editieren der Zeile für die Benutzerrollen: Falsches Datenbank-Präfix ist zu sehen.

Sobald ich nun das „nn_“ durch „wp_“ ersetzt habe, sind alle Benutzerrollen in der Site 2 wieder verfügbar:

Screenshot Benutzerkonto: Man kann wieder Benutzerrollen zuweisen.

Fazit

Wenn es in der Multisite-Installation Probleme mit den Benutzerrollen gibt, kann es sinnvoll sein, einen Blick in die „wp_options“ bzw. in die Zeile „user_roles“ zu schauen. Du solltest vorher aber kurz prüfen, ob Plugins am Werk sind, die die Benutzerrollen bearbeiten.

Kommentare, die nichts mit dem jeweiligen Artikel zu tun haben, oder die weitgehend inhaltslos sind und keinen Mehrwert für andere Leserinnen und Leser bieten, veröffentlichen wir nicht.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Hinweise zum Datenschutz
Wenn du einen Kommentar schreibst, wird dieser inklusive Metadaten zeitlich unbegrenzt gespeichert. Auf diese Art können wir Folgekommentare automatisch erkennen und freigeben, anstelle sie in einer Moderations-Warteschlange festzuhalten.
Wenn Besucher Kommentare auf der Website schreiben, sammeln wir die Daten, die im Kommentar-Formular angezeigt werden, außerdem die IP-Adresse des Besuchers und den User-Agent-String (damit wird der Browser identifiziert), um die Erkennung von Spam zu unterstützen. Aus deiner E-Mail-Adresse kann eine anonymisierte Zeichenfolge erstellt (auch Hash genannt) und dem Gravatar-Dienst übergeben werden, um zu prüfen, ob du diesen benutzt.
Die Datenschutzerklärung des Gravatar-Dienstes findest du hier.
Nachdem dein Kommentar freigegeben wurde, ist dein Profilbild öffentlich im Kontext deines Kommentars sichtbar.