Die Idee, die dahinter steht ist, einerseits die Versionierung der Inhalte für die Benutzer auf einem transparenten Weg zugänglich zu machen und andererseits den Überarbeitungsprozess mit einem einfachen Freischaltprozess zu unterstützen. Dieser Artikel stellt das hinter den Workspaces stehende Konzept und dessen Umsetzung vor, das bereits in Kasper Skårhøjs Keynote auf der TYCON3-Konferenz für Aufmerksamkeit gesorgt hat.

Bisherige Schwachpunkte bei der redaktionellen Überarbeitung

TYPO3 besticht schon immer durch seine ausgefeilte Handhabung der Inhalte und die effiziente Anpassung der Ausgabe. Eine Schwäche gegenüber Wettbewerbssystemen offenbarte sich jedoch bisher, wenn es um die Kontrolle des Veröffentlichungszyklus ging. Bis zur Version 3.7 konnte eine Überarbeitung der Seiten und Inhalte ausschließlich direkt an den veröffentlichten Inhalten durchgeführt werden. In der Praxis führte dies oft zu lästigen Kopieraktionen, deren Handhabung den Benutzern nicht immer leicht zu vermitteln war. Auch die TYPO3-eigene Workflow-Erweiterung („sys_workflow“/„sys_todo“) konnte hier aufgrund ihrer fehlenden Unterstützung für bereits bestehende Seiten und Inhalte bisher keine wirkliche Abhilfe schaffen.

Versionierung als Grundlage der Workspaces

Wer mit der Entwicklung von TYPO3 vertraut ist weiß, dass TYPO3 seit Version 3.8 im Kern über eine Schnittstelle zur Versionierung von Seiten beziehungsweise Inhalten verfügt. Zu ihrer Nutzung steht mit der Erweiterung „Version-Management” (Extension-Key „version”) bereits seit der Version 3.8 eine Benutzeroberfläche zur Verfügung. Die Versionierung bildet auch die Grundlage der Workspaces.

Übersicht über Backend-Benutzer und -Gruppen sowie ihre Zugriffsrechte auf die Workspaces.

Die Versionierung ermöglicht es, verschiedene Versionen von Seiten und Inhalten zu erzeugen und zu verwalten. Dabei sind drei verschiedene Versionierungsmodi zu unterscheiden: Der Modus „Branch“ versioniert komplette Seiten-(Teil-)Bäume, „Page“ die Seite und die darauf abgelegten Datensätze, „Element“ versioniert nur einzelne Datensätze. Über den Eintrag „versioning“ im Klickmenü wird ein entsprechendes Backend-Modul aufgerufen, in dem die verschiedenen Versionen erzeugt oder verwaltet werden können. Auf die, nicht trivialen, Details und Implikationen hinsichtlich der verschiedenen Versionierungsmodi, unter anderem auch hinsichtlich der Konsistenz von Links und Referenzen, wird in der Dokumentation zu den Workspaces [1] detailliert eingegangen.

Die Seitenvorschau eines Draft-Workspace erfolgt in einem dreiteiligen Frameset und bietet zusätzlichen Zugriff auf ein Verwaltungs-Modul.

Mit den Workspaces wird die Handhabung der Daten nun um ein weiteres Merkmal erweitert: Jede Version eines Datensatzes ist eindeutig einem so genannten Workspace zugeordnet. Jeder Workspace verfügt dabei über eine eigene Ansicht des Seitenbaums, welche man auch als virtuellen Seitenbaum bezeichnen könnte. Dabei sind die drei verschiedenen Arten von Workspaces, als „Live“, „Draft“ und „User“ bezeichnet, zu unterscheiden.

Die Workspaces: „Live“, „Draft“ und „User“

Die Workspaces „Draft“ und „Live“ stehen ab der Version 4.0 standardmäßig in jeder TYPO3-Installation zur Verfügung, ohne dass dazu eine weitere Benutzerinteraktion notwendig ist. Im Live-Workspace werden die Seiten und Inhalte, wie sie auf der Webseite (Frontend) veröffentlicht sind, verwaltet. Bearbeitungen im Live-Workspace wirken sich damit wie bisher unmittelbar auf die veröffentlichten Seiten und Inhalte aus. Der Live-Workspace entspricht damit exakt dem Verhalten einer altbekannten TYPO3-Umgebung.

