Willi Heidelbach Aus Herne, Deutschland

WordPress Multisite mit Redirect Loop und Charset-Fehler

von

Im Auftrag eines Kunden sollte ich neulich eine zweite WordPress-Seite für ein separates Projekt von ihm aufsetzen. Mit der Multisite-Fähigkeit von WordPress sollte dies gehen, dachte ich so bei mir. Ausprobiert hatte ich das nie, nur davon gehört. Ich fand schnell eine gute Anleitung und testete die Einrichtung einer Multisite auf einer meiner privaten WordPress-Seiten. Das ging fix und ohne Probleme. Frischen Mutes mit dem Rückenwind einer genialen Lösung machte ich mich ans Werk mit der Kundenseite. Es sollte ein langer, nervtötender Abend werden.

Die Einrichtung einer Multisite auf einem bestehenden WordPress-Blog ist eigentlich ganz einfach. Um nicht noch mal die unzähligen Anleitungen im Netz zu wiederholen, sei hier eine kurze Liste mit Anweisungen ausreichend:

  1. Alle Plugins deaktivieren
  2. In der Datei wp-config.php die folgende Zeile einfügen: define( ‚WP_ALLOW_MULTISITE‘, true );
  3. Ins Blog einloggen und unter „Werkzeuge“ den Punkt „Netzwerk Einrichtung“ aufrufen.
  4. Die erste Seite bestätigen (nach Prüfung) und den Code der zweiten Seite in die wp-config.php und .htaccess einfügen.
  5. Neu ins Blog einloggen.

Das sollte es sein. Das war’s auch auf meiner Testinstallation. Alles weitere erklärt sich fast von selbst bzw. lässt sich herausfinden. Den Rest findest du im Netz (u.a. bei der Anleitung weiter oben).

Charset-Fehler nach Multisite-Aktivierung

Ich richtete das Netzwerk ein und loggte mich neu in WordPress ein.

Ein Blick auf die Homepage ließ mir die Kinnlade herunterfallen: alle deutschen Umlaute und Sonderzeichen waren kaputt. Sie wurden beim Aufruf der Seite schlicht und ergreifend durch Zeichensalat ersetzt. Das passierte sowohl im Front- als auch im Backend. Also experimentierte ich mit den Codeschnipseln aus der Einrichtung etwas herum und fand heraus, dass der Zeichenschlamassel genau dann herauskam, wenn ich define(‚MULTISITE‘, true);  aktivierte. Das konnte aber definitiv nicht die wirkliche Ursache sein, oder?

Ich prüfte die ausgelieferte Seite im Rohzustand und im Multisite-Modus, ohne Unterschiede ausmachen zu können. Es wurde jeweils der Charset „utf-8“ ausgeliefert. Der Debugmodus von WordPress sorgte auch nicht für die Offenbarung.

An Plugins konnte es nicht liegen – die waren ja alle deaktiviert.

Ich verglich die Einrichtung der Kundenseite mit der meiner privaten Testseite und fand in der wp-config.php auch einen Unterschied. In der Testinstallation switche ich das Charset für die MySQL-Datenbank um: define(‚DB_CHARSET‘, ‚ISO-8859-1‘); 

Ich baute die Zeile auf der Kundenseite ein … und: BINGO! Nun war auch im Multisite-Betrieb das Schriftbild frei von Salat.

WordPress Multisite Redirect Loop bei neuer Seite

Ich wollte nun die neue Seite im Multisite-Netzwerk einrichten und tat dies auch. Subdomain-Namen eintragen, Adminemail hinterlegen, Seite aufrufen. So der Plan. Ich aktivierte die notwendigen Änderungen in der .htaccess-Datei, welche für das Routing der Anfragen auf das jeweilige Netzwerkblog zuständig sind. Und jetzt ging es los: ein Aufruf der Seite endet stets in einer Browserwarnung, dass die Seite so umleitet, dass dies nie endet. Ich konnte weder die Hauptseite, noch die Unterseite, geschweige denn den Adminbereich aufrufen. Meine Kundenseite war gerade mausetot.

Ich kopierte mir den Code einer normalen WordPress-Installation in die .htaccess-Datei und kommentierte den Multisite-Bereich aus. Also quasi umgekehrt wie es im folgenden Codefenster dargestellt wird.

# BEGIN WordPress - STANDARD
#<IfModule mod_rewrite.c>
#RewriteEngine On
#RewriteBase /
#RewriteRule ^index\.php$ - [L]
#RewriteCond %{REQUEST_FILENAME} !-f
#RewriteCond %{REQUEST_FILENAME} !-d
#RewriteRule . /index.php [L]
#</IfModule>

