Mehrere WordPress-Installationen in einer Datenbank: geht das?

Veröffentlicht am

· von Norbert Hofmann

Kurz gesagt: Ja. Jede Installation braucht dazu ein eigenes Tabellen-Präfix, das du bei der Installation oder in der wp-config.php in der Zeile $table_prefix festlegst, zum Beispiel blog_ und shop_. Empfehlenswert ist das aber nur, wenn es nicht anders geht: Ein kompromittiertes Datenbank-Konto betrifft dann alle Websites. Wenn dein Hoster mehrere Datenbanken erlaubt, nutze für jede Website eine eigene mit eigenem Benutzer.

So funktioniert es

WordPress legt seine Tabellen mit einem Präfix an, standardmäßig wp_, also wp_posts, wp_options und so weiter. Hat eine zweite Installation ein anderes Präfix, etwa shop_, entstehen daneben die Tabellen shop_posts, shop_options. Beide Websites teilen sich die Datenbank, kommen sich aber nicht in die Quere.

Anleitung: Zweite Installation in derselben Datenbank

  1. Lade WordPress in ein eigenes Verzeichnis für die zweite Website hoch, siehe WordPress installieren.
  2. Gib bei der Installation dieselben Datenbankdaten ein wie bei der ersten Website.
  3. Trag im Feld „Tabellen-Präfix“ ein anderes Präfix ein, zum Beispiel shop_. Nur Buchstaben, Zahlen und Unterstriche verwenden.
  4. Schließe die Installation ab.

In der wp-config.php der zweiten Installation steht danach:

$table_prefix = 'shop_';

Vor- und Nachteile

VorteilNachteil
funktioniert mit Tarifen, die nur eine Datenbank bietenein gehackter Datenbank-Zugang gefährdet alle Websites
eine Datenbank weniger zu verwaltenBackups und Wiederherstellungen sind aufwendiger, weil du Tabellen einzeln auswählen musst
Umzug einer einzelnen Website ist fehleranfälliger
eine große Website kann die Datenbank für alle ausbremsen

Sollen die Websites eng zusammenarbeiten, etwa mit gemeinsamen Benutzerkonten, ist ein Netzwerk die bessere Wahl, siehe WordPress Multisite aktivieren.

Für Fortgeschrittene: Tabellen-Präfix nachträglich ändern

Willst du eine Website aus der gemeinsamen Datenbank herauslösen oder das Präfix ändern, reicht es nicht, die Tabellen umzubenennen. WordPress speichert das Präfix auch in Optionen und Benutzerdaten. Nach einem Backup gehst du so vor:

  1. Tabellen umbenennen, etwa wp_posts in blog_posts.
  2. In der Tabelle blog_options den Eintrag wp_user_roles in blog_user_roles umbenennen.
  3. In blog_usermeta alle Schlüssel, die mit wp_ beginnen (etwa wp_capabilities, wp_user_level), auf das neue Präfix umstellen.
  4. $table_prefix in der wp-config.php anpassen.

Vergisst du Schritt 2 oder 3, meldet WordPress nach der Anmeldung „Du hast keine Berechtigung, auf diese Seite zuzugreifen“. Einfacher ist der Weg über einen Export: Die Website mit einem Migrations-Plugin exportieren und in eine neue Datenbank mit neuem Präfix importieren. Per WP-CLI siehst du das aktuelle Präfix und die Tabellen:

# Präfix der aktuellen Installation
wp db prefix

# Alle Tabellen dieser Installation, inklusive Plugin-Tabellen
# (ohne --all-tables-with-prefix zeigt WP-CLI nur die Kern-Tabellen)
wp db tables --all-tables-with-prefix

# Nur die Tabellen dieser Installation exportieren
wp db export blog-backup.sql --tables=$(wp db tables --all-tables-with-prefix --format=csv)

Ein geändertes Präfix ist übrigens kaum ein Sicherheitsgewinn. Automatisierte Angriffe über SQL-Injection lesen das Präfix einfach aus. Wichtiger sind aktuelle Plugins, siehe WordPress sicherer machen.

Frage dazu? Frag im Forum „Installation & Setup“: Zum WPDE-Forum

Häufige Fragen

Wie viele Installationen passen in eine Datenbank?

Technisch viele, praktisch begrenzen Größe und Last der Datenbank. Die meisten Hoster legen ein Speicherlimit pro Datenbank fest.

Können sich die Websites Benutzer teilen?

Mit den Konstanten CUSTOM_USER_TABLE und CUSTOM_USER_META_TABLE ist das möglich, aber fehleranfällig. Für gemeinsame Benutzer ist Multisite der vorgesehene Weg.

Quellen

Über den Autor: Norbert Hofmann

Norbert betreibt das WPDE-Forum und hat jahrelang im technischen Support eines Webhosters täglich WordPress-Seiten betreut. Heute arbeitet er als Cyber Defense Analyst, hat Sicherheitslücken in WordPress-Plugins gefunden (veröffentlichte CVEs) und engagiert sich mit deepfake.de gegen Betrug mit Deepfakes. Mehr auf norberthofmann.com.

Weitere Antworten