Universitätswebsites werden praktisch von allen veröffentlicht. Fakultäten, Fachbereiche, das Zulassungsbüro, Forschungszentren und studentische Dienste stellen alle Seiten online, meist über Dutzende Mitwirkende, deren Hauptaufgabe nicht die Website ist. Ohne einen festgelegten Weg entstehen daraus Tippfehler, markenfremde Seiten, Informationen, deren Rücknahme niemand mehr auf dem Schirm hatte, und gelegentlich taucht etwas Sensibles auf, bevor es jemand mit entsprechender Befugnis überhaupt gelesen hat.
Ein Workflow zur Inhaltsfreigabe gibt jeder Seite denselben Weg an die Öffentlichkeit. Sie beginnt als Entwurf, wartet auf einen benannten Prüfer und geht erst live, sobald dieser Prüfer sie freigibt. Drupal setzt das mit zwei Kernmodulen um, ganz ohne kostenpflichtige Erweiterungen. Dieser Artikel behandelt, wie diese Module zusammenspielen, wie man den Prozess auf die Größe einer Institution zuschneidet, was sich auf mehrsprachigen Websites ändert, und welche Konfigurationsdetails darüber entscheiden, ob eine Prüfwarteschlange in Bewegung bleibt oder still zum Stillstand kommt.
Warum universitäres Publizieren einen Prüfschritt braucht
Eine Universität ist ein großer, dezentraler Herausgeber, und genau diese Kombination macht die redaktionelle Kontrolle schwierig. In jeder Fakultät und jeder Einheit sitzen Mitwirkende mit sehr unterschiedlichem Grad an Web-Schulung, während die zentrale Kommunikationsabteilung und die IT weiterhin für Genauigkeit, Markenkonformität, Barrierefreiheit sowie – bei Zulassungs- oder Richtlinienseiten – für rechtliche und reputationsbezogene Risiken verantwortlich bleiben.
Die Institutionen, die die größten Drupal-Bestände im Hochschulwesen betreiben, sind genau um dieses Problem herum aufgebaut. Harvard, Yale, Stanford und Duke betreiben jeweils eine namentlich benannte institutionelle Drupal-Plattform, in die Fachbereiche und Forschungsgruppen einspeisen, statt eine Streuung unzusammenhängender Websites zu pflegen, und Harvards eigene Plattformdokumentation führt Inhaltsveröffentlichung und Benutzerverwaltung gleichrangig als Kernfunktionen auf. Sobald Hunderte Einheiten sich eine Plattform teilen, hört die Entscheidung darüber, wer veröffentlichen darf, auf, eine Kleinigkeit zu sein, und wird zur zentralen Governance-Frage der Plattform.
Der Sinn dahinter ist nicht, Mitwirkende auszubremsen. Es geht darum, einer Fakultätsautorin oder einem Fakultätsautor, die oder der zum ersten Mal schreibt, freies Verfassen zu ermöglichen, während eine geschulte Person bestätigt, dass die Seite den Standards entspricht, bevor sie jemand außerhalb der Institution zu Gesicht bekommt.
Wie es funktioniert: Workflows und Content Moderation
Standardmäßig kennt eine Drupal-Seite zwei Zustände, veröffentlicht oder unveröffentlicht, was nicht ausreicht, um einen Prüfprozess abzubilden. Zwei Kernmodule erweitern das.
Workflows definiert die Zustände, die Inhalte einnehmen können, und die Übergänge zwischen ihnen. Es ist die abstrakte Form Ihres Prozesses und nicht mehr als das. Für sich allein tut es überhaupt nichts, und installiert man es allein, erscheint ein Bildschirm, der mitteilt, dass keine Workflow-Typen verfügbar sind.
Content Moderation liefert diesen Workflow-Typ. Es verknüpft den Workflow mit realen Inhalten, etwa bestimmten Inhaltstypen, und bindet jeden Übergang an eine eigene Berechtigung, sodass nur die vorgesehenen Rollen eine Seite weiterbewegen können.
Beide sind Kernmodule, und ihre Stabilisierungsgeschichte lohnt sich zu kennen, weil sie oft ungenau wiedergegeben wird. Content Moderation kam in Drupal 8.2 als experimentelles Modul in den Kern, Workflows folgte in 8.3. Workflows wurde in 8.4 als stabil eingestuft, während Content Moderation noch im Beta-Status war, und Content Moderation erreichte den stabilen Status in Drupal 8.5.0. Content Moderation setzt Drupal 8.4 oder neuer voraus. In Drupal 10 und 11 sind beide schlicht Teil des Kerns und werden über die Seite „Erweitern" aktiviert. Die offizielle Content-Moderation-Dokumentation führt durch die Einrichtung.
Zustände, Übergänge und die Berechtigungen, die sie durchsetzen
Drei Konzepte liegen jedem Drupal-Workflow zugrunde. Zustände (States) sind die Bedingungen, die Inhalte einnehmen können. Übergänge (Transitions) sind die erlaubten Bewegungen zwischen ihnen, und sie sind gerichtet, sodass eine Seite nicht von „Entwurf" direkt zu „Archiviert" springen kann, sofern Sie das nicht ausdrücklich zulassen. Revisionen bilden die versionierte Historie darunter. Drupal unterstützt ausstehende Revisionen (pending revisions), das heißt, ein Redakteur kann eine neue Version einer bereits live geschalteten Seite vorbereiten, ohne dass etwas davon öffentlich sichtbar wird, bis sie freigegeben ist.
Berechtigungen sind das, was daraus ein echtes Steuerungsinstrument macht und nicht nur ein Diagramm. Drupal erstellt für jeden Übergang eine eigene Berechtigung, sodass das Recht, den Übergang „Veröffentlichen" zu nutzen, an Prüfer vergeben und Mitwirkenden vorenthalten werden kann. Genau dieser eine Mechanismus bildet die gesamte Freigabekette.
Das Aktivieren von Content Moderation erzeugt einen standardmäßigen Editorial-Workflow mit den Zuständen Entwurf, Veröffentlicht und Archiviert. Ein Detail bringt viele ins Straucheln: Dieser Standard-Workflow wird nur dann automatisch erstellt, wenn die Website aus dem Standard-Installationsprofil installiert wurde. Bei einem minimalen oder benutzerdefinierten Profil müssen Sie ihn selbst aufbauen.
Ein praxistauglicher Zustandssatz für Universitäten erweitert den Standard meist geringfügig.
| Zustand | Bedeutung | Übergeht in diesen Zustand durch |
|---|---|---|
| Entwurf | Wird verfasst oder überarbeitet, für die Öffentlichkeit nicht sichtbar | Jeder Mitwirkende |
| Zur Prüfung | Eingereicht und wartet auf einen Prüfer | Jeder Mitwirkende |
| Überarbeitung nötig | Mit Feedback an den Autor zurückgegeben | Prüfer |
| Veröffentlicht | Live auf der Website | Prüfer und Administratoren |
| Archiviert | Von der Website genommen, aber aufbewahrt | Administratoren |
Eine Konsequenz des Standard-Workflows überrascht die meisten neuen Redakteure: Es gibt keinen Button zum Depublizieren. Um eine live geschaltete Seite offline zu nehmen, setzen Sie die veröffentlichte Revision auf „Archiviert".
Den Workflow auf die Universität zuschneiden
In der Praxis bildet eine Universität dies auf eine kleine Rollenmenge ab, nicht auf eine große.
| Rolle | Was sie tun kann | Üblicherweise innegehabt von |
|---|---|---|
| Mitwirkender | Entwürfe erstellen und bearbeiten, Inhalte zur Prüfung einreichen. Kein Übergang zum Veröffentlichen. | Mitarbeitende von Fakultäten und Fachbereichen |
| Prüfer | Inhalte prüfen, bearbeiten, veröffentlichen oder zurückgeben. Benötigt Berechtigung zum Ansehen unveröffentlichter und der jeweils neuesten Version. | Geschulte Redakteure der Fakultät oder zentrales Web-Team |
| Administrator | Alles, was ein Prüfer kann, plus Rollenzuweisung und Konfiguration der Workflows. | Zentrale IT oder Kommunikationsabteilung |
Das leitende Prinzip ist das der minimalen Rechtevergabe. Wer Kursseiten pflegt, braucht keine Website-Konfiguration oder Benutzerverwaltung, und diese Rolle eng zu halten schützt die Plattform als Ganzes.
Drupal erlaubt mehrere Workflows auf einer Website, jeweils angewendet auf unterschiedliche Inhaltstypen, und genau hier wird das Modell im universitären Maßstab wirklich nützlich. Gewöhnliche Fachbereichsseiten nehmen den kurzen Weg. Zulassungsordnungen, Pressemitteilungen und rechtliche Hinweise durchlaufen dagegen einen zusätzlichen Freigabezustand, den gewöhnliche Seiten überspringen. Sie wenden so viel Aufsicht an, wie jede Art von Inhalt tatsächlich rechtfertigt, statt alles durch denselben Prozess zu zwingen.
Dies ist das redaktionelle Gegenstück zur architektonischen Governance, und bei großen Beständen arbeiten beide zusammen. Unser Leitfaden zur Verwaltung von Universitätswebsites mit Drupal Multisite behandelt die architektonische Hälfte.
Mehrsprachige Websites: jede Übersetzung separat prüfen
Drupal 8.5 fügte die Unterstützung für unabhängig moderierte Übersetzungen hinzu, und auf einer zweisprachigen Universitätswebsite verändert das die Form des Prozesses.
Jede Übersetzung trägt ihren eigenen Moderationszustand. Die englische Version einer Seite kann live sein, während eine andere Sprache noch in Prüfung ist, oder umgekehrt. Das ist wichtig, weil ein einzelner Prüfer selten die Sprachkompetenz besitzt, um jede Version freizugeben, und ein Prüfer, der Inhalte freigibt, die er nicht vollständig lesen kann, liefert eher einen Formalabschluss als eine echte Kontrolle.
Klären Sie die Sprachzuständigkeit, bevor Sie irgendetwas konfigurieren. Legen Sie fest, wer welche Sprache prüft, und entscheiden Sie, was Besucher sehen sollen, wenn eine Übersetzung freigegeben ist und eine andere nicht. Unabhängige Moderation bedeutet, dass eine Seite in einer Sprache legitim live sein und in einer anderen fehlen kann, also stellen Sie sicher, dass das Fallback-Verhalten dem entspricht, was Sie beabsichtigen.
Konfigurationsdetails, die eine Prüfwarteschlange zum Stillstand bringen
Die meisten Freigabe-Workflows, die scheitern, scheitern nicht am Design. Sie scheitern an kleinen Konfigurationsdetails, die die Warteschlange unsichtbar oder unbrauchbar machen.
- Prüfer können nicht sehen, was sie prüfen sollen. Übergangsberechtigungen allein reichen nicht aus. Prüfer benötigen zusätzlich die Berechtigung, die jeweils neueste Version anzusehen und beliebige unveröffentlichte Inhalte einzusehen. Fehlen diese, wirkt die Prüfwarteschlange schlicht leer.
- Entwürfe stapeln sich und werden gemeinsam veröffentlicht. Entwurfsrevisionen sind kumulativ, jede baut also auf der vorherigen auf, statt eigenständig zu sein. Wenn mehrere Personen Entwürfe derselben Seite speichern, bevor jemand sie prüft, gibt die Veröffentlichung nicht eine dieser Änderungen frei. Sie gibt alle auf einmal frei, was auf einer Seite mit mehr als einem Autor leicht übersehen wird.
- Inhalte können nicht direkt in die Prüfung springen. Übergänge sind gerichtet, sodass ein Mitwirkender, der eine live geschaltete Seite aktualisiert, sie zunächst als Entwurf speichern und erst danach einreichen muss, sofern Sie nicht explizit einen Übergang von „Veröffentlicht" zu Ihrem Prüfzustand definiert haben. Dieser Übergang wird leicht vergessen, wenn der Workflow eher um neue Seiten herum gestaltet ist als um Bearbeitungen bestehender.
- Niemand weiß, dass er oder sie an der Reihe ist. Bleibt es der manuellen Kontrolle überlassen, verharrt Inhalt in der Prüfung, weil niemand seine Ankunft bemerkt hat. Content Moderation Notifications versendet eine E-Mail an eine gewählte Rolle oder den Autor des Inhalts, sobald ein Element zwischen Zuständen wechselt, und wird unter /admin/config/workflow/notifications konfiguriert. Ein Dashboard, das alles auflistet, was sich gerade in der Pipeline befindet, deckt den Rest ab.
- Prüfer müssen sich trotzdem einloggen. Drupal zeigt unveröffentlichte Revisionen nur authentifizierten Benutzern mit den richtigen Berechtigungen, sodass ein Workflow, der darauf setzt, dass ein beschäftigter Dekan beiläufig auf eine Seite blickt, nicht so funktioniert, wie er gedacht war.
Wann sich ein Freigabe-Workflow nicht lohnt
Moderation existiert, um die Personen, die Inhalte erstellen, von den Personen zu trennen, die sie freigeben. Wo dies dieselben Personen sind, erzeugt sie Reibung, ohne zusätzliche Aufsicht zu bringen.
Eine Website, die von einem oder zwei vertrauenswürdigen Redakteuren betrieben wird, die alle über Veröffentlichungsrechte verfügen, braucht keinen Workflow, denn die eigene Arbeit durch die eigene Warteschlange zu leiten, verlangsamt das Veröffentlichen ohne jeden Nutzen. Ein Workflow wird auch dann zur Belastung, wenn die Kette länger ist, als die Institution personell abdecken kann. Muss eine Seite mehrere ausgelastete Genehmiger passieren, verwandelt sich die Warteschlange in einen Flaschenhals, und Mitwirkende beginnen, Wege daran vorbei zu finden — was der Institution am Ende weniger Kontrolle lässt, als sie vorher hatte.
Der Rat, der sich in großen Institutionen bewährt, lautet, die Moderation so einfach zu halten, wie es das tatsächliche Risiko rechtfertigt. Beginnen Sie mit den Zuständen, die Sie wirklich brauchen, und fügen Sie einen neuen erst hinzu, wenn ein echter redaktioneller Bedarf entsteht, statt Prozess um des Prozesses willen aufzubauen. Ein Workflow, um den Leute herumnavigieren, ist schlechter als gar kein Workflow.
Zwei Grenzen sollte man kennen, bevor man sich festlegt. Moderation gilt nur für revisionierbare Entitäten, was Nodes, benutzerdefinierte Block-Typen und Taxonomiebegriffe abdeckt, aber nicht alles auf einer Website. Und die Plattformentscheidung liegt all dem zugrunde; falls diese noch offen ist, behandelt unser Vergleich von Drupal und WordPress für Universitäten, wo jedes von beiden passt.
Mit dieser Disziplin konfiguriert, hört die Inhaltsfreigabe auf, eine zusätzliche Ebene zu sein, und wird Teil der Funktionsweise der Plattform. Fakultäten und Fachbereiche tragen breit bei, und eine verlässliche Kontrolle steht vor allem, was die Öffentlichkeit erreicht. Bei Drupart baut das Drupal4edu-Team Drupal-Plattformen für Universitäten wie die Sabancı-Universität, die METU und die Yıldız Technical University, bei denen die redaktionelle Freigabe auf demselben hier beschriebenen Kernfundament ruht. Unser Überblick zu Drupal im Bildungsbereich geht näher darauf ein, warum dieses Fundament für das Hochschulwesen passt.
Häufig gestellte Fragen zur Drupal-Inhaltsmoderation
Ist Content Moderation Teil des Drupal-Kerns?
Ja. Workflows und Content Moderation sind beide Kernmodule, die über die Seite „Erweitern" aktiviert werden, ohne dass etwas gekauft oder heruntergeladen werden muss. Workflows wurde in Drupal 8.4 als stabil eingestuft, Content Moderation in 8.5.0, und Content Moderation setzt Drupal 8.4 oder neuer voraus. Optionale Extras wie E-Mail-Benachrichtigungen und Moderations-Dashboards stammen aus contributed Modulen, doch die Freigabemechanik selbst ist fest in Drupal eingebaut.
Was ist der Unterschied zwischen einem Zustand und einem Übergang?
Ein Zustand ist eine Bedingung, in der sich Inhalt befinden kann, etwa Entwurf, Zur Prüfung, Veröffentlicht oder Archiviert. Ein Übergang ist eine erlaubte Bewegung von einem Zustand in einen anderen, etwa Veröffentlichen oder Archivieren. Diese Unterscheidung ist wichtig, weil Berechtigungen an Übergänge geknüpft sind, nicht an Zustände. Sie steuern, wer eine Seite voranbringen kann, indem Sie jeden Übergang gewähren oder verweigern; Zustände beschreiben also, wo sich Inhalt gerade befindet, und Übergänge definieren, wie — und durch wen — er den nächsten Schritt erreicht.
Können unterschiedliche Inhaltstypen unterschiedliche Workflows nutzen?
Ja, und auf einer Universitätswebsite ist dies eine der nützlichsten Konfigurationsmöglichkeiten. Sie können mehrere Workflows anlegen und jeden auf unterschiedliche Inhaltstypen anwenden. Eine Nachricht eines Fachbereichs könnte einen einfachen Weg von Entwurf zu Veröffentlicht nehmen, während eine Zulassungsordnung einen zusätzlichen Freigabezustand durchläuft. Jeder Inhaltstyp trägt dann nur so viel Aufsicht, wie er tatsächlich braucht.
Wie depubliziere ich eine Seite, wenn die Moderation aktiviert ist?
Im Standard-Editorial-Workflow gibt es keine separate Depublizieren-Aktion. Stattdessen setzen Sie die veröffentlichte Revision auf den Zustand Archiviert, wodurch die Seite von der öffentlichen Website entfernt wird, während ihre Revisionshistorie erhalten bleibt. Redakteure, die einen einfachen Veröffentlicht-Schalter gewohnt sind, brauchen diesen Hinweis meist nur einmal, danach wird es Routine.
Woher wissen Prüfer, dass etwas auf sie wartet?
Über Content Moderation Notifications, ein contributed Modul, das eine E-Mail versendet, wenn Inhalt zwischen Zuständen wechselt. Es kann alle benachrichtigen, die eine Prüfer-Rolle innehaben, oder den Autor des Inhalts, wird unter /admin/config/workflow/notifications konfiguriert und arbeitet zusammen mit der Kern-Content-Moderation. Kombiniert mit einem Dashboard, das alles anzeigt, was sich gerade in der Pipeline befindet, verhindert es, dass Inhalt unbemerkt in der Prüfung liegen bleibt.