# BEGIN WordPress - MULTISITE
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]

# add a trailing slash to /wp-admin
RewriteRule ^wp-admin$ wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^(wp-(content|admin|includes).*) $1 [L]
RewriteRule ^(.*\.php)$ $1 [L]
RewriteRule . index.php [L]
# END WordPress

Das brachte aber überhaupt nichts! Ich kam immer noch nicht in den Adminbereich. Erst als ich den Multisite-Code in der wp-config.php auskommentierte, konnte ich wieder mit der Seite arbeiten. (Auskommentieren kann man die folgenden Zeilen indem man der Zeile eine Raute „#“ davor setzt.)

/* Multisite aktivieren */
define( 'WP_ALLOW_MULTISITE', true );
define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', true);
define('DOMAIN_CURRENT_SITE', 'deinemdomain.de');
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);
define( 'NOBLOGREDIRECT', 'https://deinedomain.de' );

Auch hier das Phänomen, dass mit Aktivierung der ersten auskommentierten Zeile – der Multisite-Modus-Aktivierung – sofort der Redirect-Loop zündete. Mittels Deaktivierung des einen oder anderen Bereiches konnte ich immer wieder mal ins Backend der Seite und dort schauen.

Ich probierte allerlei unsinnige Zeug aus dem Netz aus, aber nichts fruchtete. Gar nichts. Ich entschied mich dafür, das Drama zu beenden und die Multisite zurückzusetzen. Frank Bültge hat ne super Anleitung dafür ins Netz gestellt. Aber das Scheitern nervte.

Neustart!
Ich begann von vorn und konnte nicht mal mehr die Multisite-Einrichtung abschließen, weil ich beim abschließenden ReLogin immer im ReDirect-Loop landete. Jetzt konnte ich das Netzwerk nicht mal mehr einrichten! WordPress schaffte es nicht mehr, die notwendigen Tabellen in der MySQL-Datenbank anzulegen!

Ich probierte noch die Cookie-Prävention, die ich irgendwo im Netz aufgelesen hatte:

define('ADMIN_COOKIE_PATH', '/');
define('COOKIE_DOMAIN', '');
define('COOKIEPATH', '');
define('SITECOOKIEPATH', '');

Ich löschte im Browser die Cookies, leerte x-Mal den Cache, probierte andere Browser … nichts. Ich bekam langsam im Hirn einen Loop.

Kurz vor dem ultimativen KnockOut spät nachts – die Erleuchtung!

Womit hat das Drama um die Installation begonnen?
Mit dem falschen Charset!

Ich deaktivierte die Charset-Definition in der wp-config.php (siehe oben). Und ZACK – ich konnte die Multisite wieder einrichten! Natürlich hatte ich jetzt wieder den Zeichensalat. (siehe oben). Aber daran störte ich mich jetzt nicht und richtete flink die neue Site im WordPress-Netzwerk ein. Alles lief bis auf die kaputten Sonderzeichen reibungslos. Ich konnte die Hauptseite sowie die „Unterseite“ jeweils direkt aufrufen. Das WordPress-Multisite-Netzwerk funktionierte!

Und jetzt – nach Abschluss aller administrativen Tätigkeiten aktivierte ich den Charset-Switch in der wp-config.php wieder.

…

Und es war gut. Die WordPress-Multisite funktionierte auch weiterhin. Beide Seiten konnten getrennt angesprochen werden: sowohl im Frontend als auch im Backend. Und alle Umlaute besannen sich ihrer deutschen Herkunft und verrichteten zuverlässig ihren Dienst.

Alles war gut.

Fazit

Wenn es mit der Multisite-Einrichtung in WordPress mal nicht so klappen sollte, kann es auch am Charset der Datenbank liegen. Kannste dir nicht ausdenken ….

Nachtrag: Ich erinnerte mich daran, dass mein Kunde mal komische Änderungen an seiner Datenbank erwähnt hatte. Ich habe das gerade mal geprüft: dort herrscht leichtes Chaos. Während einige Tabellen in der normalen latin1_swedish_ci-Kollation vorliegen, kommen andere in utf8_general_ci daher. Bisher hatte das keine gravierenden Auswirkungen. Bisher. Mit der Multisite-Einrichtung wurde das Chaos aktiv.
Wenn jemand eine Idee hat, wie ich die Datenbank wieder sauber bekomme, wäre ich sehr dankbar!

(Foto: Willi Heidelbach Aus Herne, Deutschland)

Schreibe einen Kommentar