FriLUG

Ade, dynamische Inhalte

14 May 2018

So ein CMS wie Wordpress oder zuletzt Drupal ist schon komfortabel. Jeder Laie kann ohne Vorkenntnisse eigene Inhalte veröffentlichen und verwalten. Es gibt eine Benutzerverwaltung mit Berechtigungen, sodass nichts kaputt gehen kann. Auch multimediale Inhalte, in unserem Fall nur ein paar Bilder, können einfach verwaltet werden. Und nicht zuletzt können von Mitgliedern und Besuchern Kommentare (und SPAM) verfasst werden.

Der Nachteil: Wartungsarm ist das Ganze nicht. An der Hochschule gibt es Aufgrund interner Policies grundsätzlich keinen SSH-Zugang aus dem öffentlichen Netz. Daher war meist ein VPN in die Hochschule nötig, um von dort dann unseren Server zu administrieren. Einfacher war es jedoch, hinzufahren und alle Updates vor Ort im FriLUG-internen Netz durchzuführen. Gerade in den Semesterferien (ja, für mich sind das Ferien!) ist das echt ätzend.

Sowohl Wordpress als auch Drupal glänzen mit (un-)regelmäßigen kritischen Sicherheitsupdates mit dramatischen Auswirkungen (LFI, RFI, XSS, PHP Object Insertion, um mal einige zu nennen). Von Wordpress hatten wir uns vor einiger Zeit hauptsächlich aufgrund enormer Performance-Problemen getrennt. Das auch Drupal nicht Wartungsarm ist, war mir von vornerein klar. Hinzu kommt aber noch, dass Drupal (aus Sicherheitsgründen) kein Auto-Update bietet, und ich gefühlt jede Woche im Maintenance Mode den neuen Core reinkopiert habe. Das führte natürlich dazu, dass viele Updates, gerade in den Semesterferien, auf sich warten ließen.

Footer unseres ehemaligen Wordpress-Blogs: Über drei Sekunden Pageload. Nach vielen Tagen Problemsuche haben wir schließlich Wordpress den Rücken gekehrt.

Die Lösung? Weg mit Wartungsintensiven CMS, Weg mit PHP. Weg mit FastCGI. Weg mit dynamischen Inhalten. Wir sind alle Nerds. Wir brauchen kein Klickbunti-CMS um einen Blog zu betreiben.

Hallo Jekyll

Jekyll ist ein Generator für statische Seiten. Ich habe in der Vergangenheit schon die meisten meiner anderen betreuten Seiten auf statische Inhalte umgestellt. Aber Jekyll erleichtert die Arbeit erst auf ein Level, das es tatsächlich erträglich macht kein CMS zu haben.

Features

  • Kein serverseitiges Scripting nötig
  • Artikel und Seiten können mit Markdown geschrieben werden
  • Liquid Template Engine erlaubt auch komplexe Strukturen und automatisierung
  • Vielzahl von fertigen Plugins und Möglichkeit für eigene Plugins
  • Ruby … ich mag Ruby

Warum Jekyll und nicht … ?

Es gibt einige gute Alternativen zu Jekyll

Warum also Jekyll?

Pure Gewohnheit. Es gibt keinen anderen Grund. Ich arbeite schon länger mit Jekyll und bin zufrieden. Zunächst nur für Github Pages, wenig später dann auch “außerhalb”. Jekyll ist leicht zu lernen, schnell genug und geht mir nicht auf die Nerven. Warum wechseln, wenn ich gut klarkomme? Das einzige was ich wirklich vermisse ist ein sauberes Asset-Management für Artikel. Aber dafür gibt’s ja die Plugin-Schnittstelle, das bekomme ich schon noch gelöst.

Und wie publiziert man nun Artikel?

Im Hintergrund arbeitet ein Gitlab mit aktivierter CI. Der master-branch ist protected und kann nur über einen Pull-Request verändert werden. Artikel werden von den Mitgliedern ein getrennten Branches erstellt und dann in den master gemerged. Die CI baut daraufhin die Webseite neu und schiebt sie, sofern es keine Fehler gab ins Webverzeichnis. Soweit die Theorie. In der Praxis ist derzeit alles manuell.

Related Posts