Das WordPress Multisite-Feature ist kacke!

Ich habe es wirklich versucht! Mehrfach sogar! Ich wollte mich wirklich mit dem Multisite-Feature von WordPress anfreunden, das seit der Version 3.0 durch die Integration der Multiuser-Edition verfügbar ist. Aber es klappt einfach nicht!

Ich habe ehrlich gesagt keine Ahnung, welcher Frickler da am Werk war, um dieses - eigentlich recht praktische - Feature dermaßen zu versauen! Dabei ist der Grundgedanke doch eigentlich recht praktisch: Mit einer WordPress-Installation will man mehrere Blogs - mit jeweils eigenem Inhalt - bereitstellen. Das ganze soll durch eine Userverwaltung untermauert werden, sodass jede User - potentiell - Zugriff auf mehrere Blogs der gleichen Installation hat.

MultiSite Superadmin

Aber wie sieht das Ergebnis aus? Das Einrichten ist noch ziemlich einfach: Eine Konfiguration, um das "Netzwerk" erzeugen zu können. Dann alles nochmal umkonfigurieren, um das Netzwerk nutzbar zu machen. Dann kann man neue Unterseiten anlegen und User berechtigen, auf Blog A, B und C zuzugreifen.
Doch zu welchem Preis? Das fängt schonmal damit an, dass man WordPress nicht mehr in einen Unterordner installieren darf - warum auch immer das nicht unterstützt wird. Dann verschwinden urplötzlich Einstellungsmöglichkeiten, die unter Garantie nichts, aber auch wirklich garnichts mit dem Multisite-Feature zu tun haben...

Leseeinstellungen vorher vs. nachher

...um die verschwundenen Einstellungen tätigen zu können, muss man die mehr als lächerliche Superadmin-Blog-Konfigurationsmöglichkeit benutzen, in der man die Werte händisch ändern darf...

Superadmin Blog-Optionen

...und zur Krönung des ganzen darf man dann auch noch irgendwelche Drittkomponenten einsetzen, um den Blogs auch jeweils eigene Domains zuweisen zu können (wobei das Plugin bei mir einfach nur zu einer Endlosschleife führt und den Login kaputt macht).

Ich für meinen Teil werde dieses völlig verbastelte Feature jedenfalls nicht nutzen. Wenn man nicht gerade Blogs für irgendwelche Fremden Leute bereitstellen muss, gibt es sicherlich bessere Wege, um eine akzeptable Alternative zu erreichen. Zwei Beispiele für solche Alternativen möchte ich euch zeigen. Die sind zwar weniger bequem (was die geteilte User-Verwaltung angeht), aber sie ermöglichen genau das, was ein normaler Bloguser wahrscheinlich will:

  • mehrere Blogs betreiben können
  • jedem Blog eine eigene Domain geben können
  • nur eine WordPress-Installation pflegen müssen

Die Lösungen selbst ähneln denen, die WordPress.org selber vorschlägt, nur, dass das ganze mit einer einzigen Codebasis funktioniert. Die erste Lösung ist für Leute geeignet, die nur eine Datenbank zur Verfügung haben, aber trotzdem mehrere WordPress-Blogs parallel nutzen wollen:
In der Datei wp-config.php gibt es die Variable $table_prefix. Durch Ändern dieser Variable kann man zwischen verschiedenen WordPress-Instanzen hin- und herschalten. Wenn man nun also für verschiedene Domains verschiedene WordPress-Instanzen (aber mit der gleichen Codebase) haben will, muss man diesen Prefix einfach nur vom Host abhängig machen:

1
$table_prefix  = 'wp_' + strtolower(ereg_replace("[^A-Za-z]", "", $_SERVER["HTTP_HOST"])) + "_";

