Contentworkflow – immer wieder ein heißes Thema für größere Unternehmen mit umfangreichen Websites. Oftmals ist die Person in der Redaktion, die Inhalte erzeugt jemand anderes als die Person, die diese Inhalte auch wirklich final freigibt. Eventuell gibt es sogar noch mehr hierarchische Ebenen. Compliance-Gründe oder das Vier-Augen-Prinzip spielen hierbei eine wichtige Rolle.
Wenn man an Workflows und TYPO3 denkt, so fällt einem wahrscheinlich zuerst die Systemfunktion Workspaces ein. Sie bietet auf den ersten Blick alles was man sich wünscht – Versionierung von Inhalten, Freigabeprozesse für Redakteure und einen relativ guten visuellen Vergleich der Änderungen zwischen der Live und Workspace Version.
In der Praxis jedoch ergeben sich dabei aber in vielen Installationen auch Probleme. Während die Datensätze aus dem TYPO3 Core nahezu fehlerfrei unterstützt werden, scheitert es oft an den Erweiterungen aus dem Extension Repository oder auch an selbst entwickelten Extensions. Ursache dafür sind Datenbankstrukturen, TCA und zum Teil auch weitere Konfigurationen, die speziell darauf abgestimmt sein müssen. Auch angesammelter Datenmüll kann niedrige Performance der Website verursachen. In Verbindung mit Mehrsprachigkeit und File Referenzen kommt TYPO3 ebenfalls an seine Grenzen und es führt zu unerwünschtem Verhalten.
Ein weiterer Aspekt der Workspaces ist, dass alle Redakteure auch weiterhin direkt auf dem Live – also Produktiv-System arbeiten. Jede Operation auf einer Seite im Live Workspace zieht zur Folge, dass der Cache der Seite und ggf. sogar weiterer Seiten gelöscht werden. Dies reduziert die Performance der Seite ebenfalls erheblich.
Wie ist in2publish entstanden?
Anfang 2015 bekamen wir eine Anfrage eines international agierenden Immobilien-Konzerns, der sich Freigabeprozesse in TYPO3 wünschte. Uns war klar, dass im Kontext dieser Installation Workspaces nicht funktionieren würde. Ein eigener Ansatz musste her, der für solch große Unternehmen geeignet ist.
Wie funktioniert in2publish?
Der Hauptunterschied zwischen Workspaces und dem Content Publisher ist die Trennung zwischen dem Stage- und Live-System. Während Workspaces auf Versionierung von Datensätzen und die Unterscheidung zwischen Live und Draft Datensatz setzen, transportieren wir mit dem Publisher Inhalte von Stage nach Live, woraus sich mehrere Vorteile ergeben.
Zum einen müssen eingesetzte Extensions nicht kompatibel für Workspaces sein, sondern sich nur primär an die TCA Standards von TYPO3 selbst halten. Zum anderen kann das Live System sicherheitstechnisch abgeriegelt werden, d.h. auf das Live Backend haben Redakteure keinen Zugriff, während sich das Staging-System im Intranet befinden könnte. Der Live Cache wird auch nur dann gelöscht, wenn Inhalte publiziert werden, d.h. das kann zum Beispiel zu einem festgelegten Zeitpunkt passieren, so dass Caches seltener neu aufgebaut werden müssen.
Gab es Herausforderungen?
Allerdings. Zwei Punkte sind es in der Regel, die besonders beachtet werden mussten.
Die größte Gefahr geht von User Generated Content aus. Im Speziellen von FAL Referenzen. Das heißt, wenn es eine Funktion im Frontend gibt, an der Besucher Datensätze und im Speziellen Dateien erzeugen, dann muss sichergestellt werden, dass es zu keinen Überschneidungen von UID zwischen Stage und Live kommt. Ansonsten besteht die Gefahr, dass beim Publizieren von Dateien unerwartete Ergebnisse entstehen. In diesem Fall würde auf Live eine andere Datei angezeigt, als auf Stage. Um dieses Problem zu lösen, haben wir verschiedene Ansätze.
Eine Möglichkeit ist eine unterschiedliche Schrittweise für das Auto Increment auf Stage und Live oder das Auto Increment auf Live wird auf einen deutlich größeren Wert gesetzt, sodass jeder Server einen eigenen Bereich besitzt.
Die zweite Herausforderung liegt an den System-Limitierungen. Unser Prinzip beruht auf einem Soll-Ist-Vergleich zwischen Stage und Live. Konkret bedeutet das, dass alle Relationen eines Datensatzes aufgelöst und mit dem Gegenstück auf Live verglichen werden. Wenn wir uns den typischen Fall einer Seite ansehen, haben wir folgende Datensätze:
- Die Seite selbst
- die Content Elemente auf der Seite
- die Fal Referenzen von den Content Elementen
- die Übersetzungen der Seite, der Content Elemente, ….
Somit können schon bei einer einzelnen Seite sehr viele Datensätze zusammen kommen. Nun vergleicht der Publisher jeden Datensatz mit Hilfe einer Abfrage zwischen Stage und Live. Limitierungen greifen dann, wenn die Anzahl der Datensätze zu groß werden. Und natürlich möchte kein Redakteur 40 Sekunden warten müssen, bis er weiterarbeiten kann. Das können wir allerdings noch umschiffen, indem wir Features wie Fire & Forget haben, bei denen die Publizierung im Hintergrund läuft. An das finale Limit kommen wir dann, wenn Anzahl und Größe der Abfragen durch den Server nicht mehr bewältigt werden können. Dann ist die letzte Lösung noch, Datensätze anders zu verteilen, bzw. alternative Publizierungs-Methoden zu wählen.
Technisch stellt die Entwicklung und Wartung der Extension uns auch immer wieder vor Herausforderungen. Gemäß unserem Versprechen an unsere Kunden, stellen wir immer kompatible Versionen für die aktuellen LTS Versionen von TYPO3 bereit. Hier müssen wir dann durch viele Tests gewährleisten, dass verschiedene TYPO3-Versionen mit sehr unterschiedlichen Feature-Sets funktionieren. Unser Ansatz ist dabei, zuerst überhaupt alle Testszenarien zu definieren und so weit wie möglich mit automatischen Tests abzudecken, was nicht immer einfach ist.
Damit haben wir aber auch schon den ersten der drei Schwerpunkte für die Weiterentwicklung. Automatisierte Tests verbessern die Stabilität der Software. Der zweite Schwerpunkt ist die generelle Performance. Wir sind auf der Suche nach alternativen Publizierungs-Methoden, um die oben genannten Limitierungen zu lösen.
Unser persönliches Lieblingsprojekt ist die Überarbeitung der Benutzeroberfläche. Sie wurde von Technikern gestaltet und sieht dementsprechend funktionsorientiert aus. Das Ziel ist es, eine stärkere Orientierung an den Bedürfnissen der Redakteure und auch eine bessere Konformität mit dem User Interface von TYPO3. Die Arbeit wird uns daher nicht ausgehen und mit
2567 Commits
159 Releases seit 2015 und
9 Contributoren
motivieren wir uns täglich mehr, unsere Arbeit immer auf die Spitze zu treiben.
Wer mehr über in2publish wissen möchte oder Fragen hat kann sich gerne auf unserer Website informieren oder uns persönlich kontaktieren.
Euer in2code Team!
