TYPO3-Instanzen zusammenführen – eine gute Idee?

Oft finden wir bei Kunden mehrere TYPO3-Instanzen vor, die von den TYPO3-Versionsständen, den verwendeten Extensions, den Layouts, den Backend-Usern unterschiedlich sind. Spätestens, wenn es darum geht, diese Instanzen durch Upgrades aktuell zu halten, stellt sich die Frage, ob es nicht effizienter wäre, alle Webauftritte in eine einzige Instanz zu packen und diese zu aktualisieren. Um die Antwort vorwegzunehmen: meistens ist das ein sehr sinnvoller Ansatz. Da es aber auch Argumente dagegen gibt, wird im Folgenden der Sachverhalt genauer beleuchtet.

Wenn man sieht, wie aufwändig ein TYPO3-Upgrade z.B. von v11 nach v12 ist, liegt es auf der Hand, die Anzahl der Upgrades auf genau eines zu minimieren, indem man nur noch eine TYPO3-Instanz hat. Doch vor der Integration einer TYPO3-Instanz in eine andere, gibt es häufig Bedenken auf Kundenseite: Kann die Seite hinterher genauso aussehen wie vorher? Was ist mit Extensions, die im Zielsystem nicht vorhanden sind? Was ist mit meiner Rechteverwaltung? Welche Abhängigkeiten schaffe ich mir? Kann ich die Website später bei Bedarf wieder separieren (und was könnten Gründe dafür sein)? 

Zunächst: Grundsätzlich ist TYPO3 dafür ausgelegt, völlig verschieden gestaltete Websites mit unterschiedlicher Funktionalität gleichzeitig in einer Instanz zu haben. Auch Redakteursrechte können derart granular vergeben werden, dass jeder Redakteur nur die Website bearbeiten kann, für die er freigeschaltet ist.

Gibt es dennoch Einschränkungen? Ja, aber diese sind überschaubar und stellen nur in seltenen Fällen einen Grund dar, Websites nicht in einer gemeinsamen TYPO3 Instanz zu “verheiraten”.

Da wäre zunächst eine technische Besonderheit: Alle Websites innerhalb einer TYPO3-Instanz teilen sich sämtliche Extensions. Das bedeutet in der Praxis, dass solche Extensions, die in der Zielinstanz noch nicht vorhanden sind, dort hinein integriert werden müssen. Da kann es dann auch vorkommen, dass für ein und denselben Zweck unterschiedliche Extensions in der Quell- und der Zielinstanz gewählt wurden und es sinnvoll sein kann, nicht einfach beide parallel zu betreiben, sondern sich für eine von beiden zu entscheiden. Das Zusammenführen verschiedener TYPO3-Website in einer Instanz sollte also auch zum Aufräumen und Modernisieren genutzt werden – das spart Kosten in der laufenden Wartung und bei späteren Upgrades.

Die Rolle des Admins

Ein anderer Aspekt: es gibt die Rolle des Admins, der dann Zugriff auf alle Instanzen und auf alle Backend-Benutzerkonten hat. Dies ist in der Praxis selten ein Problem, könnte aber zu einem werden, wenn aufgrund von Unternehmensrichtlinien hier eine strikte Trennung verlangt wird.

Synergieeffekte

Ein weiterer Aspekt, den man beachten sollte: die Synergieeffekte durch das Zusammenführen verschiedener Website in einer TYPO3-Instanz haben naturgemäß auch eine gewisse Abhängigkeit zur Folge. So sind keine abweichenden Upgrade-Zyklen für einzelne Websites mehr möglich. Wenn man für eine einzelne Website eventuell ein Feature der neuesten TYPO3-Version benötigt, ein Upgrade aber für die gemeinsame Instanz aktuell nicht durchgesetzt werden kann, muss man das in Kauf nehmen oder nach einem Workaround suchen.

Und was ist, wenn eine spätere Trennung der Websites erforderlich ist, weil z.B. eine Unit aus dem Unternehmen herausgelöst wird und separat veräußert werden soll? Das ist zumindest technisch sehr einfach möglich, indem man die Gesamtinstanz dupliziert und alle anderen Websites entfernt. Idealerweise räumt man bei der Gelegenheit auch bei den Extensions auf, denn vermutlich werden nicht alle von der verbleibenden Website benötigt. Und ganz wichtig: aus Datenschutzgründen sollte man auch in der Datenbank aufräumen. Z.B. reicht es nicht aus, dass man nicht mehr benötigte Backend-Nutzer gelöscht hat, denn eine solche Löschung führt in TYPO3 lediglich dazu, dass die Datensätze in der Datenbank nur mit einem deleted-Flag gekennzeichnet werden. Stattdessen muss man tatsächlich den betroffenen Datensatz löschen. Ähnliches gilt für Log- und History-Einträge sowie möglicherweise vertrauliche Daten aus Intranets.