Autorenwebseite tobias-radloff.de

Eine moderne statische Autorenwebseite mit Werksseiten, Neuigkeiten, Terminkalender, Newsletterabonnentenverwaltung und Kontaktformular auf Basis von Pelican.

Dependencies

Pelican

Ich verwende Pelican v4.11.0 mit Markdown-Support (pip install pelican[markdown]) in einer eigenen venv-Umgebung. Pelican setzt python3 voraus.

Außerdem nutze ich folgende Pelican-Plugins:

• pelican-yaml-metadata – ermöglicht das Einlesen von Metadaten im YAML-Format
• pelican-image-process – erlaubt das Bearbeiten von Bildern beim Erzeugen der Seite
• pelican-alias – damit kann ich Alias-URLs definieren, von denen aus auf die betreffende Page/Post umgeleitet wird

CSS und Schriften

• Pico CSS – tatsächlich verwende ich einen Fork, der zusätzlich Hamburger-Menüs unterstützt
• Libertinus Sans – im Development Mode greife ich auf lokale Dateien zurück, im Production Mode lade ich sie von einem CDN herunter

Werke und Texte

• TODO: alle Sourcefiles für meine Werke und Texte direkt aus der the_works-Datenbank erzeugen

Termine

Das Script utils/refresh-events.py benötigt folgende Python-Packages (alle via pip installierbar):

• caldav
• vobject
• pyyaml (bereits mit Pelican mitinstalliert)

Bildverarbeitung

@TODO: benutze ich das Script überhaupt noch?

Das Script utils/crop_image_to_bbox.py benötigt folgende Python-Packages:

• PIL

Favicon

Um aus einer einzelnen SVG-Datei Favicons in allen nötigen Größen zu erzeugen, nutze ich das Shellscript utils/favicon-from-svg.sh. Es benötigt die folgenden Linux-Packages:

• inkscape
• pngquant
• image-magick

Deployment Tool

• lftp – FTP-Client

Auf dem Produktionsserver

• php (aktuell v8.1)
• PHP-Datenbanktreiber (aktuell pdo_sqlite)
• PHP-Package PHPMailer (im Repository enthalten)

Konfiguration

Das Projekt wird in diesen Dateien konfiguriert:

• pelicanconf.py und publishconf.py – enthalten die Pelican-Konfiguration für Development bzw. Production Mode
• config.ini – enthält die Zugangsdaten für Datenbank und SMTP-Server sowie einige Einträge für die Newsletteran-/-abmeldung und das Kontaktformular; üblicherweise ist diese Datei ein Symlink zu einer Development- bzw. Production-spezifischen Datei
• deploy.ini – Zugangsdaten für den Upload auf den Produktionsserver
• events.ini – Zugangsdaten für den CalDAV-Server

Ausführen

Seite im Development Mode (neu) erzeugen

• make clean – Output-Verzeichnis leeren
• make html – alle HTML-Seiten neu erzeugen, die nicht im Output-Verzeichnis vorhanden sind oder deren Sourcefiles sich seit dem letzten Erzeugen verändert haben
• make regenerate – auf Änderungen in Sourcefiles lauschen und entsprechende Seiten neu erzeugen
• sudo lighttpd -f lighttpd.conf – Test-Webserver starten (Kontaktformular und Newsletteran-/-abmeldung erzeugen POST-Requests, doch der mit Pelican mitgelieferte Webserver verarbeitet nur GET-Requests; ich teste die Seite daher mit lighttpd)
• utils/refresh-events.py – CalDAV-Termine neu einlesen

Seite im Production Mode (neu) erzeugen

• make clean – Output-Verzeichnis leeren
• make publish – Seite mit Produktionsparametern neu erzeugen (liest automatisch Termine neu ein)

Deployment

• deploy-via-ftp.sh – Seite auf den Produktionsserver hochladen

Dokumentation

Aufbau der Webseite

Pelican kennt Artikel und Seiten. Ich verwende diese wie folgt:

• meine einzelnen Werke und News-Posts sind Artikel; alle Sourcefiles liegen in Unterverzeichnissen von content/posts/
  • die Kategorie entspricht der Werksart (Romane, Kurzprosa, Lyrik, Weitere, News); alle Sourcefiles einer Kategorie liegen im gleichnamigen Unterverzeichnis (zB content/posts/romane/)
  • Schlagworte entsprechen (größtenteils) Genres; ich habe aber zB auch englischsprachige Texte per Schlagwort markiert
• alles andere sind Seiten; die Sourcefiles liegen in content/pages/
  • Seiten haben keine Schlagworte auf und üblicherweise auch keine Kategorie
  • nur die Übersichtsseiten der jeweiligen Kategorie gehört ebendieser Kategorie an (so enthält zB content/pages/romane.md die Metadatenzeile category: Romane)

Templates

Alle Templates liegen im Verzeichnis theme/templates/.

Basis

Das Basis-Template ist base.html, so wie es für Pelican üblich ist. Darin werden der grundsätzliche Seitenaufbau festgelegt, HTML-Metadaten gesetzt und Teil-Templates aus dem Unterverzeichnis includes/ eingebunden, in denen wiederkehrenden Seitenelemente definiert sind:

