Static Site Generatoren

Viele einfache Homepages für Unternehmen oder private Blogs bestehen aus einer oder einer Handvoll Seiten. Dafür ein komplexes Content Management System (CMS) zu benutzen öffnet unnötige Sicherheitslücken und verschwendet wertvolle Ressourcen. Ein Static Site Generator erzeugt aus einzelnen Inhalten alle benötigten HTML-Dokumente für Homepages und Blogs.


Viele Webseiten werden von komplexen Content Management Systemens (CMS) wie Typo3, Drupal, Wordpress oder Joomla ausgeliefert. Bei jeder einzelnen Anfrage, auch wenn es sich um eine noch so simple Homepage handelt, baut dazu ein komplexes System aus Skripsprache(n) und einer Datenbank die Antwort für den Webserver zusammen - auch wenn es sich nur um eine einzige Seite mit statischem Inhalt handelt. Die Alternative ist, eine einzige Webseite mit Hilfe einer Homepage-Vorlage von Hand oder mit einem speziellen Editor zu erzeugen. Sobald eine zweite Seite dazukommen soll, muss man sich um eine gewisse Modularität kümmern - alle Seiten sollten einen Header, einen Footer und vor allem einen zusammenhängende Navigation haben. Das ist durchaus von Hand machbar, aber recht mühsam.

Hier helfen Static Site Generatoren (SSG). Sie stellen einen Mittelweg zwischen fettem CMS und der HTML-Programmierung von Hand dar. Bei einem SSG schreibt man seine Texte meistens in Markdown, definiert über eine Konfigurationsdatei und ein Theme das Aussehen seines Webauftritts und überlässt es dem SSG, daraus alle benötigten HTML-, CSS- und JavaScript-Dokumente für eine Website zu erstellen. Im Internet benötigt man nun nur noch einen minimalistischen und damit sicheren Webserver, auf den alle dieser Dateien kopiert werden. Viele SSG laufen in einem halbautomatischen Modus, bei dem sie die Verzeichnisse mit den vom Benutzer erstellten Inhalten überwachen, daraus bei Änderungen automatisch die neuen Webdokumente erstellen und diese auch automatisch auf den Webserver hochladen.

# Wie funktioniert ein CMS

Ein übliches Content Management System (CMS) für Webseiten wie Typo3 (erschienen 1998), Drupal (2001), Wordpress (2003) oder Joomla (2005) arbeitet immer nach demselben Prinzip: Alle Funktionen sind in einer Skriptsprache programmiert - bei den vier genannten Kandidaten ist das PHP. Diese PHP-Funktionen analysieren die vom Benutzer über seinen Webbrowser an den CMS-Webserver gesendete Anfrage. Daraus versuchen andere PHP-Funktionen nun, eine passende Antwort in Form eines HTML-Dokuments zu erstellen. Dazu greift PHP auf die Daten in einer Datenbank zu - bei obigen CMS ist das in der Regel MySQL oder MariaDB, alternativ können das auch andere Datenbanken wie SQLite, PostgreSQL, OracleSQL oder MS-SQL sein. In der Datenbank sind Vorlagen oder Anweisungen darüber gespeichert, wie einzelne Webseiten aufgebaut sein sollen, wie sie aussehen sollen und welche Inhalte sie enthalten sollen. Das alles fügt PHP zusammen und erzeugt daraus ein HTML-Dokument, das es an den Webserver (Apache, Nginx, IIS usw.) übergibt, der wiederum die dynamisch erzeugte Seite an den Browser des Anwenders ausliefert.

# Schön einfach... und unsicher

