in2publish für TYPO3: Content Publishing zwischen Staging und Live

Warum in2publish den Content-Workflow in Enterprise-TYPO3-Projekten definiert

In professionellen TYPO3-Installationen arbeiten Redakteure nicht direkt auf dem Live-System. Sie pflegen Inhalte auf einer Staging-Umgebung, stimmen Änderungen intern ab und veröffentlichen erst nach Freigabe. Aber wie kommen die Daten von Staging auf Live? Ohne in2publish bedeutet das: Datenbank-Dump auf Staging erstellen, auf Live einspielen, Dateien per FTP synchronisieren. Ein Prozess, der fehleranfällig ist, 30 bis 60 Minuten dauert und bei dem ein falscher Klick die gesamte Live-Datenbank überschreiben kann.

in2publish von in2code eliminiert diesen Prozess. Redakteure klicken im TYPO3-Backend auf “Publish”, und die Extension synchronisiert genau die geänderten Datensätze und Dateien auf das Live-System. Keine FTP-Zugänge, keine Datenbank-Dumps, keine Downtime. Der Industriestandard für Content-Staging in TYPO3.

Typische Einsatzszenarien

Redaktioneller Freigabe-Workflow. Ein Konzern betreibt seine Corporate Website auf TYPO3 mit 12 Redakteuren in 3 Abteilungen. Jede Abteilung pflegt ihren Bereich auf Staging. Die Teamleitung prüft die Änderungen und gibt sie frei. Der Redakteur klickt auf “Publish” und nur seine genehmigten Seiten gehen auf Live. Andere Bereiche der Website bleiben unberührt. in2publish zeigt dabei eine Differenzansicht: Welche Felder haben sich geändert, welche Bilder sind neu, welche Datensätze werden überschrieben.

Multi-Language-Publishing. Ein Unternehmen pflegt seine Website in 5 Sprachen. Die deutsche Redaktion veröffentlicht fertige Texte, während die englische Übersetzung noch in Arbeit ist. in2publish ermöglicht selektives Publishing pro Sprache: Der deutsche Content geht live, der englische bleibt auf Staging, bis die Übersetzung abgeschlossen ist.

Kampagnen-Launches mit definierten Terminen. Das Marketing-Team bereitet eine Produkt-Launch-Seite vor, die am 15. Oktober um 8:00 Uhr live gehen soll. Alle Inhalte - Texte, Bilder, Videos, Landingpages - werden auf Staging vorbereitet und getestet. Am Launch-Tag publiziert der verantwortliche Redakteur alles in einem Schritt. Bei Problemen kann in2publish die Änderungen rückgängig machen. Für zeitkritische Launches ist das ein entscheidender Vorteil gegenüber manuellen Deployment-Prozessen, bei denen ein Rollback 30 Minuten oder mehr dauern kann.

Technische Architektur

in2publish arbeitet auf Datenbank- und Dateisystem-Ebene. Die Extension vergleicht den Zustand der Staging-Datenbank mit der Live-Datenbank und überträgt Differenzen.

Die Architektur besteht aus vier Kernkomponenten:

• Record-Comparison: in2publish vergleicht jeden Datensatz (uid, Tabelle, Felder) zwischen Staging und Live. Geänderte, neue und gelöschte Records werden identifiziert und in einer Baumstruktur dargestellt. Relationen (z.B. Seite hat Content-Elemente, Content-Element hat Bilder) werden aufgelöst, sodass beim Publishing einer Seite automatisch alle abhängigen Datensätze mitgenommen werden.
• FAL-Synchronisation: Bilder und Dokumente aus dem File Abstraction Layer werden über SSH/SFTP auf das Live-System übertragen. in2publish vergleicht Dateigrössen und Hashes, um nur geänderte Dateien zu übertragen.
• Transport-Layer: Die Kommunikation zwischen Staging und Live erfolgt über SSH. in2publish verbindet sich per Public-Key-Authentifizierung mit dem Live-Server und führt dort CLI-Commands aus. Alternativ unterstützt die Enterprise-Version eine HTTP-basierte Kommunikation über eine API.
• Konfiguration: Über eine YAML-Konfiguration wird definiert, welche Tabellen publiziert werden (Whitelist) und welche ausgeschlossen sind (z.B. sys_log, be_sessions, cache-Tabellen). Die Standard-Konfiguration deckt alle Content-relevanten Tabellen ab.

Abhängigkeiten: TYPO3 Core, SSH-Zugang zwischen Staging- und Live-Server, PHP-SSH2-Extension oder ssh2-Binaries auf dem Server. Die Netzwerk-Architektur erfordert, dass der Staging-Server eine ausgehende SSH-Verbindung zum Live-Server aufbauen kann. In Unternehmensnetzwerken mit restriktiven Firewall-Regeln muss dafür ein dedizierter SSH-Port freigeschaltet werden.

Häufige Probleme und Lösungen

Problem: Publishing bricht mit “SSH Connection Failed” ab. Die häufigste Ursache: Der SSH-Key des Staging-Servers ist nicht auf dem Live-Server hinterlegt, oder die SSH-Konfiguration in in2publish zeigt auf den falschen Host/Port. Die Lösung: SSH-Verbindung manuell testen (ssh -i /path/to/key user@live-server), dann die Credentials in der in2publish-Konfiguration überprüfen. Bei Managed-Hosting-Umgebungen muss oft der Hoster SSH-Zugang zwischen den Instanzen freischalten.

Problem: Datensätze auf Live werden nicht aktualisiert. Die Tabelle ist nicht in der Whitelist der in2publish-Konfiguration enthalten. Das passiert häufig bei Custom-Tabellen aus eigenen Extensions. Die Lösung: Die Tabelle in der Konfiguration hinzufügen und die Relationen definieren (welches Feld verweist auf welche andere Tabelle). Ohne korrekte Relation-Konfiguration kann in2publish die Abhängigkeiten nicht auflösen.

Problem: FAL-Dateien fehlen nach dem Publishing auf Live. Der FAL-Storage auf dem Live-System hat einen anderen Pfad als auf Staging, oder die Berechtigungen auf dem Live-Server erlauben kein Schreiben in den Upload-Ordner. Die Lösung: Sicherstellen, dass der FAL-Storage-Basepath auf beiden Systemen identisch ist und der SSH-User Schreibrechte im Fileadmin hat.

Migration und Versions-Kompatibilität

in2publish wird von in2code aktiv gepflegt und ist für TYPO3 v11 und v12 LTS als Composer-Paket verfügbar. Die Enterprise-Version bietet zusätzliche Features (HTTP-Transport, erweitertes Logging, Multi-Environment-Support) und ist kostenpflichtig lizenziert.

Für TYPO3 v13 arbeitet in2code an einer kompatiblen Version. Die Extension nutzt stabile TYPO3-APIs (DataHandler, FAL), sodass die Portierung in der Regel zeitnah nach dem LTS-Release erfolgt.

Bei einem TYPO3-Upgrade muss die in2publish-Konfiguration überprüft werden: Neue System-Tabellen, geänderte TCA-Definitionen und neue Content-Element-Typen erfordern eine Anpassung der Whitelist. Gosign empfiehlt nach jedem Core-Upgrade einen Test-Publish mit einer einzelnen Seite, um die Konfiguration zu validieren, bevor der volle Redaktionsbetrieb wieder aufgenommen wird. Der Test sollte eine Seite mit allen relevanten Content-Typen umfassen: Textelemente, Bilder, Datei-Downloads und mindestens eine Relation (z.B. News-Datensatz mit Kategorien). Nur so werden alle Synchronisationspfade abgedeckt.