• favicon.html – inklusive HTML-Metadaten
• jumbotron.html – Seitenheader
• navbar.html – NavigationsmMenü
• footer.html – Seitenfooter

Sämtliche First-Level-Templates binden das Basis-Template ein.

Seiten und Artikel

Das Template page.html definiert den Aufbau einer Einzelseite mit statischem Fließtext und wenigen Bildern. Auf diesem Template beruhen zB die Seiten Impressum, Übermich, Datenschutzerklärung oder die Seiten für die Newsletteran- bzw. -abmeldung.

Alle Werke und Texte hingegen verwenden das Template article.html.

Übersichtsseiten

• wide-cards.html – Template der Übersichtsseite über alle Werkskategorien (werke.md)
• cards.html – Template der Übersichtsseiten über alle Werke einer einzelnen Kategorien

Spezielle Seiten

• index.html – Startseitentemplate
• news.html – Template für den Neuigkeiten-Bereich
• tag.html – Template für Schlagwortseiten, auf denen alle Werke aufgelistet sind, die mit dem jeweiligen Begriff verschlagwortet sind
• termine.html – Template für den Terminkalender

Termine neu einlesen

Um die Termine automatisch einzulesen und dem Pelican-Template theme/templates/termine.html zur Verfügung zu stellen, gibt es das Python-Script utils/refresh_events.py. Dieses Script

1. öffnet die Config-Datei events.ini – diese muss im Hauptverzeichnis des Projekts liegen –,
2. öffnet den in der Config-Datei definierten CalDAV-Kalender und liest daraus alle Events ein, die der Kategorie "Veranstaltung" angehören,
3. bereitet die Event-Daten für die Weiterverarbeitung auf
4. und speichert sie im YAML-Format in der Datei content/pages/termine.md.

Im Development-Modus muss refresh_events.py per Hand aufgerufen werden; im Publication-Modus geschieht dies automatisch.

Damit eine Lesung aus dem Kalender auf die Termine-Seite übernommen wird, muss sie folgende Voraussetzungen erfüllen:

1. im richtigen Kalender eingetragen sein (duh)
2. der Kategorie "Veranstaltung" angehören
3. in der Zukunft liegen

Standardmäßig werden alle Properties des "icalender"-Standards eingelesen und als Metadaten abgespeichert; ausgenommen davon sind nur die Properties "action", "repeat" und "trigger". Konkret werden vom Template die folgenden Properties ausgewertet:

• "dtstart": wird vom Script in "startdate" und ggf. "starttime" aufgespalten
• "dtend": wird vom Script zu "enddate" umgewandelt, wenn es vom Startdatum abweicht
• "summary": der Titel der Veranstaltung
• "location": Veranstaltungsort
• "description": zusäzliche Informationen zur Veranstaltung
• bestimmte Einträge in "categories":
  • "Moderation": hängt "(Moderation)" an die Summary an
  • "Babelsberger Lesesalon", "Andere Welten": gibt dem Datumsfeld des Termins die der entsprechenden Veranstaltungsreihe zugeordnete Hintergrundfarbe
• "attach": das Script geht die dem Event angehängten Links durch und stellt dem Template zur Verfügung:
  • max. einen Link zu einer Webseite (als "link")
  • max. einen Link zu einer Bilddatei (als "image")

Zu den Attachments ist Folgendes zu beachten:

• Alle Links, die zu einer Bilddatei verweisen (bei denen der "Pfad"-Teil der URL auf eine Datei mit einer Bilddatei-Suffix, z.B. "jpg", verweist), gelten als Bild-Links. Alle akzeptierten Suffixe sind in der Script-Variable "image_suffixes" definiert.

• Alle Links, die nicht als Bild-Links eingestugt werden, gelten als reguläre Links.

• Wenn mehrere Bild- oder reguläre Links existieren, wird der jeweils letzte verwendet.

• Soll auf eine lokale Bilddatei verwiesen werden, muss der Hostname des "attach"-Eintrags localhost, und eine gleićhnamige Datei muss im Verzeichnis content/images/termine/ vorhanden sein. URL-Schema, -Pfad und Query-Parameter werden nicht ausgewertet. Attachments, die auf Webseiten oder auf Bilddateien auf externen Servern verweisen, bleiben unverändert.

  Beispiele:

  Attachment URL	URL-Typ	aufbereitete URL
  http://localhost/spam/eggs/image.jpg	Bild	../images/termine/image.jpg
  ftp://localhost/image2.png	Bild	../images/termine/image2.jpg
  https://example.com/path/to/image3.png	Bild	(unverändert)
  http://veranstaltungsort.de/kalender/coole-lesung-mit-tobi.html	Link	(unverändert)
  https://127.0.0.1/foo/bar/image4.webp?size=400&height=260	Bild	../images/termine/image4.webp

TODOs

• Seite schneller laden (lazy loading?)
• the_works anbinden, sodass die Werk-Seiten aus der DB automatisch übernommen werden