Content-Publisher vs. Workspaces

Workflows in TYPO3 sind ein altes und auch immer wieder leidiges Thema, dass speziell uns von dpool seit sehr langer Zeit immer wieder beschäftigt. Zu den jüngsten Lösungen gehört der Content-Publisher von den Kollegen bei in2code aus Rosenheim. Wir haben als eine der ersten umfangreiche Erfahrungen im echten Enterprise-Einsatz sammeln können.

Workspaces in TYPO3: keine reine Erfolgsstory

Als Kasper Skårhøj vor mehr als 10 Jahren überraschend die sog. Workspaces in TYPO3 einführte, war dies eine Antwort auf die Anforderungen von Dassault Systèmes, dem Hersteller von CATIA, der ihn beauftragte.  Anders als das Templating-System „TemplaVoila“, welches aus demselben Sponsoring entstand, haben es die Workspaces in Sachen Fertigstellung und Funktionsumfang aber nie so weit gebracht und dementspreched was Akzeptanz und Verbreitung anbetrifft keine großen Erfolge gefeiert. Auf Anfrage, ob mit TYPO3 Workflows möglich seien, hat man brav genickt, aber doch gehofft, dass die am Ende nicht gebraucht würden.

„Aus Gründen“, möchte man hinzufügen, denn unsere Erfahrungen im Kundeneinsatz waren selten ausschließlich positiv. Insbesondere die Website eines institutionellen Kunden, dem Deutschen Museum in München mit beinahe 20.000 Seiten, hat über die Zeit einen beträchtlichen Datenfriedhof aufgebaut. Aber auch in der alltäglichen Bedienung gibt es vielfältige Umständlichkeiten.

Hier die wichtigsten im Überblick:

  • Preview bei mehreren Sprachen für Publikation nicht einsetzbar
  • Performanz-Probleme im Seitenbaum
  • Software-Bugs: Sortierung, Meta-Daten Dateien, Referenz-Index, Übersetzungen
  • User-Interface Workspaces List-Modul – noch Fragen

Auch in Bezug auf die Software-Architektur gibt es Einschränkungen und Mängel, die den Einsatz erschweren:

  • Invasiv: nicht mit allem kompatibel: TypoScript, realurl, solr, Sprachauswahl ohne L-Parameter
  • Kein Staging von Dateien
  • Workflow nicht/kaum von aussen steuerbar
  • Workflow-Verhalten „hardcodiert“ in den Domain-Models

Workflow-Anforderungen im Enterprise Umfeld

Bei unserem Kunden handelt es sich um ein international tätiges Unternehmen  mit ca. 12.000 Mitarbeitern. Die Website zählt knapp 1.000 Seiten in mehr als 30 Sprachen, von denen 5 vollständig übersetzt sind.
An der Website arbeiten mehr als 100 Redakteure, sodass ein geregelter Workflow notwendig und sinnvoll ist.

Die technischen Anforderungen in unserem Projekt waren/sind wie folgt:

  • Einfach zu bedienendes, seitenorientiertes User-Interface
  • Klare Markierung von Workflow-States im Seitenbaum
  • Staging von Änderungen im Datei-System
  • Live / Staging sollen 100% identisch sein – keine Nebeneffekte durch Software-Architektur
  • Möglichkeit Workflow-States von aussen zu steuern.
  • Sprachauswahl nicht über Standard L-Parameter
    https://xxx.yyy.zz/de/de
    https://xxx.yyy.zz/en/de

Architektur Contentpublisher

Der Content Publisher imitiert eine Arbeitsweise, wie sie bei den Java-basierten Enterprise WCM-Systemen immer schon gängig war:
zwei vollständig unabhängige TYPO3-Instanzen kommunizieren miteinander, die durch die Extension in eine Master/Slave Beziehung gebracht werden. Mithin also eine echte Staging-Lösung in der die Live-Umgebung wirklich nichts anderes tut, als die Website auszuliefern. Der sog. „Master“ nutzt dabei eine sichere SSH-Verbindung, um auf Dateisystem und Datenbank zuzugreifen, bzw. freigegebene Inhalte zu publizieren.

 

