Als 2009 NTT Europe Online (NTTEO) [1], ein Kunde und technischer Partner der Onedrop Solutions GmbH & Co KG [2], die Anfrage stellte, ob Interesse an der Migration aller Tochterfirmen eines großen japanischen Telekommunikationsunternehmens in ein neues CMS besteht, war die Antwort klar. Die Anforderungen waren auf dem Papier weder spektakulär noch exotisch, entpuppten sich aber als durchaus interessant. Sechzehn (Tochter-)Firmen auf drei Kontinenten (Asien/Amerika/Europa) sollten eine neue Heimat bekommen. Die Eckpunkte der Kundenanforderungen lauteten dabei wie folgt:

• Hohe System- und Ausfallsicherheit
• Zentrale Inhaltsverwaltung
• Mehrsprachigkeit
• Migration der bestehenden Seiten
• Dokumentation und Training
• Umfassender Support

Dass hierbei TYPO3 das CMS der Wahl sein würde, war klar. Doch musste man den Kunden von den Vorzügen des in Japan wenig bekannten Systems überzeugen. Mit Hilfe einiger detaillierter Präsentationen, die die Leistungen und den Vergleich zu anderen CMS herausstellten, konnte die verantwortliche Agentur den Kunden von TYPO3 überzeugen.

TYPO3-Extensions für das Projekt

Auf Grund der speziellen und teilweise komplexen Anforderungen entwickelte die umsetzende Agentur eine Reihe von Erweiterungen. Die Extensions, die auch im TYPO3 Extension Repository veröffentlicht wurden, ermöglichen beispielsweise das Setzen eines Default-Workspace beim Login, die Umleitung auf die Domain, die in den Seiteneigenschaften gesetzt wird, das sichere Zurücksetzen des Passworts und andere Features. Die Extensions sind im TER zu finden – Links zu den speziell für das Projekt entwickelten Extensions findet man über den Softlink am Ende dieses Artikels.

Insgesamt kommen 55 Extensions zum Einsatz, unter anderem TemplaVoila, Powermail, Direct Mail, JavaScript Slideshow, Error 404 multilingual, Perfect Lightbox, RealURL, SEO Basics, SEO Pack for tt_news und Spamshield.

Eine zentrale Anforderung war die Sicherheit des zukünftigen Systems, die sowohl Schutz vor Angriffen als auch vor einem etwaigen Ausfall der verwendeten Hardware, respektive kompletter Teile des Netzwerks, bieten sollte. Um dies zu gewährleisten, arbeitete man mit den Systemarchitekten des Partners NTT Europe Online eine globale Infrastruktur mit einem ausgeklügelten Monitoring-System aus.

Da die Unternehmen, deren Seiten zukünftig in nur einer TYPO3-Installation ihre Heimat finden sollten, über drei Kontinente verteilt sind, war eine globale, replizierte Server-Infrastruktur notwendig. Vor dem Hintergrund des Problems eines transatlantischen Delays (ca. 300ms) verteilte man acht virtuelle Server auf die Standorte Hongkong, USA und UK. Mehrere Firewalls an den jeweiligen Standorten sorgten dabei für Schutz. Für die geografische Verteilung der Serveranfragen sowie die notwendigen „Healthchecks“ sollte hingegen das NTTEO-eigene, global implementierte und am ehesten mit einem ausgeklügelten Loadbalancer vergleichbare Smart Content Delivery System (SCD) sorgen.

Der zentrale TYPO3-Server, der so genannte Master, steht im Datacenter London und fungiert primär als Backend-Server, der mittels MySQL-Master-Slave-Replication [3] auf die übrigen Server weltweit gespiegelt wird. Die Replikation erfolgt unidirektional mit einigen Ausnahmen – ausgenommen sind sämtliche Cache-Verzeichnisse. Dahingegen schreiben die einzelnen Slaves Adressdatensätze von beispielsweise Newsletteranmeldungen, RealURL-Redirects (wegen Counter aufgerufener URLs) sowie die RealURL-Unique-Aliases (bei News wird die URL erst beim Initialaufruf generiert) wieder zurück zum Master, der sie von dort aus erneut weltweit repliziert. Rsync [4] sorgt in fünfminütigen Intervallen mittels Cronjob für die Synchronisation des Dateisystems. Zusätzlich synchronisiert ein kleines Skript ausgewählte Verzeichnisse und Konfigurationsdateien bei Bedarf auf ausgewählte Server, um so zum Beispiel die Verteilung von Updates innerhalb der Infrastruktur zu erleichtern.

Redundanzen sind, wenn man nicht gerade von Ausfallsicherheit und Servern spricht, nicht nur in der Programmierung, sondern auch in der Inhaltsverwaltung zu vermeiden, da sie zu höherem Aufwand und vor allem zu Fehlern führen. Da es sich bei den zu implementierenden Websites um die Tochterfirmen eines Konzerns handelt, die im Zuge der Migration größtenteils ein einheitliches Design und eine einheitliche Inhaltsstruktur erhalten sollten, galt es nach Analyse der bestehenden Seiten und gemäß den Angaben des Auftraggebers, die Bereiche zu identifizieren, die ganz oder mehrheitlich für alle Websites identisch waren. Für diese war ein zentrales System zur Inhaltsverwaltung nötig.

