Wer mehrere Websites betreibt, kennt die Rechnung: Jede Installation braucht Aktualisierungen, Sicherungen, Überwachung und irgendwann eine Migration. Bei drei Projekten ist das lästig, bei fünfzehn ist es ein Teilzeitjob.

Was Mandantenfähigkeit bedeutet

Ein Programmcode, ein Vorlagensatz, beliebig viele Websites. Jedes Projekt hat eine eigene Domain, eine eigene Datenbank, eigene Inhalte, eigene Einstellungen und ein eigenes Ausgabeverzeichnis. Was sie teilen, ist die Anwendung – und damit jede Verbesserung daran.

Praktisch: Wird die JSON-LD-Ausgabe um ein Feld ergänzt, haben es nach dem nächsten Build alle Projekte. Wird ein Fehler in der Sitemap behoben, ist er überall behoben.

Wie ein Mandant erkannt wird

Über den Hostnamen der Anfrage. Eine generische Weiche in der Serverkonfiguration löst jede Subdomain automatisch auf – für ein neues Projekt unter derselben Domain ist an der Konfiguration nichts zu ändern. Für eine zusätzliche eigene Domain kommt eine Zeile dazu.

Auf der Kommandozeile und im Backend läuft die Auflösung über einen Schlüssel, damit sich Projekte ohne Domainwechsel bauen und verwalten lassen.

Der Punkt, an dem es kippt

Der Vorteil ist zugleich das Risiko: Wer eine Vorlage ändert, ändert sie überall. Ein Fehler wirkt nicht auf einer Website, sondern auf allen gleichzeitig.

Die Antwort darauf ist eine Regel, die man von Anfang an durchhalten muss: Unterschiede zwischen Projekten gehören in Einstellungen, nicht in den Code. Sobald die erste Bedingung „wenn Mandant X, dann anders“ in einer Vorlage steht, beginnt die Zersplitterung – und in zwei Jahren gibt es fünf Sonderfälle, die niemand mehr überblickt.

Wie Unterschiede stattdessen abgebildet werden

  • Vokabular. Ein Begriffsfilter über der fertigen Ausgabe ersetzt „Agentur“ durch „Shop“, „Anbieter“ oder „Funktion“. Gleiches Design, gleicher Aufbau, eigene Sprache.
  • Adressstruktur. Ob das Verzeichnis unter /agenturen oder /funktionen liegt, ist eine Einstellung. Ein leerer Wert schaltet ein Modul ganz ab.
  • Farbe. Aus der Markenfarbe werden beim Bauen zwei kontrastsichere Varianten abgeleitet, sodass die Lesbarkeit nicht von der Farbwahl abhängt.
  • Texte. Überschriften, Stichpunkte, Hinweistexte und Rahmentexte liegen in der Datenbank, nicht in der Vorlage.

Datenbanken und Zugangsdaten

Getrennte Datenbanken je Projekt sind die richtige Wahl: Sicherung, Übergabe und Löschung eines Projekts bleiben damit einfache Vorgänge. Ab dem zweiten Mandanten lohnt eine zentrale Zugangsverwaltung – ein Benutzer, ein Präfix, der Name ergibt sich aus Präfix und Schlüssel.

Häufigster Stolperstein: Hoster legen Datenbankbenutzer oft je Datenbank an. Für die zentrale Verwaltung braucht es einen Benutzer mit Zugriff auf alle betroffenen Datenbanken – sonst funktioniert die Auflösung, aber die Verbindung nicht.

Wann es sich rechnet

Ab dem dritten Projekt fast immer. Darunter ist eine getrennte Installation einfacher zu überblicken und im Zweifel schneller ersetzt. Wer allerdings weiß, dass aus einem Projekt fünf werden, sollte gleich mandantenfähig anfangen – der nachträgliche Umbau kostet mehr als der Anfang.