Dabei arbeiten die Redakteure ganz regulär im Backend und können im Seitenbaum erkennen, in welchem Status des Workflows sich die einzelnen Seiten befinden.

Die Anforderung ein Seitenbasiertes Interface anzubieten, ist hier gut umgesetzt, die Seiten sind im Seitenbaum klar markiert.
Im Page-Modul sehe ich ebenfalls den Workflow-Schritt der aktuellen Seite und habe direkt Zugriff auf ein einfaches Interface, um den Workflow-Schritt zu ändern.

Das Verhalten der Workflows wird über yml-Dateien konfiguriert und Workflow-Status* werden ganz simpel über eine eigene Datenbank-Tabelle abgebildet: Tabellenname, UID, Workflow-State-ID
.

Hier der Screen, in dem ich den Workflow-Status verändere.
Potentiell gibt es hier noch zusätzliche Optionen Email-Benachrichtigungen zu versenden.

Einschränkungen des Content Publishers

Am wichtigsten: der Seitenbaum stellt nur Status der Default-Sprache dar! Auch das User-Interface in Bezug auf gelöschte Seiten ist (noch) nicht ideal und es gibt nur einen einheitlichen Workspace für alle Nutzer.

Das klingt erstmal schlimmer als es ist, auch im Vergleich zu anderen WCM-Systemen schlägt sich TYPO3 in Kombination mit dem Content-Publisher aber mehr als wacker. Es gibt sicher noch komplexere Anforderungen und auch WCM-Systeme die sich auf das Thema geradezu spezialisiert haben (Wie SDL Tridion), jedoch muss man sagen, dass dies ausschließlich sehr kostspielige kommerziell lizensierte Systeme sind – und solche Anforderungen ausgesprochen selten im WCM-System realisiert werden müssen.

Im Open Source Umfeld und den üblichen Alternativen Drupal, Craft, Umbraco, Joomla und auch den Newcomern wie Graf, Netlify, October oder CMS Made Simple ist TYPO3 mit dem Content-Publisher Modul allein auf weiter Flur. Erst recht wenn die weit verbreitete PHP-Plattform in Frage kommt, bleibt TYPO3 als einzige Open Source Lösung mit Enterprise Fähigkeiten übrig.

Kosten und Einrichtung

Nun ist die Enterprise Version des Content-Publisher nicht frei verfügbar, sondern kostet 3990,- einmalig und 250,- Euro zzgl. MwSt. im Monat. Beides keine besonders hohen Beträge in einem Enterprise Projekt. Eine freie Version gibt es auch, die allerdings erheblich weniger kann und vor allem keine gesonderten Workflows für Sprachversionen, womit sie als reine Staging-Basis nützlich bleibt, aber eben für sehr spezielle Anforderungen.

Die  Implementation selbst durch die ausführende Agentur ist pauschal schwer zu beziffern. Wir haben durch das oben genannte Projekt viele Erfahrungen gemacht, die uns weiteren Projekten erheblichen Aufwand ersparen werden. Und wir haben dabei auch eine ganze Reihe von Spezialfällen produziert, die zu Problemen geführt haben und die mittlerweile in die Weiterentwicklung eingeflossen sind. Mehrsprachigkeit, Multi-Domains und Multi-Funktionen potenzieren sich gegenseitig, sowohl was die Optionen, als auch was die Fehlerquellen anbetrifft.

Wenn Sie ein entsprechendes Projekt planen, sprechen Sie uns gern an, wir nehmen uns Zeit für Sie und machen Ihnen eine realistisches Angebot, für diese,  und natürlich auch andere Leistungen.

Ihr Ansprechpartner:
Daniel Thomas
089/189 32 67 00
E-Mail: daniel.thomas@dpool.com

*Was man auch als nicht-Lateiner durch die Beschäftigung mit Workflows unter anderem lernt: der Plural von Status ist Status (Statu-us gesprochen)  und nicht "Stati". Stimmt wirklich.