Jekyll Logo, dark solid
Jekyll Logo, CC-BY 4.0

tl;dr Von Drupal1 nach Jekyll2.
Seit Anfang 2019 läuft mein Blog bereits mit Jekyll2, einen Statischen Seiten Generator.
Dieser Artikel beschreibt, warum ich nach fast 15 Jahren Drupal CMS Framework1 durch Jekyll SSG als zugrundeliegende Technologie ersetzt habe.

Kleiner Geschichtsabriss

Ich betreibe dieses Blog, oder genauer gesagt, das Stück Software, aus dem dieses Blog hervorgegangen ist, seit 2004. Das waren um die 15 Jahre mit Drupal, gestartet mit der Version 4.5. Diese Installation war auch immer meine Spielwiese, um z.B. interessante Drupal-Module auzuprobieren. In 2009 habe ich dann das Update von Drupal 5 auf Drupal 6 gemacht.

Seit dem Erscheinen von Drupal 8 im Jahr 2016, nutze ich Drupal 6 LTS mit einigen Verbiegungen3, welches weiterhin aus der Community mit Sicherheits-Updates versorgt wird. Es sei angemerkt, dass laut Drupal Policy immer nur 2 Versionen unterstützt werden, ergo zu diesen Zeitpunkt Drupal in der Version 7 und 8.

Trotz der Versorgung mit Sicherheits-Updates und, abgesehen von dem einen oder anderen Rudiment in der Datenbank aus den Jahren, ist und bleibt es ein 10 Jahre altes Stück Software mit einer recht altertümlichen Anmutung, weit vor der Ära Mobile.

Ein Upgrade war also unabwendbar. Also habe ich teils mit dafür gesorgt, daß die von mir benötigten Module auch für Drupal 8 zur Verfügung stehen und habe entsprechend mit an entsprechenden Modul-Portierungen für Drupal 8 mitgearbeitet. Z.B. an Footnotes4, GeshiFilter5 oder dem Gist Input Filter6. Aber unabhängig davon, dass die Migrationsversuche nach Drupal 8 bei mir auf Anhieb nicht korrekt durchliefen, hat sich für mich Drupal 8 irgendwie als zu groß und sperrig für einen simples Blog wie meines angefühlt.

Aber da war dann noch Jekyll, welches seit Anfang 2016 in meinem Backlog stand (Danke Ben von der GzEvD für die Inspiration!). Im Winter 2018 bin ich dann endlich dazu gekommen, Jekyll zu installieren und das Step by Step Tutorial7 durchzugehen.

Warum Jekyll?

Was hat mich an Jekyll so begeistert und mich dazu bewegt auf diesen SSG zu wechseln?

Drupal-Importer

Jekyll hat einen Drupal Importer für die Versionen 6 und 7, das ist natürlich weniger ein Beweggrund, als eine Grundvorraussetzung, da ich meine Nodes, also meine geschriebenen Beiträge natürlich mitnehmen wollte.

KISS - Jekyll ist einfach.

Einfacher Start

Mit bereits installiertem Ruby und Ruby Gems sind es nur ein gem install jekyll bundler
für die Installation,
ein jekyll new example.com für das Erstellen einer Site
und ein bundle exec jekyll serve --drafts das Hochfahren des lokalen Webservers, der dann unter http://127.0.0.1:4000 erreichbar ist notwendig, um mit einem lokalem Jekyll auf Tuchfühlung zu gehen.

Einfache Struktur

Jekylls einfache Funktionsweise spiegelt sich auch seiner Verzeichnisstruktur8 wider:

example.com
├── 404.html
├── _config.yml
├── Gemfile
├── Gemfile.lock
├── index.md
├── _drafts
|   ├── ideenfindung.md
|   └── hier-wird-noch-dran-gefeilt.md
├── _posts
|   └── 2019-04-22-agile-ruhr-hattrick.md
└── _site
    ├─ 2019
    |   └── 04
    |         └── 22
    |             └── agile-ruhr-hattrick.html
    ├── 404.html
    ├── feed.xml
    └── index.html

Im Minimalumfang sind die folgenden Einträge relevant:

  • _config.yml Die zentrale Konfigurationsdatei. Hier werden grundlegende Einstellungen für die Website und seine Erweiterungen vorgenommen.
  • Gemfile + Gemfile.lock Die Abhängigkeiten für dieses Projekt. Hier werden die sog. Gems9 wie Jekyll selbst und seine Plugins inkl. Version festgehalten, welche via Bundler9 verwaltet werden. Bundler lässt sich mit Composer10 in der Drupal/PHP-Welt vergleichen.
  • _drafts Hier liegen, wie der Name bereits vermuten lässt, Entwürfe.
  • _posts Der Ordner für die publizierten Artikel. Den Posts muss noch ein Datumsprefix vorangestellt werden.
  • _site Die von Jekyll erzeugte Website bestehend aus statischen HTML-Dateien. Also das was am Ende durch einen Webserver oder jekyll serve ausgeliefert wird.

Geringe Komplexität

Jekyll benötigt im Vergleich zu einem CMS wie Drupal keine Datenbank und damit verbunden auch keine Programmiersprache wie PHP, die die Verbindung zur DB herstellt, um die nötigen SQL-Abfragen für den Aufbau der angefragten Seite auszuführen.

Also keine wechselseitigen Abhängkeiten und einzelnen Stellschrauben wie bei LAMP in Setup und Betrieb mehr.

Das alles führt zu einer deutlichen Veringerung der Komplexität.

