Danke, Hannes für die Diskussion um das Thema.

In Multisiteumgebungen werden die User aller Sites die da sind oder noch kommen werden, in denselben Tabellen vorgehalten. Es hat also nicht jede neue Subsite eine eigene Usertabelle, sondern jeder neue User ist ein Netzwerkuser mit Mitgliedschaft in einer oder mehreren Sites des Netzwerks.

Beim Einrichten eines Netzwerks von WordPress Websites (Multisite) stehen mit Subdomains und Unterverzeichnisse zwei Varianten zur Verfügung.

Grundsätzlich ziehe ich die Subdoman-Variante vor, selbst wenn „Sie benötigen einen Wildcard DNS-Eintrag, wenn Sie die Funktionalität des Virtual Host (Subdomain) verwenden möchten.“ nicht zutrifft. Benötigt wird ein Wildcard-DNS-Eintrag nur für den Fall, dass dynamisch neue Sites angelegt werden, ohne dass die Subdomains dafür eigens festglegt wurden. Es empfiehlt sich dann natürlich auch Wildcard-TLS/SSL. Da das in vielen Fällen allerdings gar nicht zutrifft, spricht nichts gegen Multisite, um mehrere Webauftritte unter eine Installation zu bringen, und den Wartungsaufwand gering zu halten.

Es besteht dann lediglich das Erfordernis, zuerst eine Subdomain manuell anzulegen, und dann eine neue Site in der Umgebung mit der neuen Adresse. Abgesehen davon kann durch nachträgliches Überschreiben einer (nicht vorhandenen) Subdomain-Adresse in den Site-Einstellungen stattdessen auch einfach eine andere Domain angegeben werden (die natürlich auf dasselbe Verzeichnis zeigen muss in dem sich die WordPress-Installation befindet).

Zudem kann die Hauptsite einer Multisiteinstallation durchaus auch eine Subdomain sein – z.B. haupt.example.com. Die Folge davon ist lediglich, dass man später die URL neu angelegter Subsites (die nach diesem Muster angelegt würde: subsite.haupt.example.com) ändern muss, z.B. in subsite.example.com. Es ist im Grunde gleich, wie wenn innerhalb desselben Netzwerks verschiedene Domains verwendet werden sollen.

Ist bereits die Hauptsite eine Subdomain, oder haben die Sites innerhalb der Multisite-Umgebung verschiedene Domains, ist das Loginverhalten anders, als in Umgebungen mit der Domain als Haupsite und zugehörigen Subdomains als Subsites oder einer Umgebung, die auf Unterverzeichnissen basiert.

Bei Haupt- Subdomain Sites und Unterverzeichnissen werden beim Login Cookies unter der Domain der Hauptsite gespeichert. Diese gelten für die gesamte Umgebung. Einmal eingelogged bedeutet dann is_user_logged_in() is true;. Das trifft auch auf Subsites in denen der User gar kein Mitglied ist. Die Berechtigung zum Zugriff auf das Dashboard hat damit erstmal gar nichts zu tun. Die Adminbar ist global vorhanden, allerdings nur mit Links auf das Dashboard von Sites in denen ein User auch Mitglied ist.

Bei verschiedenen Domains oder wenn bereits die Mainsite eine Subdomain (gleicher Ebene wie die Subsites) ist, werden Login-Cookies für jede Instanz unter deren Adresse gespeichert, und gelten folglich nur dafür. Daher benötigt jede Instanz ein eigenes Login. is_user_logged_in() is true; beschränkt sich also nur auf die Instanzen, in denen sich der User jeweils anmeldete.

Möchte man innerhalb einer Umgebung, die nur ein Login erfordert herausfinden, ob ein User zu einer bestimmten Subsite gehört, muss man das anders ermitteln, als mit is_user_logged_in(), zum Beispiel mit is_user_member_of_blog(), oder man fragt nach einer Capability, wie zum Beispiel current_user_can( 'read' ), um die Zugehörigkeit zu einer bestimmen Subsite zu prüfen.