Hier gibt es jedoch einen Schönheitsfehler: Sollte jemand mit einer bisher unbekannten Domain die Blog-Installation aufrufen können, hat dieser die Möglichkeit, einen eigenen Blog zu installieren! Um das zu verhindern, sollte man entweder eine Abfrage einbauen, ob der Host zu einer Liste von Hosts gehört, zu denen der Blog bereits existiert, oder man macht die Datei wp-admin/install.php unzugänglich.

Leute, die beliebig viele Datenbanken anlegen können, können auch einen anderen Weg gehen - diesen werde ich persönlich wahrscheinlich nutzen. Was man einfach macht: Man verwendet einen Datenbank-Namen und (optional) einen Nutzernamen und ein Passwort, die sich vom Host ableiten lassen. Der Vorteil ist, dass das Installationsproblem bei inkorrekten Hosts wegfällt.

1
2
3
4
5
6
7
8
9
10
$clearedHost  = strtolower(ereg_replace("[^A-Za-z]", "", $_SERVER["HTTP_HOST"]));
$generatedPwd = ereg_replace("[^A-Za-z0-9]", "", base64_encode(pack("H*" , sha1("SALT" . $clearedHost))));

// ** MySQL settings - You can get this info from your web host ** //
define('DB_NAME',     'DBNAME_' . $clearedHost);
define('DB_USER',     'USERNAME_' . $clearedHost);
define('DB_PASSWORD', $generatedPwd);
define('DB_HOST',     'DBSERVER');
define('DB_CHARSET',  'utf8');
define('DB_COLLATE',  '');

In diesem Beispiel sollte man die Platzhalter "SALT", "DBNAME", "USERNAME" und "DBSERVER" durch seine eigenen Daten ersetzen. "SALT" dient übrigens dazu, damit außenstehende nicht anhand der Domain auf das Datenbank-Passwort schließen können. 😉

Ich hoffe, ich konnte euch ein paar neue Einblicke verschaffen und wünsche euch viel Spaß mit eurer WordPress-Installation! 😀

Und nicht vergessen: Ich hafte nicht für Schäden an Software, Hardware oder für Vermögensschäden, die durch Anwendung dieser Änderungen entstanden sind oder entstehen könnten. 😉
Multiple Grüße, Kenny

