CMS mal wieder gehackt? Keine Lust mehr ... jetzt wechsel ich das CMS ... hm aber die Datenbank und meine Posts sind total vollgemüllt. Naja, erstmal das Backup einspielen ... oh nein, das letzte Backup war unvollständig ... Wer dieses Problem kennt, bekommt in dieser Anleitung aus Nutzersicht (use case) eine charmante Variante vorgestellt, Inhalte bewusst aus der Datenbank fern zu halten und Kollaboration über Plattformen und Tools hinweg zu ermöglichen.
Manfred ist wissenschaftlicher Mitarbeiter in einem OER-Projekt. Er erstellt freie OER-Schulungsmaterialien für Schulen und Hochschulen in verschiedenen Formaten. Die Aktualisierung des Materialbestands (Internetseite, PDF, Office Dokumente und Repositorien) konnte in seinem kleinen Team zeitlich kaum aufgefangen werden. Er sucht nun nach einer Möglichkeit kollaborativ, formatübergreifend und effektiv mit seinen KollegInnen an den Dokumenten zu arbeiten.
Manfred benötigt für dieses Unterfangen einen zentralen Dateiverwaltungsdienst (filehosting), der über eine Programmierschnittstelle (API) ansprechbar ist und ein Versionierungssystem (wie z.B. git) unterstützt. Für die kontinuierliche Veröffentlichung und Darstellung der Materialien im Web bietet sich ein erweiterbares Blogsystem wie WordPress an. Für die Erstellung und den automatischen Abgleich der Materialien wird eine einfache und schnell erlernbare Auszeichnungssprache wie Markdown benötigt. Für die Umwandlung in weitere dokumentbasierte Dateiformate wie OpenOffice und PDF wird ein Parser für Multidokumentenformate wie Pandoc Einsatz finden.
Digital Publishing ist mittlerweile nicht nur für Verlage oder Agenturen ein täglicher Bestandteil; auch im wissenschaftlichen und schulischen Umfeld gehören digitale Publikationen zum Alltag. Umso wichtiger wird es, die Bestände feinsäuberlich zentralisiert zu lagern, zu verwalten und zeiteffizient auf einem aktuellen Stand zu halten. Teilautomatisierung spielt bei dieser Toolchain eine tragende Rolle und kann für viele mediale Produkte und sogar für die Kommunikation im Team ein zunehmend positiver Koeffizient sein.
Tipp: Alle Beiträge des Blogs openlab.blogs.uni-hamburg.de sind mit dieser Toolchain entstanden und werden damit verwaltet.
Damit Dokumente von mehreren Personen kollaborativ genutzt werden können, wird ein Dateiverwaltungsdienst benötigt. Je nach Anwendungsfall oder Organisation steht zu Beginn die Entscheidung an, ob der Dienst selbst gehostet oder online bei einem Anbieter gemietet werden soll. Im Nutzungsszenario von OER bietet sich ein sogenanntes öffentliches Repositorium an, das bei den Online-Anbietern GitLab.com und GitHub.com kostenlos und nur mit einer nennenswerten Klausel behaftet ist – alles ist immer öffentlich und darf auch genutzt (fork) werden.
Manfred Steger, "GitLab OpenLab Overview" CC0
Diese Toolchain bezieht sich auf GitLab.com, da dieser Anbieter seine Software auch als open source software zur Verfügung stellt. Für kleine Teams und im privaten Bereich kann GitLab sogar mit einem Minicomputer, wie z.B. dem RaspberryPi 3, für weniger als 50 Euro selbst zusammengestellt werden.
Der erste Schritt ist es, ein öffentliches Repositorium, folglich kurz Repo genannt, bei GitLab.com anzulegen.
Kleinteilige Schritte und Anleitungen können aus der Workshop Dokumentation: Einführung, Teamkommunikation und -kollaboration in GitLab entnommen werden.
uebung-macht-den-meister
.Nach dem Erstellungsvorgang erscheint ein leeres Repo.
Damit das Repo genutzt werden kann, muss mindestens eine Datei erstellt werden. Auf der Startseite des Repos wird automatisch die Datei README.md
visuell dargestellt. Wie dies funktiontiert, erfahrt ihr in den nächsten Schritten.
Overview
und wählt dort den Button New file
aus.README.md
ein.Commit changes
ab.GitLab bzw. die Technologie git protokolliert und speichert Änderungen im Repositorium ab und behält diese vorsorglich. Die sog. history wird im Sidebar-Menü > Repository > Commits
dargestellt. Der Unterschied zu einer normalen Dateiverwaltung ist die Möglichkeit, Änderungen über einen langen Zeitraum hinweg zu überblicken und gegebenenfalls auf einen vorherigen Zeitpunkt zurückzudrehen – im Prinzip wie eine Zeitmaschine. Damit diese Möglichkeit effektiv genutzt werden kann, sollten keine Dateien direkt auf der GitLab-Website hochgeladen werden. Im nächsten Schritt erfahrt ihr nun, wie ein Repo auf den lokalen Computer geklont, synchronisiert und im Team kollaborativ genutzt werden kann.
Eine verteilte Versionsverwaltung überwacht Dateiänderungen an unterschiedlichen Orten und synchronisiert diese bei Bedarf bidirektional (in beide Richtungen). Bei nicht-binären Dateien (reine Textdateien – keine Office Dokumente) ist es sogar möglich, Änderungen an der selben Datei zu erkennen und diese automatisch zusammenzuführen. Für diesen Vorgang wird ein git-fähiges Programm benötigt.
Hauptmenü > File > Clone Repository
.URL
aus.Sidebar Menü auf Overview
aus. Kopiert den HTTPS-Link
. Anstelle von HTTPS
kann auch SSH
stehen, in diesem Fall SSH
anklicken und im Drop-down-Menü HTTPS
auswählen.URL or username/repository
.Clone
.Der Vorteil von GitHub Desktop besteht darin, dass alle Inhalte im geklonten Ordner automatisch überwacht werden. Sobald sich etwas an einer Datei ändert, neue Dateien hinzukommen oder Dateien gelöscht bzw. verschoben werden, merkt sich die git-Technologie diese Veränderung. Bei reinen Textdateien werden lediglich die veränderten Passagen vermerkt und abgespeichert. In den folgenden Schritten werden wir nun den Synchronisierungsvorgang exemplarisch durchführen.
Tipp: Ein einfaches Beispiel zeigt den Mehrwert dieser Technologie. Ein von uns geschriebener Artikel wurde während seiner Entstehung 100 Mal abgespeichert und bei jedem Speichervorgang synchronisiert. Auf GitLab gibt es in der history 101 commits, wobei wir jeden Speicherpunkt nachträglich ansehen können. Würden wir dasselbe mit einem binären Format, wie z.B. einem Office Dokument (.odt oder .docx) machen, lägen 101 Dokumente auf dem Server und die history könnte die jeweiligen Textänderungen nicht darstellen. Ein weiterer Nachteil wäre die entstandene Dateimenge, die bei einem 2-Megabyte-großen Office Dokument insgesamt 404 Megabyte auf der Festplatte ausmachen würde. Die abgespeicherten Versionen/Referenzen einer Textdatei sind weitaus kleiner und liegen bei 101 Speichervorgängen unter 1 Megabyte.
README.md
..md
bleibt und nicht zum Beispiel .docx daraus gemacht wird.Menü > Changes
wird nun die Datei README.md
angezeigt.Menü > Changes
. Nun wird euch die Textdatei im rechten Fenster angezeigt und die Änderungen mit grüner und roter Hinterlegung hervorgehoben.Summary
und tragt dort eine kurze Zusammenfassung ein. Diese wird beim Synchronisierungsvorgang mitgesendet und wird euch später in der history als Titel angezeigt.Commit to master
.Fetch origin
zu Push origin
. Klickt nun auf Push origin
, um die Synchronisierung zu starten.Tipp: Zu jedem Arbeitsbeginn empfiehlt es sich, GitHub Desktop zu öffnen und den Button
Fetch origin
zu klicken. Alle Änderungen aus dem Online-Repositorium werden dann mit dem lokalen Ordner abgeglichen. Zudem sollten Änderungen nicht zu lange (Tage) lokal verändert liegen bleiben, da das Risiko größer wird, dass die Datei von z.B. einem anderen Nutzer verändert wird. Synchronisiert also in regelmäßigen Abständen; somit entsteht eine feinsäuberliche Dokumentation der erledigten Arbeit bzw. Teilarbeit.
Ein Dokument hat mittlerweile viele Gesichter – es kann als gedruckter Artikel in einer Zeitschrift, als Blogbeitrag in einem Online-Magazin, in einem Sammelband als Buch bzw. im EPUB-Format auf unterschiedlichen digitalen Endgeräten dem Nutzenden zur Verfügung stehen. Unterschiedliche Ausgabemedien erfordern mehrere unterschiedliche Dokumenttypen bzw. Formate – viele Dokumente bedeuten mehr Arbeitsaufwand beim Erstellen bzw. Abgleichen. In diesem Abschnitt wird gezeigt, wie ein zentrales Dokument mit einer einheitlichen Auszeichnungssprache für mehrere Anwendungszwecke genutzt werden kann, damit redundante Inhalte nicht entstehen und somit die Effiktivität erhöht wird und sich zugleich Fehler beim Abgleichen auf ein Minimum reduzieren lassen.
Ein zentrales Dokument ist der Ausgangspunkt für das digitale crossmedia publishing und eine einfache Auszeichnungssprache der Schlüssel zum Erfolg. Bereits beim Einrichtes des GitLab-Repo haben wir eine solche Datei mit der passenden Sprache angelegt: die README.md
. Die Dateiendung .md
steht für Markdown
, eine Auszeichnungssprache, die während des Formatierens bereits 'menschenlesbar' gestaltet ist. Eine ausführliche Erklärung erhalten Sie in der Workshop Dokumentation: Markdown – Ein Format für Vieles. In diesem Abschnitt erlernt ihr die wichtigsten Befehle und den Abgleich mit GitLab.
Die wichtigsten Markdown-Befehle im Überblick
Markdown Befehl | Ergebnis |
---|---|
# Überschrift 1 | Überschrift 1 |
## Überschrift 2 | Überschrift 2 |
### Überschrift 3 | Überschrift 3 |
*Kursiv Auszeichnung* | Kursivauszeichnung |
**Fett Auszeichnung** | Fett Auszeichnung |
- Listenelement unsortiert | • Listenelement unsortiert |
1. Listenelement sortiert | 1. Listenelement sortiert |
Tipp: In diesem Online Tutorial von CommonMark.org können die wichtigsten Markdown-Befehle als SOL (selbstorganisierte Lerneinheit) in wenigen Minuten interaktiv erlernt werden.
Tipp: Eine gute Übersicht aller Markdown-Befehle findet ihr über die nutzerfreundliche Suchmaschine Duckduckgo.com. Gebt als Suchbegriffe
markdown cheatsheet
ein. Es wird direkt eine Übersicht eingeblendet, die über den Buttonshow more
erweitert werden kann.
master
auf das Pluszeichen > New file
.File name
den gewünschten Dokumentnamen mit der Endung .md
ein.commit message
eine kurze Beschreibung ein, wie z.B. Artikel digital publishing angelegt
.Commit changes
.Fetch origin
.Der Online-Editor sollte nur in Ausnahmefällen benutzt werden, z.B. wenn ein Fremdgerät genutzt wird. Generell sollten lokale Dateien im Repo mit funktionstüchtigen Offline-Editoren bearbeitet werden.
In dieser Liste finden Sie unterschiedliche OpenSource (kostenlose) Markdown-fähige Programme:
Damit weitere Personen am gleichen Artikel schreiben oder z.B. parallel Medieninhalte wie Bilder einfügen können, müssen diese dem Projekt hinzugefügt werden.
Select members to invite
.Choose a role permission
die Berechtigkeitseinstufung vor. Eine detaillierte Übersicht der unterschiedlichen Berechtigungen und deren Auswirkungen befindet sich in der offiziellen GitLab.com Dokumentation.Developer
aus; für eine einfache Zusammenarbeit auf Augenhöhe (gleiche Rechte) wählt die Rolle Master
(empfohlen) aus. Diese Einstellung ist für den textbasierten wissenschaftlichen Handlungsalltag und zur Reduzierung der Komplexizität für GitLab-Neulinge zielführend. Im IT-Bereich wäre diese laissez-faire Rollenvergabe undenkbar.Add to project
.KollegInnen und auch die Öffentlichkeit können somit am Projekt teilhaben. Je nach Berechtigungsstufe können sie das Repo herunterladen, Änderungen einreichen, Teammitglieder und Aufgaben verwalten.
Tipp: Wer völlig neu im GitLab-Universum ist, sollte zunächst allein Erfahrungen sammeln und danach mit wenigen vertrauten Mitgliedern Rechte und Rollen erproben. Achtet besonders bei unbekannten Mitgliedsanfragen auf die Rechtevergabe und wählt bei Ungewissheit die Rolle
Reporter
.Tipp: Erklärt neuen Mitgliedern die Verfahrensweise, wie bereits im Kapitel Dateien verwalten aka verteilte Versionsverwaltung dargestellt ist. Dies fördert das eigene Verständnis, da bei Rückfragen das eigene Handeln betrachtet, erneut überdacht und mit eigenen Worten erklärt werden muss.
Vor Beginn des folgenden Abschnitts stellt sich erst einmal die Frage: Was unterscheidet das erstellte Dokument im GitLab.com-Repo von einem Online-Artikel?
Darstellungsform / Gestaltung
Auszeichnungssprachen legen die Struktur eines Dokuments fest, jedoch nicht das endgültige Aussehen. Die Darstellung der Inhalte auf der GitLab.com-Plattform ist für Arbeitsformen optimiert und nicht für den Endnutzer eines Artikel, den Leser, bestimmt. Für die verbesserte Anzeige des Artikels aus Nutzendensicht (usability) wird ein Redaktionssystem mit Gestaltungsvorlagen zum Einsatz kommen. Wir haben uns in diesem Szenario für das Blogsystem WordPress entschieden.
Tipp: Wer bereits über Fortgeschrittenen- oder Expertenwissen im Bereich Content-Management-Systeme besitzt, sollte als mögliches Front- und Backend Grav CMS in Betracht ziehen, da es einige Synergieeffekte in Zusammenhang mit GitLab aufweist.
Die Erstellung und Einrichtung eines WordPress-Blogs wird hier nicht weiter erklärt. In unserer WordPress-Workshop-Dokumentation findet ihr einige wichtige Hinweise dazu. Die Grundvoraussetzung für das weitere Vorgehen ist eine eigene WordPress-Installation (kostenlos) von WordPress.org auf einem Webspace / lokalem Webserver oder ein business subscription plan (kostenplichtig) von WordPres.com, da wir third party plugins für die Kommunikation zwischen WordPress und GitLab benötigen.
Clone or download
von GitHub.com herunter. Mit dieser WordPress-Erweiterung können Markdown-Dateien im sogenannten raw Auslieferungszustand in WordPress-Artikel eingebettet werden.Sidebar-Menü > Plugins > Installieren > Plugin hochladen
.Sidebar-Menü > Plugins > Installieren > Plugin hochladen
.Sidebar-Menü > Einstellungen > Schreiben
und setzt den Haken bei der Checkbox Markdown für Beiträge und Kommentare verwenden.
Sidebar-Menü > Beiträge > Erstellen
einen neuen Artikel.OER – Digital Publishing mit Git und WordPress
.[embed_markdown url=""]
Open Raw
; dieser befindet sich an fünfter Stelle von rechts neben dem roten delete
-Button."URL"
die GitLab Raw URL ein.[embed_markdown url="https://gitlab.com/manfredsteger/digital-publishing-openlab/raw/master/digital-publishing.md"]
Veröffentlichen
.Casus Knacksus Datenbank
Der Artikel steht nun im Frontend (Besucheransicht) bereit. Die Toolchain, für einen möglichen digital Publikationsprozess, ist damit abgeschlossen. Für sich betrachtet ein erheblicher Aufwand für das Erstellen eines einfachen blog post. Unter Berücksichtigung weiterer Faktoren nähern wir uns jedoch schnell dem break even an. Die größte Rolle spielt dabei die WordPress Datenbank, die neben Inhalte, eben auch essenzielle Systeminformationen speichert. Im Falle eines defekts oder eines Hackerangriffs ist das ganze System betroffen (z.B. SQL-Injection) und oftmals nur durch eine komplette Neuinstallation des Systems oder der Datenbank zu beheben. Ohne Backup sind die Daten meist verloren oder nur mit kostenintensiven Bereinigungsprozessen durch Fachpersonal wiederherzustellen.
Das Datenbank Dilemma
Moderne Schadsoftware schreibt nicht nur schädlichen Code in Systemdateien und installiert Skripte, die z.B. für Phishing Zwecke fungieren, sondern verunreinigen auch Inhalte aller posts mit Links und Textpassagen. Fachpersonal kann Schadsoftware anhand der Code-Signatur erkennen, jedoch nicht kontextualisiert feststellen, ob der Text eines Beitrags gewünscht oder verunreinigt ist. Tritt dieser Fall ein, müssen alle Inhalte erneut durchforstet und neu aufbereitet werden.
Bei dieser Toolchain wäre der schlimmste Fall, dass das System neu aufgesetzt und die einzelnen Posts mit Titel und Embed Code neu eingestellt werden müssen. Die Inhalte sind extern gehostet und demnach vor Veränderungen gesichert.
In der voranschreitenden digitalen Welt ist Sicherheit ein zunehmender Faktor. Daher die Entscheidung im Zwischenfazit mit einem Negativbeispiel zu starten.
Seriell vs simultan
Meines Erachtens viel wichtiger als negative Randeffekte sind die neuen Möglichkeiten und Formen der Zusammenarbeiten, die mit dieser Toolchain entstehen. Kollaboration ist mit WordPress möglich. Das Redaktionssystem gewährt mit hierarchischer Rollen- und Rechtevergabe Person A das Schreiben eines Artikels, der anschließend von Person B redaktionell begleitet und danach von Person C zurückgewiesen oder veröffentlicht wird. Dieser serielle Arbeitsprozess birgt große Schwachstellen, da erst nach Vollendung eines Arbeitsschrittes der nächste folgen kann. Wie ist nun aber der Unterschied zur Toolchain mit GitLab?
Person A schreibt an einem Artikel im lokalen Repo und synchronosiert in kurzen Zeitabständen die Inhalte. Während Person A gerade eben schreibt, kann Person B simultan z.B. ein Lektorat vornehmen. Person B speichert die Änderungen ab und synchronisiert die Änderungen mit GitLab. Speichert und synchronisiert nun Person A die Änderungen zeigt z.B. GitHub Desktop an, dass neue Änderungen im Repo vorhanden sind. Die Änderungen von Person B werden in die aktuelle Version übernommen, ein sog. merge
. Im Idealfall muss Person A die zusammengeführten Änderungen in GitHub Desktop mit einem commit
ins online Repositorium übertragen. Wurde hingegen ein und dieselbe Textzeile von beiden Personen gleichzeitig geändert, kann das System nicht entscheiden, welche Version nun die Richtige ist. In diesem Fall wird ein merge conflict
angezeigt. Dieser Fehler kann nur manuell behoben werden.
Volle Transparenz und Nachvollziehbarkeit
Betrachtet man nun die beiden Arbeitsweisen wird deutlich, dass mit der Toolchain eine neue Form der Kollaboration zustande kommt. Für redaktionelle Zwecke gibt es noch einen weiteren Vorteil. Jeder commit wird in der history in GitLab gespeichert. Wird bei einer Textdatei etwas verändert, speichert git die Veränderungen ab und eben nicht ein neues Dokument. Diese Veränderungen werden systematisch gespeichert und können nachträglich mit vorherigen Varianten verglichen werden, die sog. Blame-Funktion. Diese Funktion kann bei jeder Datei im online Repo über den Button: Blame
aktiviert oder in GitHub Desktop unter dem Reiter: History
für den jeweils zuvor gespeicherten Stand angezeigt werden. WordPress bietet diese Funktionen mittlerweile auch, die sog. Revisionen
. Nachteil der WordPress Versionen besteht jedoch darin, dass die Datenbank mit jedem Speicherpunkt wächst. Sowohl bei WordPress als auch bei GitLab besteht die Möglichkeit im Nachhinein alte Versionen aufzurufen und daraüberhinaus auch einzusehen, wer hat diese Änderungen gemacht.
Ein einfaches Beispiel zeigt welche Möglichkeiten und Vorteile dieses Verfahren beinhaltet. Person A, B, C und D
schreiben gemeinsam an einem Zeitschriften Artikel. Es steht ein Lektorat von LektorIn A
an. Die LektorIn findet eine widersprüchliche Aussage in Textzeile 340 und weiß nicht, ob diese beabsichtigt ist. Die LektorIn hat eine zusammengeführtes Office Dokument erhalten, bei dem nicht ersichtlich wird, wer für welchen Absatz verantwortlich ist. Sie verfasst eine E-Mail an alle beteiligten Personen, die nun folgendes tun:
allen antworten
Person A und C sowie LektorIn A eine E-Mail, dass Person B dafür verantwortlich sei.allen antworten
, dass sie nun auf die Rückmeldung von Person C warten wird.Über die history Funktion wird die Kommunikation automatisch geschrieben und im oben dargestellten Beispiel könnte die LektorIn A zurückblättern, bis die betroffene Stelle erscheint und selbstständig nachvollziehen wer dafür verantwortlich ist.
Das kollaborative Arbeiten hat zu Beginn einige Schwierigkeiten, die es zu überwinden gilt. Ähnlich wie beim Lernen einer neuen Sprache wird der Wortschatz zu Beginn aufgebaut. Im Verlauf ist der wesentliche und ausschlaggebende Faktor aber die Grammatik. Im übertragenem Sinne reicht es aus, den commit und sync Knopf zu kennen, jedoch gehen ohne Regeln viele zusätzliche Bonis verloren.
Am Beispiel der OpenLab Blogbeiträge kann dies verdeutlicht werden.
Jede Markdown Datei hat einen Header mit Informationen, die auf WordPress eingetragen wurden wie z.B. der Titel (Freie Ausmalbilder im Handumdrehen selbst erstellen) und Untertitel (Mal ganz kreativ. Motive suchen und ein Ausmalbild daraus erstellen.) sowie der geschätzte Zeitaufwand für die Lerneinheit (20 - 30 Minuten) und die Tags.
<!-- Titel, Intro Text and Reading Time in Wordpress for display in tiles
# Freie Ausmalbilder im Handumdrehen selbst erstellen
## Mal ganz kreativ. Motive suchen und ein Ausmalbild daraus erstellen.
> geschätzer Zeitaufwand: 20 - 30 Minuten
Tags: Umrissbilder, OpenClipart, CC Search, Ausmalbilder Vorlage, KindOERgarten, Pixlr, DIN A4, 4Teachers, Online Photo Editor, LibreOffice
## User Story ([Persona Fin Bonde](https://git.universitaetskolleg.uni-hamburg.de/synlloer/oer-know-how/blob/master/Unterlagen/Personas-03.pdf))
-->
Danach folgt das Tutorial und am Ende eines jeden Beitrags steht der zugehörige Lizenztext.
<a class="cc-license" rel="license" href="http://creativecommons.org/licenses/by/4.0/"><img alt="Creative Commons Lizenzvertrag" style="border-width:0" src="https://i.creativecommons.org/l/by/4.0/88x31.png" /></a><br /><span xmlns:dct="http://purl.org/dc/terms/" property="dct:title"><a xmlns:cc="http://creativecommons.org/ns#" href="https://openlab.blogs.uni-hamburg.de/freie-ausmalbilder-im-handumdrehen-selbst-erstellen/" property="cc:attributionName" rel="cc:attributionURL">Freie Ausmalbilder im Handumdrehen selbst erstellen</a></span> von <em><a href="https://www.manfred-steger.de/" target="_blank">Manfred Steger</a></em> für das Universitätskolleg der Universität Hamburg ist lizenziert unter einer <a rel="license" href="http://creativecommons.org/licenses/by/4.0/" target="_blank">CC BY 4.0 International Lizenz</a>.
Wird nun ein Beitrag über GitLab oder WordPress betrachtet stehen jeweils alle Informationen zur Verfügung. Gehen z.B. durch eine defekte Datenbank in WordPress Informationen verloren, sind diese über das Dokument immer noch vorhanden. Darüberhinaus können öffentliche Repositorien mit einem sog. fork in neue Projekte einfließen und alle Informationen werden in den Ableger integriert.
Dieses Werk ist lizenziert unter einer Creative Commons Namensnennung 4.0 International Lizenz.
Zitiervorschlag: Steger, Manfred: OER entwickeln und bereitstellen mit Git und WordPress. CC BY.