Auch der Draft-Workspace stellt sich für den Benutzer, bis auf eine zusätzliche Bezeichnung oberhalb des Seitenbaums, wie bekannt dar. Innerhalb des Draft-Workspace wird zunächst der Seitenbaum samt Inhalt eingeblendet, wie er auch dem Live-Baum entspricht. Sobald jedoch im Draft-Workspace auf einem der üblichen Wege eine Änderung vorgenommen wird, erzeugt TYPO3 automatisch eine neue Version des Elements, ohne die Live-Inhalte zu verändern. Im Draft-Workspace wird dazu der Versionierungsmodus „Element“ verwendet. Zusätzlich steht im Seitenmodul auch ein Button „New version of Page” zur Verfügung, mit dessen Verwendung der Versionierungsmodus „Page“ ausgelöst wird. Sobald eine Seite von der Live-Version abweicht, wird eine farbliche Kennzeichnung vorgenommen. Dabei dienen die farblich unterschiedlichen Markierungen zur Verdeutlichung der verschiedenen Versionierungsmodi „Branch“, „Page“ und „Element“, wie sie oben bereits bei der Versionierung angesprochen wurden. Das Schöne und Neue: Der Redakteur braucht sich im Draft-Workspace nicht explizit um eine Versionierung bemühen, weil TYPO3 diese automatisch vornimmt. Auf die Implikationen und Besonderheiten hinsichtlich der verschiedenen Überarbeitungsmodi wird in der Dokumentation in [1] eingegangen.

Neben den bereits standardmäßig vorhandenen Draft- und Live-Workspaces sind auch individuelle User-Workspaces vorgesehen. Für deren Nutzung sind entsprechende Konfigurations-Datensätze auf der Root-Seite anzulegen. Die User-Workspaces bieten gegenüber dem Draft-Workspace einige zusätzliche Möglichkeiten, beispielweise für eigene Datenbank-Mounts, Datei-Mounts und Rollenzuweisungen für den Veröffentlichungsprozess. Außerdem sind automatisierte Publizierungen via cronjobs oder eine Einschränkung auf bestimmte Versionierungsmodi vorgesehen. Nur in einem User-Workspace ist es möglich, auf das Dateilistenmodul und damit das Dateimanagement zuzugreifen. Dazu muss ein expliziter Filemount im User-Workspace angelegt werden. Dies ist erforderlich, da das Dateimanagement nicht von der Versionierung erfasst wird und nur so Wechselwirkungen mit der Live-Version ausgeschlossen werden können. Derzeit müssen die User-Workspaces noch von Administratoren angelegt werden.

Die für einen Benutzer zugreifbaren Workspaces sind über eine Selectbox im Shortcut-Frame am unteren Rand des TYPO3-Backends wählbar. Durch die Wahl eines dieser Workspaces in der Selectbox wird das gesamte TYPO3-Backend neu geladen. Der jeweils aktuell verwendete Workspace wird dabei zur Orientierung oberhalb des Seitenbaums angezeigt.

Übersicht, Seitenstatus und Verwaltung mit dem Workspace-Manager.

Workspaces und Zugriffsrechte

Über ein zusätzliches Feld bei den Backend-Benutzergruppen beziehungsweise Benutzern wird die Rechtevergabe zum Zugriff auf den Live- oder Draft-Workspace einzeln festgelegt. Die Berechtigung „Edit Live” entpricht der bisherigen Arbeitsweise. Sollen Benutzer die Möglichkeit haben Seiten zu veröffentlichen, muss ihnen dieses Recht eingeräumt werden. Benutzer mit ausschließlichem Zugriff auf den Draft-Workspace können die Inhalte zwar bearbeiten, nicht jedoch veröffentlichen. Die dritte Option zur Anlege-Berechtigung von User-Workspaces ist derzeit noch nicht implementiert. Auch in den Workspaces sind zur Bearbeitung weiterhin die üblichen Seitenzugriffsrechte gültig und zu beachten. In der Dokumentation [1] wird detailliert auf die Implikationen der einzelnen Rechte und ihre Auswirkungen hinsichtlich der einzelnen Arbeitsschritte im Veröffentlichungsprozess eingegangen.

Veröffentlichung und Bearbeitungsstatus

Über die Module Web/Versioning oder Benutzer/Workspace werden die verschiedenen Versionen der Elemente gegenübergestellt. Das Modul Web/Versioning stellt dabei jeweils einzelne Seiten dar, während Benutzer/Workspace Änderungen über den kompletten Seitenbaum verfolgt und zusätzliche Optionen, beispielsweise zur Anzeige von Änderungen, zur Verfügung stellt. Aus diesen Modulen heraus ist eine direkte Veröffentlichung möglich. Dazu benötigt der Benutzer allerdings entsprechende Rechte zur Bearbeitung des Live-Workspace.

Das Seitenmodul mit geladenem Draft-Workspace. Zu erkennen sind die farblichen Markierungen für überarbeitete Seiten und Elemente sowie der Workspace-Selektor im Shortcut-Frame.