Das alles klingt nicht nur kompliziert, das ist es bei den genannten CMS auch. Und wie bei allen übertrieben komplexen Systemen - egal ob Betriebssystem, init-Framework, Office-Software oder CMS - kommen mit der Komplexität die Fehler und Sicherheitslücken (CVE, Common Vulnerabilities and Exposures). Bei Drupal waren es seit 2002 ganze 200 CVEs, bei Typo3 seit 2005 immerhin 193, und das beliebte weil so einfach zu bedienende Wordpress kommt seit 2004 auf satte 331 CVEs - das sind im Schnitt rund 20 ernsthafte Sicherheitslücken pro Jahr (2019: 23, 2020: 21) [https://www.cvedetails.com/product/4096/Wordpress-Wordpress.html?vendor_id=2337]! 

Über Sicherheitslücken können Angreifer beispielsweise Schadcode einschleusen, der anschließend vom Webserver an die eigenen Leser und Kunden ausgeliefert wird. Im schlimmsten Fall kann das System und damit der ganze Server kompromittiert werden und gelangt so in die Hand von Cyberkriminellen, die dann Inhalte verändern, löschen oder gar eigene (illegale) Inhalte hochladen. Wie bei jeder Software liefern auch CMS als Gegenmaßnahme automatische Updates aus. Dabei laufen sie den Lücken jedoch prinzipbedingt immer hinterher, einen Fix kann es nur geben, wenn zuvor eine Lücke erkannt wurde. Wer einmal die Logdateien seiner CMS genauer unter die Lupe nimmt, stellt schnell fest, dass es kurz vor einem Update bereits massive Angriffe auf eben diese Lücke gibt. Die Angriffe sind ebenfalls automatisiert und kommen weltweit und skriptgesteuert aus organisierten Netzwerken. Für den normalen CMS-Betreiber ist es eher unmöglich, sich proaktiv gegen diese Angriffe zu wehren. Ist man selbst kein erfahrener Administrator sollte man sich auf einen Dienstleister verlassen, der Wordpress oder einer der anderen CMS vorinstalliert hostet - hier kann man bei Problemen von einigermaßen schnellen Reaktionszeiten ausgehen und muss nicht selbst permanent auf der Lauer liegen. Natürlich kostet das Geld.

# Sicher durch statische Inhalte

Doch es geht auch viel entspannter: Liefert man statt der dynamischen Seiten eines CMS nur statische Seiten eines "Static Site Generators" beispielsweise über den OpenBSD-Webserver "httpd" aus, hatte man bislang nur ein einziges Mal (2017) mit einer einzigen Sicherheitslücke zu kämpfen (wurden mehrere große Dateien gleichzeitig über einen HTTP-Range-Header angefordert, konnte "httpd" den Arbeitsspeicher und damit die Swap-Datei überfluten - eine klassische DoS-Attacke). Da der gesamte Content fertig "compiliert" im Dateisystem liegt und direkt vom Webserver ausgeliefert werden kann, sind auch keine Skriptsprachen wie PHP oder Datenbanken MySQL/MariaDB auf dem Server notwendig - was nicht nur den Ressourenbedarf, sondern auch die Angriffsflächen drastisch verringert.

# SSGs wie Sand am Meer

Es gibt hunderte verschiedene Static Site Generatoren (siehe Listen auf https://staticsitegenerators.net/ oder https://jamstack.org/generators/). Wie bei (freier) Software üblich werden viele davon nicht mehr gepflegt oder sind halb fertig. Um überhaupt eine sinnvolle Vorauswahl treffen zu können, sollte man die SSGs in der erstgenannten Liste nach "Stars" sortieren, was in der zweiten Liste schon die Voreinstellung ist. Diese "Stars" entsprechen den Github-Stars, geben also an, wie viele Github-Nutzer das jeweilige SSG interessant genug finden, um es in auf ihrer "Your Stars"-Seite aufgelistet zu haben - man kann nicht mehr interessante Projekte auch per "unstar" aus der Liste entfernen. Viele Stars deuten auf eine gewisse Popularität hin, was heute nicht zwangsläufig ein gutes Auswahlkriterium ist... aber SSGs mit weniger als vielleicht 1000 Stars sind Nischen- oder Hobbyprojekte, die durchaus interessant, aber in den meisten Fällen für den Praxiseinsatz unbrauchbar sind.

# Der Weg zum passenden SSG

SSGs sind freie Software und lassen sich leicht installieren, man sollte also durchaus ein paar von ihnen ausprobieren. Die Konfiguration, die Verfügbarkeit von PlugIns und Themes und vor allem der späterer Workflow sind teilweise sehr unterschiedlich. Wer ernsthaft mit einem SSG arbeiten will sollte auch einen Blick auf die verwendete Programmier-/Skriptsprache, die Templates und die Lizenz werfen.

Anders als bei Wordpress & Co. kann es durchaus vorkommen, dass man sein SSG im Detail anpassen und erweitern will - und dann sollte man dessen Programmiersprache beherrschen. Neben Python sind das JavaScript, Ruby, Rust, Go und andere hippe Sprachen, manchmal aber auch nur HTML oder Bash. Noch wichtiger sind die Templates, denn aus diesen Formularen oder Vorlagen generiert ein SSG die eigentlichen Webseiten. Hier will man fast immer etwas anpassen, beispielsweise den Namen des Autoren oder das Datum des Postet ein- oder ausblenden. Das geht manchmal über eine Option in der Konfigurationsdatei des SSG, manchmal muss man dazu aber auch ein Template von Hand ändern. Eine Template-Sprache wie Jinja2 ist verbreitet und speziell auf diese Aufgabe zugeschnitten. Ob man sich in Exoten wie ERB, Tilt oder Haml einarbeiten will, nur um ein paar Angaben bei den Postings oder im Header seiner späteren Webseite zu ändern, muss jeder für sich selbst entscheiden. Das kann Spaß machen, wenn man viel Zeit hat. Die Lizenz ist mehr Geschmackssache, denn die Lizenzen sind fast ausnahmslos frei - der Trend geht allgemein zu den wirklich freien MIT- und BSD-Lizenzen.

# Welche SSGs sollte man ausprobieren?

Wer sich wirklich einen Überblick verschaffen will, sollte vielleicht folgende SSGs ausprobieren, weil sie das Spektrum der SSGs weitestgehend abdecken. Eines der ältesten und bekanntesten SSGs ist Jekyll (geschrieben in Ruby), das beispielsweise auch Github für die Github Pages nutzt. Ebenfalls ein Klassiker und dabei einfach zu handhaben ist Pelican, das in Python geschrieben Jinja2-Templates benutzt und unter der AGPL-3.0 steht - leider machen die Entwicklung und vor allem die Themes keine großen Fortschritte. Superschnell, fexibel und mit vielen praktischen Funktionen wartet Hugo auf. Das in Go geschriebene SSG verwendet auch Go-Templates, bietet viele schicke freie und sogar kommerzielle Themes und ist vor allem als kompaktes Binary für viele Betriebssysteme und Rechnerarchitekturen erhältlich. Hugo erfordert einiges an Einarbeitungszeit, ist dann aber flexibler als beispielsweise Wordpress.

Die drei genannten SSGs eignen sich für einfache Webauftritte und Blogs. Wer mehr im Stile einer Dokumentation arbeiten will, sollte sich MkDocs und Sphinx ansehen. Sphinx wurde ursprünglich für die Dokumentation von Python geschrieben und eignet sich hervorragend dazu, aus reStructuredText-Quellen HMTML-, PDF-, LaTeX-, ePub- und viele weitere Dokumente zu erzeugen. MkDocs ist einfach einzurichten und erzeugt auf Anhieb schick aussehende Online-Dokumentation, weswegen es von vielen Projekten gerne zur Erzeugen der Online-Handbücher benutzt wird. Beide Dokument-Generatoren sind in Python geschrieben und lassen sich über Jinja2-Templates anpassen.

Wie einfach ein SSG sein kann, zeigt BashBlog von Carles Fenollosa. Wie der Name andeutet, ist es lediglich ein großes (1194 Zeilen umfassendes) Bash-Skript [https://github.com/cfenollosa/bashblog]. Trotz seiner Einfachheit produziert es optisch ansprechende kleine Blogs, an dessen pure Ästhetik viele andere SSGs nicht heranreichen. Wer ohne irgendwelche Installation und ohne weitere Abhängigkeiten nur ein paar Seiten ins Internet stellen will, sollte sich unbedingt einmal BashBlog ansehen.



            !!! Vielleicht als KASTEN ANFANG? !!!
# Wohin mit dem Script/Binary?

Skripte oder Binaries für die SSGs kann man mit root-Rechten für alle Benutzer in den entsprechenden /opt- oder /usr/local-Verzeichnissen von GNU/Linux oder FreeBSD ablegen. Wer nur mit den eigenen Benutzerrechten auskommen will, kann als einfache Lösung die Skripte oder Binaries auch in das ~/bin-Verzeichnis im Homeverzeichnis kopieren. Die meisten GNU/Linux-Installationen berücksichtigen diesen lokalen Ort für Programme. Wenn nicht, muss man das Verzeichnis per

 mkdir ~/bin

anlegen. Dazu ist in der ~/.profile-Datei eine Erweiterung des Suchpfades notwendig. Meistens ist der Block dort bereits vorhanden:

 # set PATH so it includes user's private bin if it exists
 if [ -d "$HOME/bin" ] ; then
     PATH="$HOME/bin:$PATH"
 fi

Die Bash fragt in diesem per if-Statement ab, ob das ~/bin-Verzeichnis überhaupt vorhanden ist und erweitert den Suchpfad gegebenfalls um eben dieses Verzeichnis. Die obigen Änderungen erfordern zumindest einen Neustart des Terminal-Fenster, um aktiv zu werden.

Natürlich kann man Skripte und Binaries auch im Projektverzeichnis ablegen. Das hat den Vorteil, dass Anpassungen oder bestimmte SSG-Versionen immer zum Projekt passen und in einem Rutsch zusammen mit den Inhalten gesichert oder auf ein anderes System verschoben werden können.
             !!! Vielleicht als KASTEN ENDE? !!!



# Super-simpel: Bashblog

Bashblog von Carlos Fenollosa zeigt, wie einfach ein SSG sein kann. Das Projekt ist bereits zehn Jahre alt, erhält aber sporadisch noch Verbesserungen. Glücklicherweise wird es nicht wie viele andere Opensource-Projekte permanent mit neuen Funktionen vollkommen überladen. Bashblog kann für seine aktuell 1194 Zeilen Bash-Code überraschend viel und macht genau das, was es soll: Aus HTML- oder Markdown-Texten eine Webseite generieren. 

Eine Installation gibt es nicht, am einfachsten legt man ein Verzeichnis für Bashblog an und lädt das Bashblog-Skript (bb.sh) herunter:

 mkdir bashblog
 cd bashblog
 wget https://raw.githubusercontent.com/cfenollosa/bashblog/master/bb.sh

Wichtig ist das "raw" im Domainnamen, weil sonst eine HTML-formatierte Seite, aber nicht der pure Shellcode heruntergeladen wird. Das Skript muss als ausführbar (+x) gekennzeichnet werden:

 chmod +x bb.sh

Macht man das nicht, erhält man die Fehlermeldung "-bash: ./bb.sh: Keine Berechtigung". Ruft man nun

 ./bb.sh

ohne weitere Parameter auf, zeigt es eine kleine Hilfe an - dazu sollte das Terminalfenster 120 oder mehr Zeichen breit sein, ansonsten wird der Text unleserlich umgebrochen.

Bashblog benutzt zum Editieren der Postings einen frei definierbaren Editor, der über die EDITOR-Variable festgelegt wird. Je nach GNU/Linux-Distribution kann der Eintrag schon voreingestellt sein, was sich mit einem der beiden folgenden Befehle leicht herausfinden lässt:

 echo $EDITOR
 printenv EDITOR

Je nach Geschmack kann man hier "nano", "joe", "vim", "emacs" oder wie der Autor den von OpenBSD stammenden MicroEmacs ("mg") verwenden:

 export EDITOR="mg"

Soll diese Einstellung permanent sein, fügt man diese Zeile ans Ende der .bashrc an und übernimmt die Einstellung für die aktuelle Sitzung per 

 source ~/.bashrc

# Mit Bashblog bloggen

Bashblog funktioniert nun ganz einfach: Im aktuellen Blog-Verzeichnis gibt man

 ./bb.sh post

ein. Bashblog öffnet dann eine Vorlage im voreingestellten Editor. Den Text kann man editieren und im einfachsten Fall mit HMTL-Anweisungen formatieren. Die erste Zeile ist die spätere Überschrift, aus der Bashblog auch den Dateinamen generiert. Aus der Überschrift "Ein erster Test" wird also "ein-erster-test.HTML". Ist der Dateiname (und damit die Überschrift) bereits vorhanden, fügt Bashblog ein paar Ziffern zur Unterscheidung an - es überschreibt also keine alten Postings. Wie in der Vorlage bereits vorhanden können über die Formatierung "<p>Tags: Stichwort1, Stichwort-Nummer-Zwei</p>" Tags für Postings vergeben werden.

Nach dem Speichern des Postings und Verlassen des Editors fragt Bashblog, ob der Text in ein Posting umgewandelt, nochmal editiert oder als Draft behandelt werden soll. Mit "p" für Posting erzeugt Bashblog ein paar HTML-Dateien. Die "index.html" kann man mit dem Webbrowser öffnen. Der Inhalt des Blog-Verzeichnisses (ohne die bb.sh) kann auch in das Wurzelverzeichnis eines Webservers kopiert und so öffentlich publiziert werden.

Etwas ungewohnt ist das Editieren vorhandener Postings, da man hierzu den HTML-Dateinamen kennen muss. Man ruft dann

 ./bb.sh edit ein-erster-test.HTML

auf. Achtung! Man sollte keinesfalls ein solches HTML-Dokument außerhalb von Bashblog von Hand ändern. Um Texte in Markdown zu schreiben muss ein Markdown-Prozessor installiert werden, Bashblog erkennt das in der Regel automatisch. Welche Postings (genauer: Überschriften, nicht HTML-Dateinamen) vorhanden sind, zeigt ein

 ./bb.sh list

Durch Löschen der HTML-Datei eines Postings löscht man das Posting. Bashblog sollte dann per

 ./bb.sh rebuild

alle Seiten inklusive des Index neu generieren.

# Feintuning bei Bashblog

Das Bashblog-Skript generiert auch ein main.css und ein blog.css für das grundlegende Aussehen des Blogs, welche sich anpassen lassen. Für weitere Änderungen muss man sich durch das Bashblog-Skript arbeiten, was schon einiges an Vorwissen im Bashscripting erfordert. Im vorderen Bereich des Skripts ("global_variables()") sind viele Einstellungen zusammengefasst. Achtung! Änderungen hier gehen mit einem eventuellen Update der bb.sh verloren. Besser ist es, alle diese Variablen in einer separaten ".config"-Datei im Blog-Verzeichnis zu definieren. Bashblog setzt zuerst alle Variablen anhand der Werte im bb.sh-Skript und überschreibt diese dann mit den Variablen aus der .config-Datei. Eine .config-Datei mit folgendem Inhalt

 global_title="Colossus vs. Enigma"
 global_description="Röhrencomputer und Krytografie"
 global_url="http://192.168.1.1/bashblog"
 global_author="mipl"
 
würde die grundlegenden Blog-Einstellungen vornehmen. Nach Bedarf fügt man weitere Variablen aus dem global_variables()-Abschnitt hinzu. Tipp: Das Plain Text Project liefert minimalistische ASCII-Vorlagen für diverse Projekte, unter anderem auch eine mit allen auf die Standardwerte vorkonfigurierte .config-Datei für das aktuelle Bashblog 2.9 [https://plaintextproject.online/templates/bashblog-dot-config.txt].

# Go Hugo, go!

Hugo ist eher auf der anderen Seite des SSG-Spektrums anzuordnen: Geschrieben in der Programmiersprache Go wurde es auf Geschwindigkeit optimiert, bietet enorm viele praktische Funktionen, ist aber trotzdem leicht zu benutzen und äußerst flexibel. Die Entwickler bieten Hugo als sowohl im Quellcode als auch als Binary an. Echte OpenSource-Admins übersetzen Hugo aus den aktuellen Quellen, was unter FreeBSD und dessen Ports-Sammlung ganz einfach per

 cd /usr/ports/www/gohugo/
 make install clean

oder installieren es alternativ per

 pkg install www/gohugo

über den Paketmanager (nicht "hugo" installieren, dass ist ein PC Engine/TurboGrafx 16-Emulator).

Bei Mac OS X bietet sich der Weg über Homebrew ("brew install hugo") oder MacPorts ("port install hugo") an. Für Windows kann das mit Chocolatey oder Scoop erledigt werden. Wie üblich muss man bei GNU/Linux aufpassen, welche Distribution man einsetzt. Einige wie Gentoo oder Arch sind recht aktuell, bei Debian oder Ubuntu bekommt man teilweise stark veraltete und vor allem merkwürdig konfigurierte Binaries. Je nach Geschmack und Fähigkeiten des jeweiligen Maintainers ist beispielsweise Sass/SCSS für erweiterte Themes vorhanden (Ubuntu), oder eben auch nicht (Debian). Es mag helfen, unter GNU/Linux auf Snap, Flatpak, Appimage oder Docker auszuweichen und dort auf eine passende Konfiguration von Hugo zu hoffen.

Die Dokumentation zur Hugo-Installation [https://gohugo.io/getting-started/installing] zeigt viele Wege. Am einfachsten ist es letztlich, das zu seinem Betriebssystem (Windows, Mac OS X, GNU/Linux, Free/Net/OpenBSD und Dragonfly BSD) und der Architektur (32/63 Bit, AMD oder ARM) von der Release-Seite [https://github.com/gohugoio/hugo/releases] herunterzuladen und von Hand zu installieren. Dazu wählt man das "tar.gz" (nicht das .deb) und kopiert das darin enthaltene Hugo-Binary in den oben beschrieben ~/bin-Ordner - fertig.

Um mit Hugo ein neues Projekt zu erstellen gibt man dessen Namen an:

 hugo new site meinblog

Hugo erzeugt das Verzeichnis "meinblog" und legt darin alle grundlegenden Dateien und Strukturen an. Im "meinblog"-Verzeichnis liegt die Konfigurationsdatei von Hugo, die anfangs fast leer ist. Später nimmt man hier alle Anpassungen für das noch zu installierende Theme vor. Im Verzeichnis "archetypes" liegen Vorlagen für neue Postings im Jinja2-Format. Es lohnt sich, für wiederkehrende Postings eigene Vorlagen zu erstellen. In "content" speichert man alle Postings, Seite, Blogeinträge und so weiter. Dort kann man weitere Verzeichnisse anlegen, die Hugo optional automatisch als Kategorie verwenden kann. Unter "themes" liegen die Themes, die man für seine Hugo-Website verwenden will. Themes kann man selbst entwickeln oder beispielsweise von "Hugo Themes" [https://themes.gohugo.io/] herunterladen. Alle Themes dort sind kostenlos, es gibt aber auch (wenige) kostenpflichtige Themes für Hugo in den üblichen Theme-Shops. Ein heruntergeladenes Theme muss im "theme"-Ordner entpackt werden, so dass das Theme "notrack" beispielsweise im Verzeichnis "meinblog/themes/notrack" liegt - eventuell muss man es entsprechend umbenennen. In die "meinblog/config.toml" fügt man die Zeile

 theme = "notrack"

ein.

Das "data"-Verzeichnis ist eine Art Datenbank für Inhalte. Hier kann man YAML-, JSON- oder TOML-Dateien mit Daten ablegen, mit deren Hilfe Hugo Inhalte generieren kann. Die Daten können auch über APIs von anderen Webseiten im Internet geholt werden - beispielsweise Wetterdaten oder Kurse von Kryptowährungen.

Zurück im "meinblog"-Verzeichnis kann man im "content"-Ordner Postings im Markdown-Format (.md) - optional auch als reStructured Text (.rst) oder mit etwas Aufwand auch als asciidoc (.adoc) anlegen. Um Metadaten zum Posting festzulegen fügt man einige Variablen am Anfang des Postings als "Front-Matter" ein. Hugo versteht die Formate YAML, JSON, TOML und sogar ORG (dem Org-Mode von Emacs). In TOML kann das so aussehen:



 categories = ["Editorial"]
 date = "2021-07-01"
 description = "Vorteile von Hugo als Static Site Generator"
 tags = ["Hugo", "SSG", "Development"]
 title = "Hugo statt Bashblog: Wenn es komfortabel sein soll"
 draft = "false"

 Hier kommt der eigentliche Text...



Ruft man im "meinblog"-Verzeichnis nun

 hugo

auf, generiert Hugo sämtlichen Content, der für die Hugo-Website notwendig ist. Alle Dateien landen im Verzeichnis "static": HTML-Seiten, CSS-Dateien, Bilder, JavaScript und so weiter. Hier kann man auch Dateien speichern, die von Hugo 1:1 übernommen werden sollen. Der gesamte Inhalt des "static"-Verzeichnisses muss auf den Webserver kopiert werden, damit dieser die Hugo-Website ausliefern kann.

Gerade beim ersten Ausprobieren, aber auch später beim Schreiben der Postings ist es praktisch, das Ergebnis gleich in einem Webbrowser betrachten zu können. Dazu kann Hugo als Mini-Webserver gestartet werden. Für die lokale Ansicht kann dann auch das Schlüsselwort "draft" aus dem TOML-Header ausgewertet werden: Für den Produktionsserver werden diese Postings nicht generiert, wohl aber für den lokalen Server, wenn dieser mit dem Parameter "-D" (drafts) gestartet wird:

 hugo server -D

Unter http://localhost:1313/ oder der IP-Adresse des Hugo-Rechners auf Port 1313 wird die neue Website bereitgestellt.

# Wie geht es weiter?

Man kann nun per

 hugo new posts/hello-world.md

ein neues Posting in Markdown erstellen. Läuft der Hugo-Miniserver erkennt dieser neue oder geänderte Dateien und rendert erzeugt schnell die neuen HTML-Dateien - im Browser aktualisiert sich die Seite, an der man gerade arbeitet, automatisch. Wer statt dessen reStructured Text verwenden will, kann je nach GNU/Linux-Distribution über einen Fehler wie

 ERROR 2019/05/02 17:11:34 rst2html / rst2html.py not found in $PATH: Please install.
 Leaving reStructuredText content unrendered.

stolpern. Unter Devuan GNU/Linux behebt man das durch Installieren von

 sudo apt-get install python3-docutils

Während man mit Bashblog und einigen anderen SSGs recht schnell zurecht kommt, spielt Hugo seine Stärken erst dann aus, wenn man sich in das System eingearbeitet hat. Das geht Dank der Hugo-Dokumentation [https://gohugo.io/documentation/] und den darin eingebetteten Videos ausgezeichnet. Hugo kann in fast allen Bereichen angepasst werden, obwohl es von Anfang an leicht zu bedienen ist. Das Problem dabei ist, dass man im Laufe der Zeit immer wieder neue Funktionen von Hugo kennenlernt, diese aber unter Umständen eine Umstrukturierung der gesamten Content-Struktur nach sich ziehen. Bei Hugo zahlt es sich aus, einen konkrete Idee von der Struktur der späteren Website zu haben und Hugo dahingehend zu konfigurieren und vor allem auch den Content und dessen Verzeichnisstruktur entsprechend anzulegen.




!!! BILDER

SSGs.png: Übersichten zu Static Site Generatoren liefern aktuell 460 (https://staticsitegenerators.net/) beziehungsweise 327 (https://jamstack.org/generators/) unterschiedliche Generatoren.

editor.png: Bei SSGs gibt es keinen Online-Editor, sondern man kann seinen Editor - er sollte ASCII-Texte erzeugen können - je nach Geschmack frei wählen.

bashblog.png: Selbst ein simples Bash-Skript wie Bashblog erzeugt aus ein wenig Text und Bildern einen ansprechendes Webblog.





!!! Bashblog

Im Verzeichnis Bashblog liegt der gesamte Content, der für das Bashblog-Beispiel benötigt wird.
- Bashblog (bb.sh) stammt von https://github.com/cfenollosa/bashblog
- Text/Bilder stammen von Wikipedia: https://de.wikipedia.org/wiki/Colossus
- eingebettetes Video ist ein Link auf Youtube

Könntet ihr als ZIP zum Download anbieten. ACHTUNG! Da ist eine versteckte ".config"-Datei im Verzeichnis, die muss mit im ZIP sein!