Ein weiterer Zweig im Seitenbaum sollte die durchgehend identischen Seiten sowie ähnliche Content-Elemente beherbergen. Die Verlinkung kompletter Seiten in die jeweiligen Websites setzten die Entwickler mittels Mount Points um. Für die einzelnen Content-Elemente wie Textfragmente (zum Beispiel Firmennamen/Zertifizierungen), beinhaltete Links oder auch Bilder kamen hingegen Marker zum Einsatz. Konstanten ersetzten diese wiederum dynamisch zur Laufzeit.

Mehrsprachigkeit war eine Grundvoraussetzung für das System. In Summe galt es, elf verschiedene Sprachen zu implementieren. Neben Englisch als Default-Sprache sollten Deutsch, Portugiesisch, Spanisch, Französisch, Japanisch, Koreanisch und Chinesisch in vier Versionen (simplified, traditional, simplified HongKong, traditional Taiwan) implementiert werden. Eine Herausforderung bestand in der Anweisung, dass die im vorherigen Abschnitt genannten globalen Inhaltsbereiche in den Sprachen Englisch und Japanisch ausschließlich von einer Abteilung des Mutterkonzerns in Japan kontrolliert werden sollten. Die Lokalisierungen in die einzelnen landesspezifischen Sprachen sollten jedoch von den Editoren der einzelnen Tochterunternehmen vorgenommen werden. Da sich diese Inhalte jedoch nicht sehr oft ändern und der Faktor Zeit eine entscheidende Rolle spielte, entschied man sich für eine äußerst einfache Lösung. Für jede der verbleibenden neun Sprachen wurde ein eigener Backend-Benutzer angelegt, der wiederum auf diese eine Sprache limitiert wurde.

Nachdem die umsetzende Agentur die Analyse der bestehenden Seiten beendet, die besonderen Backoffice-Anforderungen der einzelnen Sites geklärt (beispielsweise SalesForce-Anbindung), die Templates erstellt und das System der globalen Inhaltsbereiche entwickelt hatte, ging es an die tatsächliche Migration der Inhalte aus den bestehenden Websites. Hierzu galt es, eine prinzipielle Überlegung anzustellen: Soll ein Skript die Inhalte übertragen oder ist es effizienter, dies manuell mit genügend Manpower zu erledigen?

Nach eingehender Überlegung und den Ergebnissen der Website-Analysen fiel die Wahl auf die manuelle Übertragung, da auf Grund der bis dato zu sehr variierenden Seiten- und Inhaltsstrukturen eine automatisierte Übertragung aus einer Kostenanalyse heraus im klaren Nachteil stand.

So ging die Agentur Site für Site vor und erstellte nach jeder komplettierten Migration eine Checkliste, die alle URLs der neuen Page mit Kontroll- und Kommentarfeldern enthielt. Diese wurde dann an die zugewiesenen Mitarbeiter des Kunden verteilt und im Falle von Korrekturen zur Nachbesserung zurückgesendet.

Nachdem die umsetzende Agentur alle Seiten lauffähig in TYPO3 implementiert hatte, musste sie sich einer weiteren Herausforderung stellen: In den einzelnen Ländern sollten lokale Admins eingesetzt werden, die einen tieferen Einblick in das System hatten, als zentrale Anlaufstelle fungierten und gegebenenfalls Supportanfragen der User selbst lösen oder aber an Onedrop vermitteln sollten.

Diese Admins mussten darüber hinaus auch in der Lage sein, neue Backend-Benutzer anzulegen, bestehende Nutzer zu bearbeiten oder aus dem System zu entfernen. Gleichzeitig sollten sie aber weder Zugriff auf das verwendete TypoScript noch auf die Templates haben.

Ein TYPO3-Admin hat Vollzugriff auf das System – aus diesem Grund kam diese Lösung nicht in Frage. Eine spezielle Berechtigung für den Zugriff auf die Admin-Tools, ohne selbst Admin zu sein, existiert aber nicht. Aus diesem Grund schrieben die Entwickler eine Backend-Extension, die genau dieses Paradoxon möglich machte. Mit Hilfe dieser Extension und der Backend-Gruppen können die „local Admins“ nun Benutzer für ihren Zweig des Seitenbaums auflisten, anlegen, bearbeiten und löschen.

Teile der Anforderungen und somit des Projekts waren die Bereitstellung einer umfangreichen Dokumentation sowie ein Editoren- und Administratorentraining. Erstere realisierte die Agentur in Form eines Quick-Start-Guides, einer ausführlichen Anleitung und eines Video-Tutorials. Darüber hinaus trainierte man die Editoren blockweise (nach Kontinent) mit Hilfe einer Webinar-Software und geschalteter Telefonkonferenz innerhalb von einer Woche.

Die Administratoren hingegen bereitete man in einer dreitägigen Intensivschulung in London, inklusive Audio/Videostreaming und -Aufzeichnung, auf ihre zukünftigen Aufgaben vor. Der laufende Support wird mit Hilfe eines Ticketsystems von NTTEO geleistet.

Das Projekt in Zahlen

16 Websites

11 Sprachen

Replikation in drei verschiedenen Datacentern auf drei Kontinenten

11 Patches (davon drei von Onedrop)

55 Extensions (davon 17 von Onedrop und sieben projektbezogene, siehe Softlink)