Ein WordPress Multisite Netzwerk hat viele Vorteile. Gerade beim Einsatz in einer mehrsprachigen WordPress-Umgebung oder bei einer umfangreichen Website-Struktur mit Webshop und Co. kann die Multisite-Strategie ein lohnendes Investment sein. Zumindest dann, wenn sie einwandfrei funktioniert. Aufgrund der steigenden Komplexität ist die Multisite Installation nämlich durchaus etwas fehleranfälliger. Aber kein Grund zur Sorge. Jeder Fehler hat auch seine Lösung.
Multisite Vorbereitung als Problemfaktor
Im alltäglichen Alltag als WordPress-Agentur muss man einige Dinge möglichst effizient gestalten, damit der Workflow bei der Entwicklung von Websites möglichst reibungslose Ergebnisse erzielt. Ein wichtiger Aspekt sind wiederkehrende Arbeitsschritte wie die gängigen Sicherheitsanpassungen für WordPress-Webseiten, mit denen unsere Websites zuverlässig gegen die gängigsten Hacker-Angriffe abgesichert werden.
Zu den Standard-Maßnahmen gehören beispielsweise:
- Das Ändern des Tabellen-Präfix
- Umbenennung des Verzeichnis wp-content
- Verschieben der WordPress-Installation in ein weiteres Unterverzeichnis, damit die wp-config.php im übergeordneten Verzeichnis platziert werden kann
- Einschränkung der Dateirechte
Ziel dieser allgemeinen Maßnahmen ist es, den unbefugten Zugriff auf Dateien oder Skript-basierte Angriffe wirkungsvoll zu unterbinden. Jedoch bringen diese Maßnahmen einige Schwierigkeiten mit sich, wenn sie schon im Vorwege einer sauberen WordPress-Installation umgesetzt werden und nicht erst nachträglich über die Anpassung der laufenden WordPress-Datenbank.
„Fehler beim Aufbau einer Datenbankverbindung“
Diese Fehlermeldung ist wohl eine der häufigsten Fehlermeldungen, die uns bei der täglichen Arbeit mit WordPress um die Ohren fliegt. Doch glücklicherweise hat der Datenbankfehler in den meisten Fällen einfache Ursachen.
Wir setzen an dieser Stelle einmal eine korrekte WordPress Installation voraus, bei der die Einstellungen der wp-config.php fehlerfrei vorgenommen wurden. Der Datenbank-Fehler tritt also erst auf, nachdem eine WordPress-Website bereits erfolgreich installiert ist und lediglich nachträglich die folgenden Einträge in der wp-config vorgenommen wurden, um die Multisite Installation einzuleiten:
define( 'WP_ALLOW_MULTISITE', true );
define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', false);
define('DOMAIN_CURRENT_SITE', 'domain.com');
define('PATH_CURRENT_SITE', '/SUBVERZEICHNIS');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);
Nachdem wir die Netzwerk-Einrichtung unter „Werkzeuge“ im WordPress Backend gestartet haben, müssen wir die automatisch generierten Änderungen für die wp-config.php und die .htaccess übernehmen. Haben wir das naiv nach der vorgegebenen Anleitung getan, kann ein Fehler beim Aufbau einer Datenbankverbindung auftreten.
Sobald wir die folgende Ziele auf „false“ setzen, läuft die Datenbankverbindung wieder problemlos:
define('MULTISITE', true);
Das löst aber nich das Problem, sondern umgeht nur die Konsequenz. Zumindest ist so klar, dass es an der Multisite-Konfiguration liegen muss. Also ein paar Zeilen zurück.
Wenn wir die automatisch generierten Konfigurationseinstellungen anschauen, fällt uns im Falle eines selbst angelegten Subverzeichnisses auf, dass WordPress hier automatisch das Subverzeichnis mit in den Pfad der aktuellen Domain setzt:
define('PATH_CURRENT_SITE', '/SUBVERZEICHNIS');
Das ist verursacht jedoch einen Fehler, weil dieser Pfad bei den automatisch während der Installation angelegten Multisite-Datenbanktabellen nicht berücksichtigt werden kann. Das lösen wir, indem wir unsere MySQL Datenbank via phpMyAdmin aufrufen und die Tabelle wp_blogs auswählen.
In der Spalte „path“ ist hier fälschlicherweise das Subverzeichnis hinterlegt. Wir gleichen den Pfad – abhängig von unserer tatsächlichen Verzeichnistiefe – korrekt an (in diesem Fall auf das Hauptverzeichnis „/“) und aktualisieren die Tabelle.
Datenbanktabelle „wp_blogs“ einer Multisite-Installation
Nun aktualisieren wir noch den Eintrag in der wp-config.php auf das Hauptverzeichnis und die Datenbankverbindung funktioniert wieder einwandfrei:
define('PATH_CURRENT_SITE', '/');
