Rechtemanagement TYPOlight
Das Rechtemanagement für den Redaktionsworkflow in TYPOlight halte ich für sehr granular. Intuitiv ist es leider nicht an jeder Stelle, wie ich feststellen musste, als ich mich dann nun noch einmal näher mit dem Kommentar zum Artikel über die Kritik an TYPOlight befasst und einige Test gemacht haben.
Wie ist also der Stand der Dinge? Was geht und was nicht geht. Und vor allem: brauchen wir das alles überhaupt?
Die Benutzer und die Mitglieder einer TYPOlight Site
TYPOlight unterscheidet zwischen Benutzern, das sind beispielsweise der Administrator, Redakteure und Lektoren und den Mitgliedern einer Site, also den “ganz normalen” registrierten Benutzern des Frontends.
Beiden Gruppen können ganz bestimmte Rechte zugewiesen werden, die Mitglieder (Vorsicht, hier verbirgt sich eine Doppeldeutigkeit!) dieser beiden Gruppen können entweder die Rechte der Gruppe erben, zusätzlich zum Administrator ernannt werden, eigene zusätzliche Rechte bekommen oder ein komplett eigenes Rechtesystem. Klingt eigentlich ganz gut, soweit.
Wenn es um Redaktion geht, dann geht es im Weiteren um die Gruppe der Benutzer, also der registrierten User, die auch aufs Backend zugreifen.
Seitenstruktur, Artikel und Rechte
Die Basis einer TYPOlight Website ist die hierarchisch angelegte Seitenstruktur. Pro Seite gibt es dann ein oder mehrere Artikel. Diese Artikel wiederum bestehen aus mindestens einem Inhaltselement. Optional kann dazu ein Teasertext angelegt werden.
Eine Seite hat immer einen Besitzer, der zu den registrierten Benutzern der Site gehören muss und außerdem eine Besitzergruppe. Für diese beiden Ebenen wie auch alle anderen registrierten Benutzer können separat Rechte an der einzelnen Seite vergeben werden. Anderenfalls gelten die Rechte der übergeordneten Seite. Die Rechte werden für die Seite wie auch die Artikel dieser Seite vergeben.
Es ist also theoretisch denkbar, den Besitzer der Seite im Hinblick auf das Ändern von Artikeln mit weniger Rechten auszustatten als die Besitzergruppe (was ich nicht als sinnvoll erachte).
Sinnvoller ist es, dem Besitzer der Seite alle Rechte zu vergeben und der Gruppe nur die Rechte auf Artikel. Hiermit gäbe es einen Verantwortlichen für die Seite selbst und einen oder mehrere für die Inhalte, also die Artikel.
Problematischerweise gibt es an dieser Stelle jedoch nur die Optionen bearbeiten, Hierarchie ändern und löschen. Wer also irgendwelche Rechte am Artikel hat, kann Artikel hinzufügen und duplizieren. Einzig für das Löschen gibt es eine Einschränkung.
Welche Rechte der Benutzer nun für die Artikelerstellung haben, wird direkt in der Benutzerverwaltung eingestellt und gilt dann Site-übergreifend. Die Einstellungen sind umfassend und granular sowohl für den Artikel selbst als auch für Inhaltselemente (und natürlich auch alle anderen Module des Systems).
Grenzen
Die Grenzen liegen bei der Überlegungen des Kommentars zu meinem Artikel über die Kritik eines Joomla Users an TYPOlight.
Es wäre schön- so war da die Idee- wenn man dem Redakteur bereits eine Artikelstruktur vorgeben könne. Konsequent wie ich finde, - ich sehe in den TYPOlight Inhaltselementen durchaus eine Chance.
Meine Idee dazu war folgende:
- der Administrator legt eine Seite samt Artikel mit Dummytexten an
- will der Autor einen neuen Artikel anlegen, so kopiert er jene Vorlage und befüllt die vorgegebenen Elemente mit Text
Dies geht prinzipiell natürlich schon, die Rechte des Autors sind jedoch durch die Notwendigkeit der Rechtevergabe so groß, dass man sich diese Restriktion sparen kann. Diese Artikelvorlage wäre also nichts anderes als eine Servicemaßnahme, jedoch kein Schritt innerhalb eines mit strikten Rechten versehenen Workflows.
Besser ist es da wahrscheinlich, die Rechte an den Inhaltselementen einzuschränken und mit TINY MCE Vorlagen zu arbeiten.
Möglichkeiten zur Restriktion?
Schon allein die Überschrift zeigt eigentlich, wie kritisch das Ganze ist. Will oder muss man wirklich restriktiv eingreifen? Geht es hier nicht schlicht um Verantwortlichkeiten? Wie kann man aber nun mit TYPOlight das Beste daraus machen. Auch eine Frage, die sich letztens innerhalb eines Projekts stellte.
Generell stellt sich die Frage, auf was man denn nun setzt: auf das Inhaltselement oder auf die Editor Vorlage. Ich bin eigentlich überzeugt vom hybriden Ansatz, da einige Inhaltselemente sehr praktische Helferlein darstellen, die in Vorlagen erst mühsam konzipiert werden müssten und schneller per CSS in den Griff zu bekommen sind.
Mit Hilfe eines durchdachten Rechtesystems, in dem es Gruppen eventuell für die verschiedenen Bereiche der Site gibt (Fachautoren beispielsweise für…) und in diesen Gruppen wiederum Verantwortliche mit Berechtigungen auf die Seitenstruktur, können die Rechte an einzelnen Elementen der Website sehr gut definiert werden.
Weiterhin offen bleibt das Recht am Artikel. Es kann schließlich sein, dass eine Seite inhaltlich Artikel aus verschiedenen Fachbereichen mit verschiedenen Zuständigkeiten umfasst. Hier ist das Rechtesystem schlichtweg nicht ausreichend.
Ebenfalls nicht abgedeckt ist der Workflow im Redaktionsworkflow. Eine automatische Benachrichtigung und ein Freigabemechanismus wären da natürlich eine wichtige Sache. - Wie auch Joomla, das hier ja ursprünglich zu diesem Beitrag mit animierte, gibt es nur “veröffentlicht” und “nicht veröffentlicht” als Status eines Artikels.
Fazit?
Gut, dies alles sind marginale Probleme. Wer wirklich auf ein dezidiertes Rechtemanagement angewiesen ist, wird sich für ein Enterprise CMS entscheiden. In der Praxis habe ich bisher auch bei größeren Sites meist erlebt, dass zwei bis drei Leute an einer Website gearbeitet haben, so dass Absprachen unproblematisch sind.
Interessanter finde ich das Rechtemanagement fürs Frontend, insbesondere die Möglichkeit, Inhaltselemente je nach Mitgliederberechtigung anzuzeigen. Ganz schlicht ist hier denkbar, dem nichteingeloggten Benutzer Informationen zu Anmeldung und Registrierung anzuzeigen, während der angemeldete Benutzer einen freundlichen Begrüßungstext sieht. Für weitere Szenarien sind natürlich der Phantasie keine Grenzen gesetzt. Da die Rechte für Inhaltselemente vergeben werden (und dazu zählen auch Module, beispielsweise Navigationselement) wird das System gerade an der Stelle ungeheuer flexibel.
Das gewünschte Szenario, dem Benutzer Artikel mit vordefinierten Inhaltselementen als Vorlage anzubieten, die ausschließlich kopiert, eingefügt und editiert werden können, und dabei noch vorzugeben, dass es beispielsweise eine maximale Anzahl an Artikeln pro Seite geben kann, sehe ich mit Bordmitteln als nicht realisierbar.
Die Frage ist, ob das nicht alles sowieso l’art pour l’art ist? Wie viel Feature braucht ein CMS überhaupt, beziehungsweise wo ist die Allgemeingültigkeit überschritten, wo fängt der spezielle Kundenwunsch an? Ich halte die ACL für ein wichtiges Feature. Sieht das der Kunde genauso? Gleiches gilt wahrscheinlich auch für eine Reihe anderer Funktionen…
der Joomlasche :)
“Das gewünschte Szenario, dem Benutzer Artikel mit vordefinierten Inhaltselementen als Vorlage anzubieten, die ausschließlich kopiert, eingefügt und editiert werden können, und dabei noch vorzugeben, dass es beispielsweise eine maximale Anzahl an Artikeln pro Seite geben kann, sehe ich mit Bordmitteln als nicht realisierbar.”
Das ist ein Manko was wohl jedes Content Management System mit sich rumschleppt. Meiner Meinung nach nicht verständlich. Es wird sich überall beschwert, das Autoren und Webseitenbetreiber aus einer hübschen Seite, mit Ihren “eigenwilligen” Word-Schönheitsidealen, die komplette Website verhunzen.
Weshalb kam noch nie irgendjemand auf die Idee, das ganze endlich mit in ein CMS zu integrieren. TypoLight geht ja schon mal den ersten Schritt. Ich halte das “kopieren” allerdings nicht für sonderlich sinnvoll, denn hat man mehrere Artikelbereiche und entsprechend auch andere Artikelvorgaben, so müsste sich der Autor jedesmal durch die Liste wühlen und den letzen Artikel einer bestimmten Kategorie heraus suchen. Das ist keine zumutbare Alternative.
Zumal, es müssten einfach ganz klare Benennungen für die Inputs und Textfelder vorhanden sein. Habe ich beispielsweise eine Ausgabe, so wäre es unnötig einen Editor für dieses Feld zur Verfügung zu stellen, lediglich die Bezeichnung und eine Inputrow müssten zu sehen sein.
Schön strukturierte und etwas aufwändiger gestaltete Inhalte müssen also weiterhin auf “Inhaltstemplates”, die in die Editoren geladen werden, zurückgegriffen werden.
Wie blöd. Auch von Entwicklerseite.
Ist es denn so ungewöhnlich das man sich um Typo und Darstellung/Anordnung der Inhalte auch kümmern möchte ? Ich könnte mir das ganze im Typoschema schön vorstellen.
Input: Headline
Input: Autor
Input: Create_date
Input: Article_image ( Upload-Feld)
Textbox: Teaser
Textbox: Article Text
Textbox: Quellverweise / Links / etc.
Der Vorteil würde doch klar auf der Hand liegen. Man könnte den Autoren eine einheitliche Struktur vorgeben, die das einheitliche Aussehen der Webseite und deren Inhalte festlegt. Man hätte wesentlich mehr möglichkeiten, auch umfangreiche Archive Aufzubauen, die Daten nicht in Textform beinhalten. Man hätte verdammt viel mehr Möglichkeiten.
Ben
der Joomlasche :)
Nachtrag:
Das war gerade etwas verwirrt geschrieben ^^
Das mit den TinyMCE Templates ist halt insofern ein Problem, da die Editoren meist kleiner sind als die Anzeigebereiche auf der Seite, das heißt es ist einfach unkonfortabel mit solchen Inhaltstemplates zu arbeiten, auch wenn man die Möglichkeit hat den Browser zu resizen.
Problem hierbei ist auch, das der TinyMCE und auch alle anderen Editoren mit dieser Funktionalität, Divs und Spans beim Backspace ganz gern mal löschen. Heißt ich habe beispielsweise ein für den Autorennamen, so löscht der Autor die Vorgabe “Max Mustermann”, logisch - wenn er allerdings einmal zuviel löscht, dann hat er diesen nicht mehr. Bei umfangreichen Artikeltemplates ist das natürlich problematisch. Angenommen das passiert beim vorletzten Imput-Element, da gehen die Jungs&Mädels an die Decke. Ein paar mal wenn das passiert und niemand möchte mehr mit “Artikeltemplates” arbeiten.
Sinnvoll wäre also auch hier eine Erweiterung der Editoren, die anhand eines Merkmals, welches man einem Element mit auf den Weg gibt, deklarieren, das der Editor selbiges nicht löschen darf.
Anne-Kathrin
Das ist wieder eine andere Geschichte…
Die Leute arbeiten mit Word und auch im Web soll es sein wie Word.
Ich glaube, man muss sich erstmal bewusst machen, wie sehr die ganz normalen Anwender eigentlich schon bei Word gezwungen sind zu pfuschen, mangels besseren Wissens.
Tab, Absatz? Nie gehört! Eine Reihe von Leerzeichen tut es auch.
Dass das Ganze beim Formatieren der Schriftart seinen Zweck nicht mehr erfüllt, das ist kaum mehr plausibel zu machen.
Der ganz normale Anwender klickt und klickt, in der Hoffnung, es passiere schon mal das richtige. Oft wahrscheinlich hilflos. Nicht vergessen dürfen wir ja, dass wir bei einer Website eigentlich in zwei Anwendungen sind: dem Programm “Browser” - wie auch immer der heißen mag, mit seiner Funktionalität und der Anwendung CMS/Website mit ihrer Funktionalität.
Wie die beiden zusammenspielen, lässt sich nicht so leicht verallgemeinern.
Und gleichzeitig fordert man beim Arbeiten mit einem Online Editor Kenntnis um Semantik und das Kredo “sauberes Arbeiten” ein?
Wahrscheinlich erwarten wir zuviel vom User…
der Joomlasche :)
Da bin ich nicht deiner Meinung.
Ist es nicht so, das der User zwangsweise das Bedürfniss hat die Texte “selber zu pimpen”, wenn sich der Webdesigner nicht darum gekümmert hat das die Ausgabe auch gut aussieht ?
Schau dir doch mal viele Seiten an, dort ist “Typo im Web” ein Fremdwort, ebenso wie Artikelformatierungen. Es gibt mittlerweile doch mehr als genügend Lösungen solch einen Artikel-Gau zu verhindern. Jeder Editor lässt sich beschneiden, das ist nicht die Boshaftigkeit, wenn ich einem Kunden keine 35 verschiedenen Formatoptionen im TinyMCE zur Verfügung stelle, sondern Vorsorge.
Es gibt ja tolle Extensions, welche ganz einfach erlauben selbst BB-Code für die Editoren zu integrieren. Wo ist das Problem frage ich mich, dem Kunden ein PDF zur Verfügung zu stellen und zu sagen: “Passen Sie auf, das hier sind Ihre Formatierungsoptionen”. Neben Fettschrift, Italic und Underline - hat der Autor dann eben noch vorgefertigte Möglichkeiten. [hinweis]Dein Text[/hinweis] - könnte so eine sein. Das ganze wird dann flott im Dein Text ausgegeben.
Es gibt ja den schönen Spruch “simplify your Work” - warum das nicht auch auf Editoren anwenden ? Nur weil das Web inzwischen unzählige Optionen mittels Editoren ermöglicht, bedeuted das noch lange nicht das diese auch sinnvoll sind. Ich glaube nämlich das Web verlangt zuviel vom User, nicht wir. Meine Autoren haben einen minimalistischen Editor, der nur Dinge erlaubt, die eben keinen Artikel-Gau produzieren können. Die Grundformatierungen werden eh vom Artikeltemplate gehalten, alle weiteren sind durch speziell an die Bedürfnisse angepasste BB-Code-Optionen. Da hat der Autor ein PDF und kann, sofern er etwas besonders hervorheben möchte, sich den entsprechenden Tag raussuchen. Nach ein paar mal verstehen die meisten das auch ohne auf das Cheatsheet zu schauen.
Jemand der sich nicht einmal mit solchen Optionen zurecht findet, der sollte vielleicht hinterfragen ob es nicht vielleicht sinnvoller wäre, Inhalte vom Professionellen seines Vertrauens pflegen zu lassen. Wenn ich mir keinen Tisch bauen kann, dann geh ich zum Schreiner. Wenn mein Auto kaputt ist, dann fahre ich in die Werkstatt und wenn der Webdesigner es nicht fertig bringt, seinen Kunden in klarer Sprache zu erzählen auf was es ankommt und was der Kunde eventuell selbst machen kann und was wohl besser mit in die Seitenpflege integriert werden sollte, dann hat der oder die gute seinen/Ihren Beruf verfehlt.
Ich bin nach wie vor der Meinung, das jemand mit einer prof. Webseite, seine Inhalte auch professionell einstellen und pflegen lassen sollte. Nur weil es Editoren gibt und die Umwelt einem erzählen möchte das dank Joomla & Co. nun jedes Kind eine Webseite betreiben kann, ist es noch lange nicht wahr.
Aber da rutschen wir wieder in die Endstation: “Frank ist jetzt ein Webdesigner” ab.