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. Eine etablierte Lösung für Content-Staging über zwei getrennte TYPO3-Server.

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. Bricht die Veröffentlichung mit einem Fehler ab, rollt in2publish die Datenbank-Änderungen dieses Vorgangs zurück. 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ößen 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. Für Umgebungen ohne SSH bietet in2code ein kostenpflichtiges HTTP-Add-on (in2publish_http) an.
• Konfiguration: Über eine YAML-Konfiguration wird definiert, welche Tabellen von der Veröffentlichung ausgeschlossen sind (excludeRelatedTables, z.B. be_users, sys_history, sys_log); alle übrigen Tabellen mit TCA publiziert in2publish. Die Standard-Konfiguration deckt alle Content-relevanten Tabellen ab.

Abhängigkeiten: TYPO3 Core, SSH-Zugang zwischen Staging- und Live-Server, PHP-Extension ssh2 auf dem Server (die ssh-Programme des Systems nutzt nur das kostenpflichtige Add-on in2publish_native). 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 steht in der Ausschlussliste excludeRelatedTables, oder ihre Relationen sind im TCA nicht sauber deklariert. Das passiert häufig bei Custom-Tabellen aus eigenen Extensions. Die Lösung: Die Tabelle aus der Ausschlussliste nehmen und die Relationen im TCA korrekt deklarieren (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 als Community Edition in2publish_core für TYPO3 v12, v13 und v14 als Composer-Paket verfügbar. Die Enterprise-Version bietet zusätzliche Features (Freigabe-Workflows, zeitgesteuertes Publizieren, Benachrichtigungen) und ist kostenpflichtig lizenziert.

Jede TYPO3-Version hat eine eigene Reihe: 12.x für v12, 13.x für v13 seit März 2025 und 14.x für v14 seit Mai 2026.

Bei einem TYPO3-Upgrade muss die in2publish-Konfiguration überprüft werden: Neue System-Tabellen, geänderte TCA-Definitionen und neue Content-Element-Typen können eine Anpassung der Ausschlussliste erfordern. 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.