Bei der Veröffentlichung stehen zwei Verfahren, „Publish” und „Swap”, zur Verfügung. Bei „Publish” wird die Version veröffentlicht, während die derzeitige Live-Version in einen Archivstatus versetzt wird. Bei „Swap” werden Live- und Draft-Version getauscht. Gedacht ist dies beispielweise für temporäre Sondereditionen, bei denen später wieder zur Ursprungsversion zurückgekehrt wird. Neben der direkten Veröffentlichung kann auch der Status des Dokuments („controls”) während des Veröffentlichungszyklus gesetzt werden. Die Seiten und Inhalte verfügen nunmehr über ein Flag bezüglich ihres Status im Veröffentlichungszyklus. „editing” steht dabei für Elemente in Bearbeitung, „review” für Elemente im Prüfungsstatus, „publish” für Elemente, die bereits zur Veröffentlichung freigegeben sind und „rejected” für Elemente, die wieder in den„editing”-Status überführt werden sollen. Bei der Statusänderung eines Datensatzes über eines der Controls neben dem aktuellen Status kann auch jeweils ein Kommentar eingegeben werden. Das Statusprotokoll samt Kommentaren wird bei einem „mouseover” in einem kleinen Bubbleup angezeigt. Leider ist es derzeit ausschließlich in einem User-Workspace möglich, den Zugriff auf die verschiedenen Stati auch an bestimmte Benutzergruppen zu binden. Es ist damit aber – zumindest in den User-Workspaces – möglich, einen einfachen redaktionellen Workflow samt Rollenverteilung für Review und Publizierung zu realisieren.

Seitenvorschau

Wird in einem Draft- oder User-Workspace über das Kontextmenü (Lupe) die Seitenvorschau im Frontend aufgerufen, so wird ein dreigeteiltes Frameset aufgebaut, in dem Links übereinander die Frontend-Ansichten der aktuellen Live- und der Draft-Version gegenübergestellt werden. Daneben befindet sich ein Backend-Modul zur Verwaltung, um das Veröffentlichen beziehungsweise Setzen des jeweiligen Seitenstatus zu ermöglichen.

Fazit

Zum Zeitpunkt der Erstellung dieses Artikels ist die BETA-Version in eine erste offizielle Testphase gegangen. Bis zur Veröffentlichung der Version 4.0 Ende Januar 2006 werden möglicherweise noch einige Änderungen vorgenommen werden. Um eine möglichst anwendergerechte und fehlerfreie Handhabung zu gewährleisten, sollten nach Möglichkeit bereits jetzt auf breiterer Basis Testinstallationen durchgeführt werden und Feedback über die Mailinglisten oder den Bugtracker gegeben werden.

Die Umsetzung der Workspaces verspricht zum jetzigen Zeitpunkt eine neue Ära in der Benutzung von TYPO3 einzuläuten. Verschiedene Versionen der Inhalte können damit auf einfache Art und Weise erzeugt und verwaltet werden. Mit den Workspaces ist auf jeden Fall eine sehr komfortable Überarbeitung der Inhalte unter Beibehaltung der bereits veröffentlichten Live-Inhalte möglich. Dadurch wird die technisch eingesetzte Versionierung für einen Redakteur auf einfache und intuitive Art und Weise nutzbar. Für die Revision und Veröffentlichung stehen entsprechende Backend-Module zur Verwaltung und Handhabung der Inhalte aus den Live- und Draft-Workspaces bereit. Bei entsprechender Konfiguration kann das eigentliche Veröffentlichen von Seiten und Inhalten auch auf bestimmte Nutzergruppen eingeschränkt sowie ein kontrollierter Redaktions-Workflow abgebildet werden.

Allerdings erfordert das neue Workspace-Konzept für Administratoren eine gewisse Einarbeitungszeit, um wirklich effizient damit arbeiten zu können. Leider scheint die Benutzerführung derzeit noch nicht überall konstant. Der Versionierungsmodus „Branch“ scheint derzeit nur über das Klickmenü „versionierung“ verwendbar zu sein. Solche kleineren Wehwehchen sollten bis zur endgültigen Freigabe der Version 4.0 noch ausgemerzt werden. Auch für Extension-Entwickler ergeben sich einige Implikationen die beachtet werden müssen, um eine Extension mit dem Workspace-Konzept kompatibel zu machen.

Eine spannende Frage zur weiteren Entwicklung wird sicherlich sein, wie sich die beiden derzeit noch nicht verknüpften Ansätze der Workflow-Extension und Workspaces entwickeln werden, und ob möglicherweise eine Integration der Workspaces in das native Workflow-System vorgenommen wird. Eine Entscheidung wird sicherlich auch abhängig von dem Benutzerfeedback auf den Release 4.0 sein.

Unbedingt beachtet werden muss bei der Versionierung beziehungsweise auch bei den Workspaces, dass einige MySQL-Versionen 3.x.y. möglicherweise Probleme verursachen und nur MySQL-Versionen größer 4.0.18 verwendet werden sollten. Von Mathias Schreiber (WMDB) gibt es einen Patch [2], der die Probleme mit einigen älteren MySQL-Versionen behebt.