21 Kommentare » Schreibe einen Kommentar

  1. Ich oder wir, wenn wir nicht ständig an mir hängen bleiben würde, haben eine solche Page am Laufen. Gewünscht hätte ich mir mehr Möglichkeiten dass die jeweiligen Blogs unter einer Hauptdomain miteinander kommunizieren könnten. Es hat auch eine ganze weile gedauert und dauert auch noch an die passenden Plugins zu finden und zu installieren. Ebenso machen etliche Themes richtig Probleme. Bei der Adminstration und Gruppenrechten darf man erst einmal die Suchmaschinen durchforsten um nicht jeden Benutzer gleich mit Admin Rechten auszustatten. Das ist schon ziemlich krass bis man alles wirklich zusammen hat.
    Es wäre ganz nett wenn du deinen Artikel hier einmal überholen könntest. Weil gerade für Einsteiger, zu denen ich mich nach einem kompletten Wechsel zu WP auch zähle, ist es nicht besonders hilfreich und zum Teil auch schon überholt. Oft liegt es aber auch an der Bereitschaft der User/Betreiber selbst, denn es ist nun einmal Anfangs mit ordentlich Arbeit verbunden. Viele unterschätzen dies gewaltig. ich werde sicherlich auch noch einmal irgendwann etwas darüber schreiben, wenn ich hier erst einmal durch bin und das jetzige Theme gegen ein eigenes getauscht habe.

  2. Hallo Kenny,
    genialer Beitrag auch wenn er etwas älter ist 🙂

    Hast du denn Aktuell noch eine WP-Multisite am laufen?

    Kann man denn wenn man mehrere Blogs hat, von Blog A die Beiträge(bestimmte Kategorie) auch auf Blog B abbilden/ anzeigen?

    Grüße,
    Mark

    • Ahoi. Nein, habe ich nicht mehr. Ich habe inzwischen wieder für jede Seite eine komplett eigenständige WordPress-Instanz laufen. Das hat den massiven Vorteil, dass ich jede Webseite prozessual und zugriffsrechtetechnisch vollständig trennen kann. Deshalb kann ich die zweite Frage auch nicht beantworten - ich habe das Multisite-Feature in den letzten 4,5 Jahren nicht wieder angesehen. 😉

    • Ich oder wir haben die Kategorie auf allgemein stehen gelassen.
      Andernfalls kannst du dir die Kommentar-Funktion damit versauen. Gerade wenn es sich um eine Community handelt kann dies schnell daneben gehen. Die User müssen sich dann auch noch da einarbeiten und das ist vielen schon zu viel oder mehr als sie erwartet haben oder an Zeit bringen oder bereit sind aufzubringen - eben Multi 😉 Da kannt man nicht von sich selbst ausgehen. Eine gute Lösung stellen dann statische Seiten da.

  3. Nochmal ein Kommentar und vergiss den von vorhin. Es hat sich herausgestellt, dass mein Problem ein Cookie Problem ist. Oh Mann. Aber die Idee hier finde ich trotzdem geil. Alles Gute

  4. Ich finde Deinen älteren Artikel aus aktuellen Anlass sehr interessant. Mein Anbieter 1und1 hat jedes Wochenende einen Serverausfall und danach funktioniert nichts aber auch gar nichts mehr. Ich musste mein Netzwerk schon dreimal neu installieren und das ganze ist ruinös. Kann man so nicht verkaufen. Obwohl ich nichts an der .htaccess oder wp-config.php geändert habe, kann ich mich nicht mehr einloggen. Irgendwie werden die mod rewrite Regeln geändert in der Tiefenstruktur von 1und1 und die gesamte Installation ist hin. Eine Jagd auf das Deaktivieren von einzelnen Plugins geht los und wenn ich Glück habe finde ich den Fehler. 1und1 hüllt sich in Schweigen.

    Wenn ich die Multisite Installation deaktiviere kann ich auf die Hauptseite zugreifen. Mehr aber auch nicht. Alle Unterseiten sind unerreichbar. Ein Blick in die Datenbankstruktur hat mir dann irgendwann verraten, dass WordPress für jeden Blog einen wp_id_ Präfix verwendet. Ist ja auch nicht viel anders als das, was du da vorschlägst.

    Das Problem der Multisite Installation ist der kollektive Ausfall aller Blogs, wenn etwas schiefläuft.

    Die Frage ist, ob das bei den obigen Vorschlag nicht genauso ist.

    • Mag vielleicht daran liegen, dass der Artikel nun auch schon über zwei Jahre alt und das Feature entsprechend weiterentwickelt worden ist. ^^

  5. Habe keine Probleme mit der Multisite beim Einsatz von Subdomains festgestellt. Ein Domain-Mapping sollte natürlich nativ von WordPress unterstützt werden.

    • Der Artikel ist ja dann doch auch schon etwas älter. Gut möglich, dass das Feature inzwischen besser geworden ist. 😉

  6. kann nur positives Berichten, nach ungefähr 5 Minuten Tipsel und Einstellungen wurde bei mir vor einer Woche aus Standard WordPress Installation eine Multisite WordPress (subdomain und Domainmapping incl)

    der Zweck den ich verfolge, ist das sich Freunde und zb meine Workshopteilnehmer, einfach mit WordPress beschäftigen können, ohne große Installation eines eigenen WordPress zu machen und ich kann trotzdem einfach Support oder Hilfe geben, bzw steuern.
    denn mit angabe eine gewünschte Portal(subdomain) namen und einer Email ist es für eine neugierigen Einsteiger schon erledigt, Portal ist fertig und braucht nur mit Content befüllt werden. Bei Bedarf kann ich dann solch erstelltes Portal auch (mit Domainmapping und Steuerung durch Netzwerkadmin) für Professionelle Nutzung erweitern.

    gruss Franz
    http://vorne.at - mein Multisite WordPress für die Homepage mit einem Click

  7. Komisch nur, dass das Feature bei mir super läuft. Wenn man es einmal raus hat, ist es sehr praktisch, vor allem deswegen, weil ich dadurch 3 Datenbanken gespart habe.

    • Nachdem ich drei mal vergeblich versucht, das ganze irgendwie halbwegs zum Laufen zu kriegen, habe ich es sein lassen. Im Zuge dessen hatte ich einmal meine komplette Dateiverwaltungsstruktur umgeworfen, um es nutzbar zu machen. Nun läuft alles, wie es geplant war, ohne irgendwelche Probleme oder GUI-Ungeklärtheiten.

      Wenn es für dich funktioniert, freut mich das natürlich sehr 🙂 . Bei mir hat dieser Multisite-Bug (sieht derzeit IMHO noch nicht nach einem Feature aus) lediglich einen haufen vergeudeter Stunden und Nerven verursacht.

  8. Das Multisite-Feature ist zwar nicht perfekt, aber man richtet sich eine ms-Instanz nur einmal ein und dann läuft das. Okay, ohne Domain-Mapping-Plugin macht es keinen Spaß, aber auch das ist ja schnell behoben.

    Die Loop-Problematik kenne ich; zeugt aber meist davon, zuviel rumgespielt zu haben, was man nicht sollte. WordPress nimmt einem vieles krumm, leider.

    Dein Vorschlag von oben hab ich übrigens vor ca. 3 Jahren in ähnlicher Weise selbst schon mal genutzt, weil wordpress mu damals noch viel größerer Müll war und sich fast gar nicht intuitiv installieren ließ.

    Dabei hab ich aber nicht nur DB-Umlenkungen eingesetzt, sondern auch noch Pfade und Dateien dynamisch angepasst (favicon.ico, sitemaps und uploads zB). Ich wollte da mal einen fetten, dokumentierenden Artikel schreiben, fand es aber mit der MultiSite-Lösung von WordPress dann doch etwas überflüssig.

    Immerhin hab ich meine Instanz ja auch so aufgesetzt bekommen und nicht mehr Zeit hineingesteckt als bei meiner damaligen Lösung. Natürlich sollte DomainMapping mE in den Core wandern, und diese fehlenden Optionen fand ich auch seltsam (leider auch nur mit Plugin wieder zurückzuholen).

    Und nicht immer auf Plugins schimpfen, durch die ist WordPress überhaupt erst ein beliebtes BlogCMS geworden (und wenn Matt/Automattic mal darauf achten, werden Plugin-Funktionen dann auch mal in den Kern implementiert, aber das dauert meistens ewig...).

    • Mein Problem mit dem Multisite-Feature ist, dass es halt "irgendwie" funktioniert. Ich möchte aber, dass es ordentlich und nachvollziehbar funktioniert - das ist bisher aber nicht gegeben. Und dabei ist es mir persönlich als Admin völlig Wurst, ob das daran liegt, dass der Merge erst erfolgt ist, oder daran, dass die Entwickler es halt nicht besser können.

      Es soll funktionieren und zwar auf verständliche, nachvollziehbare Weise. Bei meiner eigenen Lösung ist das gegeben, da der Multisite-Code (hoffentlich) niemals zum Einsatz kommt.

Schreibe einen Kommentar

Um Ihnen beim weiteren Kommentieren auf dieser Webseite die erneute Eingabe Ihrer Daten zu ersparen, wird beim Absenden Ihres Kommentars ein Cookie an Ihren Browser gesendet und von diesem gespeichert. Mit dem Absenden eines Kommentars auf dieser Webseite stimmen Sie der Speicherung und Übertragung dieses Cookies explizit zu.

Pflichtfelder sind mit * markiert.