Markdown

Markdown11 ist eine vereinfachte Auszeichnungssprache.
Ein erklärtes Ziel bei der Entstehung von Markdown war die leichte Lesbarkeit.

Bei Jekyll kommt der Markdown Dialekt Kramdown12 zum Einsatz. Dessen Umfang wurde unter anderem durch Fußnoten, Tabellen, Definitions-Listen und Abkürzungen erweitert.

Im Gegensatz zum HTML ist Markdown nicht nur viel leichter lesbar, sondern auch wesentlich schlanker und entsprechend einfach und auch ohne WYSIWYG Editor gut und recht intuitiv bearbeitbar.

Geschwindigkeit

Bei Drupal erfolgt zuerst der sogenannte Bootstrap Prozess13 14, welcher für das Laden der Konfiguration, Initialsierung der Datenbank und Variablen zuständig ist. Dann wird entschieden, unter anderem via Auswertung der URL, was ausgeliefert wird. Hier kommt maßgeblich die Datenbank an ins Spiel.

Auch wenn das sog. Bootstrapping bei anderen CMS unterschiedlich sein mag, gleich ist die Ausführung von Code und Datenbankabfragen für die dynamische Auslieferung einer Seite durch einen Request.

Im Vergleich zum CMS werden beim SSG direkt statische HTML Dateien ausgespielt. Das ist wesentlich performanter.

Keine Sicherheits-Updates

Durch die Verwendung einer serverseitigen Skriptsprache, egal ob es nun PHP, Python oder Perl im Beispiel des Apache Webservers ist, kann auch auf das CMS zugegriffen werden. Software wie CMS enthält potenziell wie jede andere Software auch Fehler. Gleiches gilt auch für Zusatzmodule, welche nicht nur den Funktionsumfang, sondern auch das Einfallstor für Angriffe vergrößern.

Wie beim Punkt Geschwindgkeit punktet hier auch wieder statisches HTML, das aus dem SSG heraus erzeugt wird. Da keine Skiptsprache bzw. Software nachgelagert ist bzw. diese nicht über die Anfrage auf den Webserver erreichbar ist, fällt dieser Angriffsvektor weg.

Spätestens seit dem letzten Drupalgeddon15 16, bin ich heilfroh, dass Sicherheits-Updates nichts mehr sind, worum ich mich (zeitnah) kümmern muss!

Viele Plugins & Themes

Jekyll ist weit verbreitet, das ist bestimmt nicht nur darin begründet, dass die kostenlosen GitHub Pages17 auch mit Jekyll betrieben werden können, sondern, sicherlich auch wegen der nicht geringen Anzahl von sogenannten Plugins, welche den Funktionsumfang erweitern und Themes, welche für das Look’n’Feel verantworlich sind.

Für alle von mir benötigten Drupal Module habe ich das jeweilige Jekyll Plugin Pendant einsetzten können oder es mit Bordmitteln geschafft.

Plugins

Themes

Arbeitsweise

Begünstigt dadurch, dass eine Jekyll Installation nur aus Dateien besteht, lassen sich Erstellung und Änderung von Inhalt, Konfiguration und Template-Logik mit einen Editor, in meinem Fall dem Vim18, durchführen. Es gibt auch keinen Zwischenschritt über den Browser zur Bearbeitung und Speicherung von Inhalt mehr.

Darauf aufbauend lassen sich natürlich Text-Dateien wunderbar mit einem VCS verwalten, und das Deployment in die DocumentRoot auf Uberspace läuft über einen post-receive git-hook. Das heißt, alle einzelnen Schritte sind über die Konsole möglich.

Blogging Like a Hacker19

Diese Arbeitsweise sagt mir mehr zu. Ich habe das Gefühl effizienter zu arbeiten und kann mich wesentlich mehr auf die eigentliche Arbeit, der Erstellung von Inhalt, konzentrieren.

Ein neues Spielzeug

Ein neues Stück Software und ein sich daraus erschließender Mikrokosmos.
Es fing alles mit einer Sandbox Installation und dem Jekyll Step by Step Tutoriali7 an.
Mit dem Jekyll Importer für Drupal 6 und dessen Anpassung ging es weiter und das, obwohl ich eigentlich kein Ruby spreche. Den Funktionsumfang durch Plugins erweitern und konfigurieren, Anpassung des Standardthemes Minima20, Inkludieren von Logik via Liquid Template Engine21, alles neue Spielzeuge.
Viel Neues und Unbekanntes, viel ausprobieren und experimentieren und die immens große Freude über erzielte Erfolge.

FLOSS

Klar, Jekyll ist mit MIT Lizenz FLOSS. Und klar, die Lizenz ist wichtig, aber ich möchte zudem auf noch etwas anderes hinaus:

Dadurch, dass Konfiguration sowie Template Logik in Code festgehalten wird, zusammen mit der Möglichkeit, GitHub Pages mit Jekyll zu betreiben, und der Verbindung von Netlify nach GitHub oder GitLab, gibt viele öffentlich verfügbare Repositories auf GitHub und Co.

Das hat einen großen Lerneffekt, spart viel Zeit und noch mehr Frust. Man muss das Rad ja nicht immer wieder neu erfinden.

Negatives

Last but not least, etwas Negatives: Geschwindigkeit.
Es dauert lange, bis eine Änderung (Inhalt, Theme, etc.) von jekyll serve --draft erkannt wird und die Seite “regeneriert” wird.

To be continued

Ich habe noch 2 verwandte Artikel in _draft, die bald folgen werden: