Auf Twitter kam die Frage auf, warum einige Menschen statische Webseiten Generatoren benutzen. Seitdem ich im vergangenem Jahr Planet-Punk.de wieder reanimiert habe, nutze ich eine Kombination aus Pelican und Git um diese Seiten hier zu veröffentlichen.
Ich schreibe bereits seit Anfang 2000 auf Planet-Punk.de, also lange, bevor Bloggen en-vogue war. Nachdem ich ganz lange HTML Seiten editiert und regelmässig aktualisiert hatte, benutzte ich irgendwann ein(!) PHP Skript, um HTML Seiten aus Textdateien zu generieren und Kommentare in eine ebensolche zu schreiben.
Dieses Skript wuchs über die Zeit heran und irgendwann 2005 / 2006 bin ich dann - als Bloggen wirklich ganz groß war - auf Wordpress umgestiegen. Diesem System bin ich bis heute für mein IT Blog und neuerdings unserem Familienblog treu geblieben und finde es - trotz vieler optischer Änderungen im Backend - bis heute ausgesprochen gelungen.
Für Planet-Punk.de habe ich damals schon ein Plugin namens Text Control eingesetzt, um die Formatierung der Posts zu steuern. Da ich vieles in Textdateien vorliegen hatte, wollte ich nicht, dass Wordpress versucht, irgendwelche Interpretationen und Formatierungen vorzunehmen und konnte so meine Posts in Textile verfassen bzw. alte Inhalte übernehmen.
Wie viele Dinge ändern sich Interessen im Lauf der Zeit und meine Arbeit an Daily Fratze, meiner “regulären” Arbeit und natürlicher meiner Familie beanspruchten viel Zeit, die ich früher zum Bloggen aufgewandt hatte. Nachdem ich fast ein Jahr nichts mehr veröffentlich hatte, machte ich das Blog mit einer statischen Seite dicht. Aufgeben wollte ich die Domain aus unterschiedlichsten Gründen nicht.
Viele der Dinge, die ich damals schrieb, sind überholt oder teilweise auch einfach nur dämlich. Viele andere allerdings, beispielsweise meine Konzert- und Festivalberichte haben für mich einen hohen Erinnerungs- und ideellen Wert. Diese möchte ich gerne aufbewahren, insbesondere lokal in meinem Archiv.
Meine Anforderungen an ein solches Archivsystem mit der Möglichkeit zur Veröffentlichung:
- Inhalt soll ohne das Template / Blogging System oder den Generator lesbar sein
- Minimaler Wartungsaufwand
- Revisionssicher
- Kein Pflegeaufwand (insbesondere Updates von Bloggin Software u.ä.)
- Bei Veröffentlichung sollen alte URLs (auch wenn diese teilweise bereits 10 Jahre alt sind) wie gehabt funktionieren.
Eine Kommentarfunktion wollte und will ich explizit nicht. Ich möchte zum einen den Inhalt erstmal für mich und die 3 Leute haben, die aus nostalgischen Gründen hier vorbeischauen. Zum anderen halte ich es für fragwürdig, dass sich eine Kommentarfunktion überhaupt noch lohnt, merke ich doch an meinen anderen Blogs, wie sehr die Bereitschaft, einen Kommentar zu schreiben, gesunken ist. Leider werden die meisten Kommentare mittlerweile von Spammern geschrieben, was dann automatisch Pflegeaufwand oder den Einsatz weiterer Software bedingt, um dieser Kommentare Herr zu werden.
Wenn man bereit ist, einen Drittanbieter anzubinden, ist z.B. Disqus.com eine Möglichkeit, auch bei statisch generierten Seiten eine Kommentarfunktion zu ermöglichen.
Da schließt sich für mich der Kreis. Die meisten meiner Texte liegen bereits im Textile Format vor. Dieses wird leider nicht wirklich gepflegt bzw. es gibt nur noch wenige Tools dafür. Markdown scheint das Markupfrei Format zu sein, das sich durchgesetzt hat. So oder so ist der Konvertierungsaufwand nicht besonders hoch und ich habe nun ein lokales Archiv meiner Posts, die ich gerne plattformunabhängig aufbewahren möchte:
Diese Dateien lassen sich in jedem Texteditor halbwegs lesbar für Menschen anzeigen. Genau das, was ich wollte.
Wie kommen die auf den Webserver? Ich verwalte das Archiv mit Git und nutze im Upstream Repository folgenden post_receive hook, der aktiv wird, sobald ich mit git push meinen lokalen Branch veröffentliche:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | #!/bin/sh
SRC=~/temp/staging/planet-punk.de/src
TARGET=~/temp/staging/planet-punk.de/target
SITE=/pfad_zu_www_dateien/planet-punk.de/html
PELICAN=/opt/local/bin/pelican
rm -rf $SRC
mkdir $SRC
GIT_WORK_TREE=$SRC git checkout -f
rm -rf $TARGET
mkdir $TARGET
cd $SRC
$PELICAN content -o $TARGET -s publishconf.py
rsync -crlpgoDv --delete --checksum $TARGET/ $SITE/
|
Dieser checkt das Repository in ein temporäres Staging Verzeichnis aus, nutzt Pelican zur Generierung des Inhaltes und anschließend ein rsync in das eigentliche Verzeichnis, das vom Webserver ausgeliefert wird.
Der rsync Teil ist nicht unbedingt nötig, aber in dieser Form bleibt der Zeitstempel der bestehenden Dateien, die sich nicht ändern, wenn der das Blog neu generiert wird, erhalten und demzufolge ändern sich auch die Cache-Header nicht. Zum anderen ist es ganz nett für das Backup des Webservers, da dieses inkrementell wird.
Diesen Post habe ich gerade offline bzw. mit einer ausgesprochenen wackligen Internetverbindung im ICE International geschrieben, ein weiterer Vorteil dieses Systems.
Für dieses Blog habe ich mit der Kombination aus Source-Controll-System und einem statischen Seiten Generator die für mich ideale Lösung gefunden, meine Inhalte zu erhalten.
Was ich irgendwann mal tun müsste, ist zum Beispiel etwas Code schreiben (entweder im Pelican Template oder als Javascript), der die Archivseite übersichtlicher macht oder den Paginator auf der Startseite sinnvoller gruppiert, sollte die Anzahl der Inhalte in absehbarer Zeit wieder drastisch zunehmen.
Da selbst die Formatierung von Quelltexten (siehe das Bashskript oben) sehr ansprechend funktioniert, wäre so ein System selbst für http://info.michael-simons.eu eine denkbare Alternative. Allerdings hoffe ich dort dann doch immer noch auf etwas mehr Interaktion oder Rückmeldung, möchte aber kein System von Drittanbietern dazu nutzen (mal abgesehen davon, dass in diesem Blog alle Texte im Wordpress “Format” vorliegen…)
Generatoren sind sicherlich keine universell einsetzbare Wunderwaffe, aber das sollten die wenigstens Werkzeuge im IT Bereich meiner Meinung nach sein, sondern nur Mittel, um die gestellte Aufgabe effizient zu lösen.
- «
- 1
- »