Netz - Rettung - Recht (Artikel mit Tag webdesign)

Versionierung von Webseiten

nospam@example.com (Thomas Hochstein) — Thu, 05 May 2022 04:20:00 +0000

Bei der Überschrift “Versionierung von Webseiten” könnte man annehmen, dass es in diesem Beitrag um Versionsverwaltungssysteme wie git, SVN, und Co. gehen wird, mit denen eben die Dateien, die eine Website ausmachen, verwaltet werden. Doch dem ist nicht so; ich bin vielmehr dieser Tage auf eine interessante Variante gestoßen, alte Versionen (und vor allem Inhalte) einer Webpräsenz online verfügbar zu halten.

Cool URIs don’t change

“Linkrot” ist eine ständig weiter um sich greifende Pest: zunehmend verschwinden Inhalte aus dem Netz - nicht nur, weil eine Webpräsenz oder ein Blog ganz aufgegeben wird oder sich jemand aus dem WWW zurückzieht, sondern auch, weil ein “Relaunch” erfolgt, eine Webpräsenz also technisch, optisch oder organisatorisch runderneut oder ein Blog auf eine neue Software umgestellt wird, oder weil (insbesondere bei Blogs) ein inhaltlicher Schnitt gemacht und thematisch neu begonnen werden soll. Bedauerlicherweise gehen dann Links auf die bisherigen Inhalte ins Leere - das widerspricht dem Urpinzip des Webs, das ein Hypertext-System darstellt, wie sich schon aus den Bezeichnungen “Hypertext Markup Language” (HTML) oder “World Wide Web” ergibt, und davon lebt, dass Inhalte miteinander verknüpft (und nicht kopiert) werden.

Schon 1998 veröffentlichte Sir Tim Berners-Lee, der “Vater” des Webs, den Aufsatz Cool URIs don’t change, der - mit Ausnahme technischer Implementationsdetails - auch heute noch Geltung hat: Netzadressen sollten so permanent wie nur möglich sein.

Ich habe mich bemüht, das umzusetzen; seit über 20 Jahren setze ich bei jeder Änderung meiner Homepage Redirects von der alten auf die neue Struktur, soweit das irgendwie möglich ist. Ich halte sogar weiterhin einen seit 2005 ungenutzten Account bei inka.de, weil meine Seiten bis Ende 2004 dort lagen und th-h.de nur als Forwarder agierte, so dass verschiedene Links (insbesondere auf alte FAQs und vergleichbare Texte) noch nach dort zeigen. Auch beim Wechsel meines Blogsystem von Sunlog zu Serendipity habe ich nicht nur die Beiträge übernommen, sondern auch durch einen speziellen Forwarder dafür gesorgt, dass auch die meisten alten Links noch funktionieren.

Auf der einen Seite erfüllt das seinen Zweck, auf der anderen Seite wäre es natürlich auch manchmal nett, sich - quasi museal - noch einmal frühere Versionen der Seiten (mit dem alten Design, Theme oder Template, mit der alten Struktur) anschauen und in die Vergangenheit abtauchen zu können. Da kann ich nur mit Screenshots jeweils der Startseite dienen, die einen gewissen Eindruck vermittelt, aber nicht das komplette “Feeling”.

Manches geht über die Wayback Machine des Internet Archive, die man nicht genug loben kann. Manche lassen ihr altes Blog - meistens sind es Blogs und keine ganzen Websites - einfach komplett online und fangen unter einer neuen Domain oder Subdomain neu an.

Versionierung über die Subdomain

Erstmals bin ich jetzt - und damit schaffe ich hoffentlich den Bogen zurück zur Einleitung - auf eine systematische Versionierung gestoßen. Chris Krycho stellt sein aktuelles Blog / seine aktuelle Website unter der URL https://v5.chriskrycho.com/ online. Und wie der Name schon andeutet: die Vorversionen sind (weitgehend) unter https://v4.chriskrycho.com/, https://v2.chriskrycho.com/ und https://v1.chriskrycho.com/ verfügbar. Weil die “Versionsnummer” von Anfang an Teil der URL ist, bleiben alle Links valide, auch wenn später einmal “v8” die aktuelle Version sein wird.

Diese Vorgehensweise hat einerseits - technisch gesehen - Charme. Andererseits ist sie mir, fürchte ich, zu technisch; ich schätze gut gewählte, passende Namen, und wenn ich mein Blog “Sympolymathesy” genannte hätte, dann würde ich auch als URL sympolymathesy.chriskrycho.com haben wollen. Dennoch: eine Variante, über die man nachdenken kann.

Am wichtigsten aber ist: wenn man Content online bringt, den andere verlinken oder den Google findet, dann sollte man nach Möglichkeit dafür sorgen, dass dieser Content auch verfügbar bleibt, so lange das möglich ist.

Titelbild © jro-grafik - stock.adobe.com

FLOSS'n'net - Aktivitäten im Jahr 2021 (und 2020)

nospam@example.com (Thomas Hochstein) — Thu, 30 Dec 2021 06:20:00 +0000

Meine Reihe FLOSS’n’net ist in den letzten fast zwei Jahren auch mehr oder weniger der Pandemie zum Opfer gefallen; der letzte der üblicherweise jedes Quartal veröffentlichen Beiträge datiert vom April 2020 und gehört mit zu den letzten vor der “Aufholjagd” noch veröffentlichten (bzw. verfassten) Beiträgen. Entweder als Schlusspunkt oder als Neubeginn - je nachdem, wie 2022 werden wird … - möchte ich daher einen kurzen Rückblick über das vergangene Jahr (und auch das Jahr 2020) geben.

2020 endeten meine Aktivitäten - vor allem rund um Serendipity - mehr oder weniger im April. 2021 habe ich nichts an Serendipity getan, aber das eine oder andere sonst rund ums Netz. Im Einzelnen sieht das dann so aus:

Serendipity (s9y)

Das Blogsystem Serendipity werkelt auch hinter diesem Blog.

Alle Änderungen hier stammen noch aus dem April 2020.

s9y-Kern

Es ist mir endlich gelungen, einen schwer zu reproduzierenden Fehler zu finden, der mich seit Jahren wahnsinnig gemacht hat. Ich nutze für meine Blogbeiträge recht intensiv “erweiterte Eigenschaften von Artikeln”, also entryproperties, bspw. die HTML-Meta-Description und Social-Media-Bilder - und diese “verschwanden” regelmäßig in vorbereiteten Einträgen, was einerseits ärgerlich ist und andererseits oft unbemerkt bleibt. Das ging so weit, dass ich vorbereitete Einträge (Entwürfe) nicht mehr in s9y selbst gespeichert habe, sondern extern, und sie dann erst zur Veröffentlichung dort hineinkopierte. Das wurde seit 2018 im Issue #577 getrackt, aber ohne richtige Lösung (auch weil mir die Zeit zum Debugging fehlte). Am Ende hatten wir 2019 die richtige Ecke gefunden, aber das Problem nicht wirklich behoben. Das gelang aber jetzt (endlich!), und rückblickend war das eine gute Sache, hatte ich doch im Rahmen der “Aufholjagd” 2020/2021 oft mehrere Dutzend komplett postingfertige Beiträge “gebunkert”.
Scheduled entries lose all entryproperty information on publish date. mit
Fix accidental deletion of extended properties. und
[event_trackback] Draft entries should not be saved in delayed_trackbacks
Eine mit s9y 2.3.3 releaste Änderung hatte ein Designproblem im Code aufgedeckt, das zu Fehlern im Plugin History führte, einem der wenigen mit s9y gebundleten Plugins.
[plugin_history] Fix SQL error in plugin_history.

Plugins

Der Bugfix für die entryproperties erforderte auch Änderungen in den entsprechenden Plugins:
[event_metadesc] [event_social] Fix accidental deletion of extended properties.
[event_trackback] Fix draft check.
Das Plugin, das Sitemaps erstellt, sollte in diese Maps keine Übersichtsseiten für getaggte Artikel aufnehmen, die gar nicht existieren (weil das entsprechende Tag zwar vergeben wurde, aber nur für Entwürfe).
[event_sitemap] Don’t add tag pages with draft tags.

Releases

Ich habe alle geeigneten Änderungen aus der aktuellen Entwicklungsversion in den 2.3er-Zweig übernommen und dann Serendipity 2.3.5 releast sowie die Release-Notes, einen Blog- und einen Forenbeitrag verfasst.

Usenet und Co.

Zum Jahresende 2021 hin habe ich eine notwendige Änderung der Einrichtungsregeln für Newsgroups im deutschsprachigen Usenet vorgeschlagen, die Abstimmung dazu durchgeführt und sie umgesetzt.

FAQs

Ich habe 2020 und 2021 die Pflege weiterer FAQs und vergleichbarer Text übernommen und dann auch regelmäßig eine ganze Reihe Änderungen eingearbeitet:

2020

Übernahme der Newsreader-FAQ
(verfügbar in einem Git-Repository auch mit allen alten Fassungen seit 2000)
Übernahme der Newsserverliste
(verfügbar in einem Git-Repository)

2021

Übernahme der Einrichtungsregeln
(verfügbar in einem Git-Repository)

Moderation von de.alt.netdigest

Zum 01.07.2021 habe ich die Moderation der Newsgroup de.alt.netdigest übernommen.

Sonstiges

Seit April 2021 bin ich einer der Newsmaster von bawue.net.

Relaunch von Webseiten

Nicht nur für die Newsgroup de.alt.netdigest habe ich Webseiten erstellt, sondern auch die Webseiten (und die damit verbundene Hintergrunddtechnik) meines Newsservers und von szaf.org komplett überarbeitet und erneuert.

Vorherige Aktivitäten-Übersicht: I/2020

Wir werden sehen, ob und wie es 2022 weitergeht …

Titelbild © momius - stock.adobe.com

Webseiten für de.alt.netdigest

nospam@example.com (Thomas Hochstein) — Thu, 08 Jul 2021 21:30:00 +0000

Zwar ist das Usenet deutlich älter als das World Wide Web und braucht es - grundsätzlich - auch nicht; dennoch finde ich es hilfreich, Informationen nicht nur im Usenet, sondern auch im Web bereitzustellen. Das Usenet hat seine Stärken in Austausch und Diskussion; für die Bereithaltung (aktueller) Informationen zum Abruf ist es nicht die erste Wahl. Natürlich gab es immer schon FAQs und Infopostings, die regelmäßig (jede Woche, jeden Monat) veröffentlicht werden, damit sie immer in der Gruppe zur Verfügung stehen; natürlich kann man in regelmäßigen Abständen einen Status oder Updates in einer Newsgroup veröffentlichen. Bequemer - solange eine Internetverbindung besteht - und jedenfalls eine sinnvolle Ergänzung ist es aber auch, diese Informationen zusätzlich (ggf. auch in erweiterter Form) online als Webseiten anzubieten.

Daher gibt es jetzt auch eine Website für de.alt.netdigest.

Im Gegensatz zu dem Relaunch der Webseiten um Ostern diesen Jahres herum ist das wieder eine mit dem Webseitengenerator Nanoc erstellte Webpräsenz, diesmal allerdings - im Gegensatz zu meinen anderen Nanoc-basierten Webseiten - auf Grundlage von Bootstrap 5 und daher mit SASS statt LESS. Zudem liegen die Seiten auf einem Server, auf dem bisher Ruby und Nanoc noch nicht installiert waren; der Aufwand war also doch etwas größer, als ich gedacht hatte, zumal es eine ältere Version von Nanoc sein musste, weil die Ruby-Version aus Debian Stable nicht aktuell genug ist. Immerhin aber mal ein schöner Anlass, mich wieder einmal näher mit Nanoc vertraut zu machen, eine passende Rules-Datei zu erzeugen und kleine Helper zu schreiben.

Die Webseiten enthalten (eine weitere) Web-Fassung der auch in der Gruppe geposteten FAQ, einen historischen Überblick über die Geschichte der Gruppe und auf der Startseite eine kurze Einführung einschließlich des Füllzustands der Warteschlange, der bei der täglichen Neuerzeugung der Webseiten ausgelesen wird. Mir gefallen die Inhalte und das - bewusst eher schlicht gehaltene - Design; für Ergänzungen und Kritik habe ich aber natürlich ein offenes Ohr.

[Nachträglich veröffentlicht im Oktober 2021.]

Relaunch der Webseiten von szaf.org

nospam@example.com (Thomas Hochstein) — Fri, 09 Apr 2021 19:05:00 +0000

Wie ich bereits Ende März in meinem Beitrag über die Vorbereitungen zum Relaunch der Webseiten von news.szaf.org angedeutet hatte, ging es dabei nicht nur um eine Präsenz, sondern mehrere miteinander zusammenhängende Angebote. Und so habe ich die letzten Tage damit verbracht, auch die Webseiten von szaf.org auf das neue System umzustellen.

Das Design ist identisch - und soll es auch sein -, die technische Lösung ist weitgehend vergleichbar: wieder gibt es eine Vielzahl aus Markdown mit YAML front matter generierter Seiten, es gibt Benutzerdaten und ein Administrationsinterface mit einer Liste aller Nutzer, hinzu kommen aber weitere Funktionalitäten: teilweise nur Ausgaben aus einer Datenbank (deren Inhalte sich in den letzten 15 Jahren so selten geändert haben, dass es sich nicht lohnt, dafür ein Formular mit der dahinterstehenden Logik anzubieten), aber auch eine Zitatsammlung aus dem IRC und anderen Quellen, die die Ausgabe der Zitate, verschiedene Filter sowie Änderungen und Neuanlagen von Zitaten unterstützen muss. Viel Code ließ sich recyclen (entweder modular oder, wenn projektspezifisch, per copy & paste mit entsprechenden Abwandlungen), und “von außen” sieht alles sehr ähnlich aus (und ja, das war schon vorher so und soll auch so sein):

Der öffentliche Teil von szaf.org.

Mehr als das - und die Login-Seite - bekommt man von außen allerdings auch nicht zu sehen. Mit Login ist die Optik im Wesentlichen der von news.szaf.org vergleichbar. Es gibt aber auch eine schöne Möglichkeit, die neuen “Cards” von Bootstrap zu verwenden, nämlich um eine Übersicht der verschiedenen Dienste zusammenzustellen, jeweils mit Links zu weiteren Informationen:

Ein Ausschnitt aus der Dienste-Übersicht.

Ein paar Webseiten sind noch übrig, die der Umstellung harren, aber insgesamt bin ich sowohl mit dem Ergebnis als auch mit der zugrundeliegenden “Technik” und ihrer Wiederverwendbarkeit sehr zufrieden.

[Nachträglich veröffentlicht im September 2021.]

news.szaf.org: Relaunch abgeschlossen

nospam@example.com (Thomas Hochstein) — Mon, 05 Apr 2021 16:30:00 +0000

Pünktlich zu Ostern habe ich den Relaunch der Webseiten von news.szaf.org abgeschlossen.

Der interne Bereich war schon früh fertig, unterstützt jetzt aber auch (wieder) die Bearbeitung der eigenen Daten:

Der interne Bereich für angemeldete Nutzer.

Nach dem Login wechselt die Login-Box zur Anzeige von Benutzer und Status und bietet einen Logout-Button. Die Benutzerdaten werden angezeigt, Mailadresse und Passwort können geändert werden. Die Navigation links bietet allen Benutzern Links zu den Serverstatistiken und den Benutzungsbedingungen an, aber den Link zur Administration nur den Benutzern mit administrativen Rechten - und nur für die sind diese Seiten auch zugänglich.

Das Administrations-Interface.

Im Administrationsbereich wird eine Liste aller vorhandenen Benutzer angezeigt (Login, Name, Status, letzte Anmeldung am Newsserver - nicht an den Webseiten); mit dem Button am Anfang jeder Zeile können die Nutzerdaten aufgerufen und bearbeitet werden. Das Datum des letzten Logins ist farbig hinterlegt; rot markierte Nutzer haben sich noch nie eingeloggt, gelb markierte zuletzt vor mehr als drei Monaten, grün markierte innerhalb der letzten zwei Tage. Gesperrte Nutzer sind ebenfalls farbig hervorgehoben. Hinter dem Fingerabdruck-Symbol ist ein eindeutiger Code hinterlegt, mit dem sich Postings jedes Nutzers diesem zuordnen lassen. Neue Benutzer lassen sich per Klick auf den entsprechenden Button oben auf der Seite anlegen.

Besonders gefallen mir die Suchfelder für Benutzernamen und Hashes; diese sind mit einer Javascript-Funktion hinterlegt, die auf Eingaben reagiert und alle Zeilen der Tabelle ausblendet, die die entsprechenden Zeichen nicht enthalten. So lässt sich ein bestimmter Nutzer ganz einfach mit wenigen Tastendrücken finden.

Auch im öffentlichen Bereich kam noch eine neue Funktion hinzu, nämlich ein Changelog. Auf der entsprechenden Seite sind diverse Änderungen - meistens neue oder wegfallende Peeringpartner - zusammengestellt. Das allein wäre nichts besonderes; die Seite wird aber aus einzelnen Markdown-Dateien für jede Änderung zusammengebaut, die Datum und Titel im YAML front matter tragen, wobei die Änderungen automatisch nach den Daten sortiert und in eine Navigation aufgenommen werden. Das finde ich sehr praktisch.

Mit dem Ergebnis des Relaunchs bin ich weiterhin sehr zufrieden.

[Nachträglich veröffentlicht im September 2021.]

Relaunch der Webseiten von news.szaf.org

nospam@example.com (Thomas Hochstein) — Tue, 30 Mar 2021 19:00:00 +0000

Seit 2005 betreibe ich einen “richtigen” Newsserver, also einen solchen, der die großen (und ein paar kleine) Hierarchien mit dem Rest der Welt peered und auch für andere Nutzer aus meinem Umkreis zur Verfügung steht: news.szaf.org.

Die zugehörigen Webseiten allerdings, die fast so alt waren, hätten schon lange ein Update vertragen können - weniger inhaltlich als vielmehr optisch und funktionell. Lange stand das auf meiner Todo-Liste, erwies sich dann aber doch als eher größeres Projekt; die Hintergründe habe ich in meinem vorherigen Blogbeitrag beschrieben. Mittlerweile ist das dort beschriebene Projekt veröffentlichungsreif. Ich präsentiere daher die neuen Webseiten für news.szaf.org.

Die aktuellen Webseiten von news.szaf.org.

Ich finde, es ist mir dabei gut gelungen, das bisherige Farbschema und generelle “look and feel” der Seite beizubehalten, aber in eine ansehnliche(re) Form zu transformieren - zum Vergleich die Fassung von 2006:

news.szaf.org früher (seit 2006).

Und natürlich erkennt man die Design-Elemente von Bootstrap; aber zumindest für mich sieht es mehr nach einem optischen Update der bisherigen Seiten als “yet another Bootstrap site” aus.

Auch die Login-Seite ist auf der einen Seite absoluter Standard, wirkt aber andererseits (wie ich finde) trotzdem optisch hübsch:

Loginseite.

Mir jedenfalls gefällt sie sehr.

So hat sich der investierte Aufwand bisher gelohnt.

[Nachträglich veröffentlicht im August 2021.]

Naives MVC

nospam@example.com (Thomas Hochstein) — Thu, 25 Mar 2021 21:20:00 +0000

Seit 2014 setze ich sowohl bei neuen Websites als auch bei der “Renovierung” alter auf static site generators, also Generatoren für statische Webseiten, die aus Templates und Inhalten in verschiedenen Markups, aus Helper-Klassen und ggf. auch Datenbankinhalten HTML-Seiten generieren, die dann auf den Server hochgeladen werden. Das hat verschiedene Vorteile ggü. CMS oder selbstgeschriebenem Code: weil nur statisches HTML ausgeliefert wird, muss auf dem Server keine Scriptsprache wie PHP laufen, was die Last vermindert und vor allem auch aus Sicherheitsgründen angenehm ist, denn wo kein Code läuft, gibt es auch keine Sicherheitslücken. Außerdem bringen Generatoren wie Nanoc, mein bevorzugtes Werkzeug, ein ganzes Toolset wie Helper-Klassen für häufige Aufgaben und Filter für die verschiedensten Markup-Formate mit. So habe ich mich daran gewöhnt, dass ich das Grundgerüst einer Website in Form von Templates, meistens in HAML, erstelle, für die optische Gestaltung CSS-Frameworks wie Bootstrap nutzen kann, wobei ein LESS-Compiler automatisch mitkommt, und dass ich die eigentlichen Inhalte in Markdown (oder in einer Kombination aus HAML und Markdown) erstellen kann. Auf diese Weise habe ich mir einen gut funktionierenden Workflow geschaffen.

Das alles erfüllt seinen Zweck im Grundsatz sehr gut, auch für in begrenztem Umfang dynamische Elemtente: es genügt ja, die Webseitengenerierung in regelmäßigen Abständen neu anzustoßen, bspw. nachts, oder wenn man will auch stündlich. Nanoc kann man zudem aus Datenbanken speisen, und auch beim bloßen Umgang mit Textdateien lassen sich deren Metadaten auswerten, um bspw. die letzten Änderungen zu verlinken, Termine anzukündigen (aber nur, solange sie noch bevorstehen), Zeitangaben automatisch zu ersetzen (“Diese Seiten stehen schon seit x Jahren online”) und anderes mehr. Man kann auch mal ein PHP-Script dazwischenmixen, beispielsweise für ein Kontaktformular. Ihre Grenzen erreicht die Technik erst, wenn es um tatsächlich dynamische Seiten geht, also bspw. die Suche in Datenbanken (bei der man die Einträge nicht schlicht insgesamt vorab als statische Seiten erzeugen kann) - oder wenn ein Passwortschutz (jenseits von Basic Auth) oder ein Session-Management implementiert werden soll. Dann braucht es etwas anderes. Nur was?

Bestimmt fünf Jahre lang habe ich die Überarbeitung verschiedener Webseiten vor mir hergeschoben, deren Anforderungen über die Möglichkeit von static site generators hinausgehen. Der ursprüngliche Ansatz aus meinen ersten (und zweiten) Schritten mit PHP - jede Seite ein Mix von HTML und PHP, letzteres vor allem Funktionen zum Generieren der Seitenstruktur (Header, Footer) und Navigation als “Templating für Arme” - kam natürlich nicht mehr in Betracht; natürlich machen allein Templates in diesem Zusammenhang Sinn. Aber ich wollte die Inhalte auch nicht mehr in HTML verfassen, sondern zumindest in Markdown; und ein CSS-Baukasten wie Bootstrap sollte sich auch einbinden lassen, was einen Preprocessor wie LESS oder SASS zumindest wünschenswert macht. Über die Jahre habe ich mit vielen Gedanken gespielt, bspw. an Frameworks wie Laravel oder Symfony; früher hatte ich über viele Jahre die CakePHP-Mailingliste abonniert. Das erschien mir dann aber doch vergleichsweise aufwendig, um letztlich einen Passwortschutz und ein paar Formulare bzw. Datenbankausgaben zu implementieren.

Nach langer Pause und Stagnation wollte ich das Thema dieses Jahr über die Osterzeit aber noch einmal angehen. Dazu gehörten mehrere Schritte: Zunächst waren einige eng verbundene Webseiten zu entkoppeln, die gemeinsame Ressourcen nutzten, also bspw. alle dieselbe CSS-Datei eingebunden hatten. Danach brauchte es ein Design, das optisch den bisherigen Webseiten ähnlich sein sollte, nur schicker und möglichst unter Verwendung von Bootstrap - und dafür wiederum musste ich mich mit Bootstrap 5 auseinandersetzen (meine bisherigen Webseiten setzen alle noch auf die Version 3 auf), und dafür wiederum von LESS auf SASS wechseln. Der wiederum nächste Schritt wäre dann ein PHP-basiertes Templating-System, und dann musste all das zusammengesetzt und um die notwendige Funktionalität erweitert werden.

Bootstrap 5 und SASS

Bootstrap 5 erwies sich als gar nicht so anders; klar, das Grid ist neu und setzt auf Flexbox, es gibt einen Haufen Utility-Klassen für Abstände und bei den Komponenten hat das neue “Card”-Element einige bisherige Elemente ersetzt, aber die einzige Neuerung mit Umstellungs- und Änderungsbedarf war der Wechsel von LESS als CSS-Preporzessor zu SASS.

Ich habe also zunächst die Quell-Dateien heruntergeladen und mich damit vertraut gemacht und mir dann eines der Beispiele ausgesucht, um davon ausgehend einen groben Design-Entwurf zu puzzeln. Das war dann auch der Zeitpunkt, wo ich einen SASS-Compiler brauchte. Das erwies sich als überraschend einfach: Dart Sass bietet Pakete für Windows an. Herunterladen, dart.exe und sass.snapshot in ein bin/-Verzeichnis packen, eine Batch-Datei mit bin/dart.exe bin/sass.snapshot mein.scss mein.css ins Hauptverzeichnis des Projekts, und schon kann ich aus mein.scss eine CSS-Datei zaubern. In der .scss-Datei importiere ich dann die notwendigen Bootstrap-Komponenten (oder auch einfach alles), ggf. weitere Elemente (wie Font Awesome), passe Variablen an (insbesondere das Farbschema), ergänze eigenes CSS - et voilá. Und all das kann ich dann direkt lokal auf meinem unter Windows laufenden Entwicklungsrechner testen: Änderungen vornehmen, Build-Script starten, HTML-Datei im Browser neu laden - und ggf. von vorne.

Eine solche .scss-Datei kann dann beispielsweise so anfangen:

/* --------------------------------------------------------
 *  SCSS styles and Bootstrap import
 */

// custom variables
$primary:   #314e8c;
$secondary: #bad1e1;
$info:      #ced4da; /* gray-400 */
$body-bg:   $secondary;

// import from Bootstrap
@import "bootstrap/scss/bootstrap.scss";

// import from FontAwesome (Solid)
@import "fontawesome/scss/fontawesome.scss";
@import "fontawesome/scss/solid.scss";

// custom SCSS
/* --------------------------------------------------------
 * Text elements
 */

h1, h2, h3, h4, h5, h6 {
  color: $primary;
}

Damit werden die gewünschten Primär- und Sekundärfarben gesetzt, die ich aus dem bisherigen Design übernommen habe, die Farbe für “Info”-Boxen auf einen Grauton umgestellt und der Hintergrund in der Sekundärfarbe eingefärbt. Dann ziehe ich das komplette Bootstrap-Framework und Font Awesome als Webfont ein (hier kann man sich natürlich auf die Elemente beschränken, die man nutzt; das macht alles schlanker), und danach folgen die Anpassungen und eigenen Elemente. So färbe ich bspw. die Überschriften gerne in der Primärfarbe der jeweiligen Website ein.

Das war, ehrlich gesagt, im Ergebnis dann sehr viel einfacher als ich befürchtet habe, und es gelang mir überraschend schnell, ein brauchbares Mockup zu erstellen. Feinheiten folgen dann, wie immer, sobald sie für bestimmte Elemente oder Situationen benötigt werden.

Den ganzen Kram - Bootstrap-Quellcode, Font-Awesome-Quellcode, die ausführbaren Dateien von Dart Sass und meine .scss-Datei - habe ich natürlich in ein Git-Repository gepackt. Dabei haben sowohl Bootstrap als auch Font Awesome als auch Dart Sass jeweils nach dem initialen Einkopieren der Dateien einen eigenen Branch erhalten. Wenn ich nun bspw. eine neue Bootstrap-Version einspielen will, genügt es, den Bootstrap-Branch auszuchecken, die neuen Dateien einzukopieren und ihn in den Master-Branch zu mergen. So sehe ich sofort alle Änderungen und kann ggf. Anpassungen vornehmen.

Die am Ende dieser Operationen erzeugte mein.css-Datei kann ich dann jeweils in das Repository (oder die Repositories) für den Quellcode der einzelnen Webseiten einkopieren.

Templates

So weit, so gut. Im nächsten Schritt sollte ich dann aus dem Mockup ein Template machen, in das sich Inhalte einbinden lassen. Davor bedarf es aber eines Template-Systems, das diesen Schritt (Template laden, mit Inhalten füllen) technisch umsetzt.

Für eine simple interne Seite - Erzeugen von Mailboxen und Mailadressen über ein Webinterface - hatte ich 2017 bei der Renovierung des ursprünglich aus dem Jahr 2009 stammenden Codes auf Plates, ein einfaches PHP-Templating-System, gesetzt. Zusammen mit Bootstrap sah das hübsch aus und war funktional, wenn auch vielleicht von der Funktionalität her eher überschaubar. So richtig wollte das aber nichts werden; schon das Einbinden machte mir Schwierigkeiten, und mit dem Templating-System wurde ich ebenfalls nicht warm.

Also dachte ich mir, warum nicht etwas verwenden, von dem ich weiß, dass es sich anderswo bereits bewährt hat? So habe ich mich dann für Smarty entschieden, denn was für Serendipity gut ist, kann für ein simples Projekt nicht schlecht sein. Außerdem kann ich dann das, was ich lerne, direkt noch anderswo zum Einsatz bringen. Das funktionierte dann auch direkt sehr schön, zumal Smarty das Einbinden von Teil-Templates (Partials) in Templates unterstützt; man kann sich also das endgültige Template aus wiederverwertbaren Bausteinen zusammenstückeln. Einen Wermutstropfen gibt es freilich: die Templates sind kein HAML, sondern HTML und Smarty, aber das passt - so viele Templates braucht man ja in der Regel nicht.

Wichtiger war mir, die Inhalte nicht komplett als HTML verfassen zu müssen; Markdown ist da meine Standardlösung. Und wenn ich mich schon an Serendipity bediene, warum dann nicht auch hier? Das Markdown-Plugin dort nutzt PHP Markdown, und das lässt sich natürlich auch sehr schön in meinem Projekt verwenden.

Model-View-Controller

Jetzt mussten alle diese Einzelteile “nur noch” sinnvoll zusammengeführt werden. In meinem schon angesprochenen Plates-Projekt hatte ich für jede Webseite weiterhin jeweils eine gesonderte PHP-Datei, die im Prinzip aber nichts anderes machte, als das Template aufzurufen und mit Inhalten zu füllen. Außerdem gab es für jede Seite dann ein gesondertes Template, dass auf ein Standard-Template aufsetzte. Das kann aber natürlich nicht die Lösung sein. Nicht nur Serendipity macht das anders: im Prinzip gibt es primär eine PHP-Datei, nämlich eine index.php im Webroot, die als Parameter die jeweils anzuzeigende Webseite übergeben bekommt und sich dann um den Rest kümmert.

Im Grundsatz ist das ein Model-View-Controller-Pattern, kurz MVC. Das Model liefert die Daten, sorgt also in einer Applikation üblicherweise für die Abbildung in einer Datenbank. Views sind die Präsentation, die Templates, die mit Inhalten gefüllt werden. Und der Controller führt beides zusammen. Natürlich kann man das mehr oder weniger ausgefeilt betreiben; mir genügte eine weniger ausgefeilte Lösung, die bspw. einzelne Aktionen im Controller nicht in Funktionen auslagert, sondern im Kern auf ein langes switch-Statement setzt. Immerhin enthält der Großteil der Webseiten primär einmal Text, der angezeigt werden muss; ich will ja keine Webapp schreiben.

Am Anfang steht die Frage, wie man die anzuzeigende Webseite als Parameter übergeben möchte. Eine URL wie https://meine-website.example/index.php?page=about/contact sieht ja wirklich hässlich aus und ist auch unter SEO-Gesichtspunkten keine gute Idee. Stattdessen möchte ich gerne URLS wie https://meine-website.example/about/contact/ haben. Hier kommt mod_rewrite zu Hilfe:

RewriteEngine On
# rewrite URLs to controller
RewriteCond %{REQUEST_URI} !^/.well-known
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ /index.php?page=$1 [QSA,L]

Die erste der beiden Bedingungen sorgt dafür, dass alle Aufrufe in das Verzeichnis /.well-known/ nicht umgesetzt werden; das ist bspw. erforderlich, damit certbot von Let’s encrypt seine Aufgaben erfüllen kann. Die zweite sorgt dafür, dass tatsächlich physisch vorhandene Dateien angezeigt werden. So lassen sich bspw. Textdateien oder Downloads unterbringen, die “as is” ausgeliefert werden sollen. Die darauffolgende Regel schnappt sich den Pfad - im Beispiel also about/contact/ - und ruft die index.php mit diesem Pfad als Parameter auf. Damit lässt sich arbeiten.

Im zentralen PHP-Script wird dieser Pfad dann zunächst normalisiert (damit er mit oder ohne abschließenden Slash “/” zur selben Seite führt) und auf unerwünschte Zeichen geprüft, damit nicht böse Menschen versuchen, unerwünschte Pfade (../../../../etc/passwd) zu übergeben. Der Rest des Scripts arbeitet dann mit diesem Pfad weiter. Dazu wird eine weitgehend aus Smarty abgeleitete Controller-Klasse benutzt, die ein Template-Objekt erzeugt und mit Variablen befüllt; wo erforderlich, steht eine spezialisierte Datenbank-Klasse bereit, die spezifische Funktionen für alle erforderlichen Lese- und Schreib-Operationen bereithält. Für das Session-Management konnte ich auf eine bestehende PHP-Klasse aus dem Jahre 2011 zurückgreifen, die ich damals für ein anderes Projekt geschrieben und bewusst modular aufgebaut hatte; tatsächlich war sie 10 Jahre später mit kleinen Anpassungen - vor allem in bisher nicht oder kaum genutzten Codepfaden - sofort verwendbar. Auth- und Controller-Klasse lassen sich modular wiederverwenden, die Datenbank-Klasse ist weitgehend projektspezifisch.

Den Hauptteil der index.php bildet dann tatsächlich ein langes switch-Statement, das für bestimmte Seiten spezifischen (Datenbank-)Code enthält, in den meisten Fällen aber auf default zurückfallen und schlicht eine Markdown-Datei in HTML konvertieren, in ein Template einsetzen und dann anzeigen kann.

Verzeichnisstruktur

Die Verzeichnisstruktur des Projekts sieht im Grundsatz so aus:

\___ source/
 \
  \__ data/
   \
    \__ web/

Das web-Verzeichnis ist das Webroot; dort finden sich die index.php, die Unterverzeichniss mit CSS, Javascript, Webfonts, Bildern und Icons und die Downloadverzeichnisse, also alles, was “as is” ausgeliefert werden soll.

In source liegen die Module und externen Elemente: Smarty, PHP Markdown Extra, meine eigenen Module und eine Konfigurationsdatei, die etliche Variablen setzt (bspw. für die Datenbankanbindung) und zugleich alle notwendigen Elemente einbindet.

data schließlich enthält zum einen die Templates (also die typischen Smarty-Verzeichnisse wie templates, templates_c, cache und Co.) und zum anderen im Verzeichnis content die eigentlichen Inhalte in Form von Markdown-Dateien in einer Verzeichnisstruktur, die der der Webseite entspricht. Der Inhalt, der nach Aufruf von https://meine-website.example/about/contact/ angezeigt werden soll, liegt also in data/content/about/contact.md.

Umsetzungsbeispiele

$controller = new Controller($config);
$controller->assign('page',$page);

Auf diese Weise wird ein neues Controller-Element erzeugt, dass den Inhalt des Arrays $config (aus der zentralen Konfigurationsdatei) und die anzuzeigende Seite ($page) in Smarty verfügbar macht. Die assign-Methode akzeptiert entweder ein Array oder - wie im Beispiel - ein Tupel aus Schlüssel und Wert.

# create pages from Markdown/YAML
$yaml = $controller->create_from_md($page);

Diese Funktion liest eine Datei ein, konvertiert das enthaltene Markdown in HTML und kann YAML front matter verarbeiten, also YAML, das als Vorspann (eingefasst in ---) in einer anderen Datei enthalten ist. Diese Inhalt werden in Smarty als Variablen bereitgestellt.

Die technische Umsetzung der Funktion create_from_md() ist im Kern wirklich einfach:

# parse YAML and copy to Smarty
$yaml = yaml_parse_file($content_file);
$this->template->assign($yaml);

# parse Markdown, ignoring YAML front matter, and assign to content
$this->template->assign('content',Michelf\MarkdownExtra::defaultTransform($this->read_ignore_frontmatter($content_file)));

# return YAML metadate
return $yaml;

Die PHP-Funktion yaml_parse_file() kann YAML front matter verarbeiten und ignoriert den Rest. Die selbstgeschriebene Funktion read_ignore_frontmatter() ist das Gegenstück dazu; sie sorgt dafür, dass beim erneuten Einlesen der Datei diesmal das YAML front matter übersprungen und nur der Markdown-Teil verarbeitet wird. Danach werden die eingelesenen YAML-Daten zurückgegeben und stehen daher nicht nur im Smarty-Template, sondern auch für den PHP-Code zur Verfügung.

Auf diese Weise können beispielsweise Titel und Beschreibung der Seite, der Autor usw. übergeben werden. Für die (wenigen) Seiten, die nicht nur aus Markdown bestehen, sondern weitergehende Funktionalität enthalten, werden diese Daten als Array in der index.php definiert. Jede Webseite besteht also entweder aus einem speziellen Smarty-Template mit zusätzlichem Code in der index.php oder aus dem Inhalt einer Markdown-Datei, die in das Default-Template eingesetzt wird.

# check for protected pages
if(isset($yaml['login'])) $auth->check_session();

Wenn im YAML-Vorspann login gesetzt ist, wird geprüft, ob ein berechtigter Benutzer eingeloggt ist; ansonsten erfolgt die Umleitung zur Anmeldeseite.

# display template
$controller->display('index.tpl');

Am Schluss wird das mit Inhalt gefüllte Template angezeigt.

Ein paar Worte zum Schluss

Das Konzept stand natürlich nicht von Anfang an in der hier präsentierten Form, sondern ist dynamisch gewachsen - so gab es zunächst nur Smarty-Templates, dann kam die Möglichkeit von Markdown-Dateien hinzu, und noch später das Parsing von YAML front matter. Und natürlich waren viele Tests und etliche Iterationen über einige Abende und ein langes Wochenende notwendig - aber am Ende war ich überrascht, erfreut und beeindruckt, mit wie vergleichsweise geringem Aufwand sich ein solches doch (für meine Verhältnisse) einigermaßen komplexes Projekt umsetzen lässt. Frei verfügbare externe Projekte und Frameworks - Smarty, PHP Markdown, Bootstrap, SASS und natürlich am Ende auch PHP selbst -, eigene kleine Module und ein bißchen Klebstoff, um das alles miteinander zu verbinden, dazu ein altes Design zum Aufhübschen und die bestehenden Inhalte, die ergänzt und übernommen werden, sind eine ebenso mächtige wie vielseitige Kombination.

[Nachträglich veröffentlicht im August 2021.]

Titelbild © pripir - stock.adobe.com

Der Teufel steckt im Detail

nospam@example.com (Thomas Hochstein) — Thu, 23 Apr 2020 06:15:00 +0000

Vor einigen Tagen hatte ich berichtet, wie sich mithilfe der <details>- und <summary>-Elemente von HTML 5 ganz leicht “ausklappbare” Erläuterungen - nur mit HTML und ggf. CSS, ohne Javascript - erzeugen lassen. Danach ist mir aufgefallen, dass wir - also vor allem vermutlich yellowled - das in Serendipity auch schon nutzen: im 2k11-Theme wird damit im Blog die einblendbare “Vorschau” der Trackback realisiert, und im Backend findet derselbe Mechanismus bei der Einblendung weiterer Informationen in den Plugin-Boxen Anwendung.

In einem Kommentar zu meinen Blogeintrag hatte Beat dann vorgeschlagen, statt der Screenshots doch lieber ein Live-Beispiel im Blog zu zeigen. Das wollte ich dann “mal eben schnell” nachholen - und natürlich ging das dann nicht “mal eben”, und nicht richtig schnell, so dass ich daran dann länger geknobelt habe. Mittlerweile tut es aber.

`<details>` und `<summary>` in der Praxis

Lorem ipsum!

Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.

Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat,
vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan
et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi.

Der “Quellcode” dafür sieht wie folgt aus (mit serendipity_event_markdown und Markdown Extra, damit Markdown auch innerhalb von HTML geparsed werden kann):

<details markdown="1"><summary>Lorem ipsum!</summary>

Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.

* Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat,
* vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan
* et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi. 

Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.

</details>

Natürlich geht das auch ohne Markdown; dann müsste man eben bspw. komplett HTML verwenden, etwa so:

<details><summary>Lorem ipsum!</summary>
<p>Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.</p>
<ul>
<li>Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat,</li>
<li>vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan</li>
<li>et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi.</li>
</ul>
<p>Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.</p>
</details>

So weit, so gut; es passen auch Listen und alles mögliche anderen Elemente in einen <details>-Abschnitt.

Das ganze hat allerdings, wie schon geschildert, nicht ganz auf Anhieb geklappt.

Anpassungen am CSS

Initial war kaum erkennbar, dass dort etwas “ausklappbar” ist; es fehlte nämlich das typische “Dreieck” vor dem summary. Das liegt daran, dass das Stylesheet von 2k11 für das <summary>-Element im Frontend display: block; vorsieht, es also nicht als Liste anzeigt. Es dürfte zu erwägen sein, das auf die Darstellung der Trackbacks zu begrenzen. Bis dahin kann man in einem User-Stylesheet (user.css) Abhilfe schaffen, zum Beispiel so:

/* restore browser defaults for details & summary */
.content details > summary:first-of-type {
  display: list-item;
  counter-increment: list-item 0;
  list-style: disclosure-closed inside;
}

.content details[open] > summary:first-of-type {
  list-style-type: disclosure-open;
}

.content details > summary:first-of-type > *|* {
  /* Cancel "list-style-position: inside" inherited from summary. */
  list-style-position: initial;
}

Das entspricht dem Browser-Stylesheet des Firefox.

Update vom 25.04.2020: Die vorstehende Änderung ist nicht mehr nötig, weil das Stylesheet von 2k11 mit der Version 2.3.5 von Serendipity entsprechend angepasst wurde.

Außerdem finde ich persönlich es schick, wenn die Überschrift des <details>-Elements, also <summary>, durch Fettschrift hervorgehoben und das gesamte Element etwas kleiner (und mit verringertem Zeilenabstand) dargestellt wird. Dementsprechend müssen dann auch die Abstände zwischen den Absätzen kleiner sein. Außerdem möchte ich nicht, dass der “ausklappbare” Bereich bzw. - solange nichts ausgeklappt ist - die Überschrift nach innen eingerückt sind; beides soll vielmehr auf der linken Seite bündig abschließen. Das alles habe ich im user.css so gelöst:

/* details & summary */
.content details {
    font-size: 80%;       
    line-height: 1.6em;   
    padding-left: 1em;
}

.content details > summary {
    font-weight: bold;
    margin-left: -1em;
    margin-bottom: 0.5em; 
}

.content details p, 
.content details ul,
.content details ol {
    margin-bottom: 0.2em;
}

Anpassungen am Markdown-Plugin bzw. an PHP Markdown

Die Darstellung sah immer noch nicht richtig aus; eine genauere Betrachtung ergab, dass um die einzelnen Teile des <details>-Elements <p>-Elemente verstreut waren. Das kann nicht richtig sein; ich hielt erst serendipity_event_nl2br für den Bösewicht, es stellte sich aber heraus, dass der Fehler in Wahrheit im Markdown-Parser von serendipity_event_markdown lag. Trotz Probieren ließ sich dafür keine Abhilfe schaffen; also musste ich einen Blick in die Innereien von PHP Markdown werfen - das ist die Bibliothek, auf die das Markdown-Plugin aufsetzt.

Offenbar wurde <details> im Gegensatz zu bspw. <pre> nicht als Block-Level-Element erkannt. Die Lektüre im Issue-Tracker des PHP-Markdown-Projekts ergab Hinweise auf eine mögliche Lösung, die ich dann getestet und umgesetzt habe. Die Änderung wurde bereits in den PHP-Markdown-Code übernommen. Um nicht auf ein neues Release warten zu müssen, habe ich die Änderungen direkt in die Code-Kopie in unserem Markdown-Plugin kopiert, so dass sie für Serendipity direkt nach dem Update des Plugins zur Verfügung stehen.

Nun funktioniert’s in meinem Blog so, wie das sein soll.

Wer einen “grafischen” WYSIWYG-Editor verwendet, muss ggf. darauf achten, dass dieser <details> und <summary> erkennt und nicht ausfiltert. Ob der mit Serendipity ausgelieferte Editor das kann, weiß ich nicht, weil ich ihn nicht verwende (und bislang den Code des Editors auch nicht recht durchschaut habe).

Danke jedenfalls nochmal an Beat für seinen Vorschlag, das direkt im Blog zu demonstrieren, wenn die Umsetzung auch mehrere ungeplante “Abstecher” nach sich zog.

Titelbild © pripir - stock.adobe.com

Details - ganz einfach

nospam@example.com (Thomas Hochstein) — Tue, 21 Apr 2020 06:00:00 +0000

Meistens ist es so: Ich habe eine Idee, die ich gerne auf einer meiner Webseiten umsetzen würde - sei es, dass ich das irgendwo anders gesehen habe und diese Funktion auch gerne hätte, sei es, dass mir ein eigener Gedanke gekommen ist. Dann recherchiere ich und stelle fest: das ist alles ziemlich kompliziert. Klar, wenn man HTML einigermaßen, CSS oberflächlich und JS gar nicht beherrscht, ist man zumeist auf copy&paste oder viel Ausprobieren angewiesen, und der Teufel steckt ohnehin immer im Detail.

Manchmal aber ist es auch umgekehrt: ich mache mich auf, um nach Lösungen zur Umsetzung einer Idee zu suchen - und finde heraus, dass eigentlich gar nichts mehr umzusetzen ist, weil alles schon fertig ist. So ging es mir bei einer meiner letzten Ideen, als ich eine Möglichkeit suchte, weitergehende Erläuterungen in einem längeren Text erst auf Wunsch einzublenden.

Das Prinzip ist nicht neu (und aus manchen Lehrbüchern und Kommentaren vertraut): Wichtige Begriffe werden drucktechnisch hervorgehoben, sei es durch Fett- oder Kursivdruck, sei es gar durch Randsymbole oder Kästchen. Auf der anderen Seite gibt es aber auch Details, die zum Verständnis nicht unbedingt erforderlich sind, aber weitergehende Hintergrundinformationen zur Vertiefung liefern, die nicht jeden Leser interessieren. Üblicherweise werden diese Abschnitte in einer kleineren Schriftgröße mit verringertem Zeilenabstand gedruckt - das Kleingedruckte, quasi.

Wie überträgt man dieses Konzept in die digitale Welt? Der Beck-Verlag, der in seinem Online-Dienst beck-online bereits seit Jahren juristische Kommentare als reine Onlineversionen anbietet (“Beck’sche Online-Kommentare”, kurz BeckOK), kombiniert in der sog. “Detail-Ebene” die kleinere Schriftgröße und den verringerten Zeilenabstand mit dem Ausblenden der Hintergrundinformationen - eine gute Idee, finde ich.

Das würde ich gerne für längere Texte übernehmen.

Mein erster Gedanke war, dass sich dafür eine Javascript-Lösung anbieten würde, mit der man beim Anklicken einen vorher per CSS auf visibility: hidden gesetzten Bereich sichtbar macht. So etwas müsste es ja eigentlich bereits in fertiger Form geben, dachte ich mir, und suchte bei Google nach “css details ausklappen”. Nur um festzustellen, dass es im Prinzip gar keiner Javascript-Verrenkungen bedarf: HTML 5 kennt ein details-Element! Und das funktioniert im Prinzip ganz genau so, wie ich mir das denke:

<!-- https://wiki.selfhtml.org/wiki/HTML/Interaktiv/details -->
<details>
  <summary>
    Hintergrundinformationen
  </summary>
  <p>
    Das neue &lt;details&gt;-Element ermöglicht es, ganz ohne den Einsatz von JavaScript,
    ursprünglich verborgene Textinhalte aufzuklappen.
  </p>
</details>

Will man den Text standardmäßig eingeblendet, aber ausblendbar haben, ergänzt man im details-Element noch ein open:

<details open>
  [...]
</details>

Natürlich kann man das ganze noch mit etwas CSS stylen, aber im Prinzip ist das ganz genau das, was ich will. Und am besten: das Konzept ist viele, viele Jahre alt und wird mittlerweile breit von Browsern unterstützt. Auf der praktischen Website Can I use …? lässt sich nachvollziehen, dass die entsprechende Untersützung in Firefox (seit Version 49 von 2016), Chrome (im Prinzip seit Version 12 von 2011, vollständig seit Version 36 von 2014) und Safari (im Prinzip seit Version 6 von 2012, vollständig seit Version 12 von 2018) in auch nur halbwegs aktuellen Versionen vorhanden ist. Auch bei den mobilen Browsern unter iOS und Android sieht es gut aus. Problemkind ist wie immer Microsoft - aber die aktuellsten Versionen von Edge (leider erst seit Anfang 2020) untertützen das Element auch. Immerhin > 93% der Nutzer, so die Seite, sollten insofern mit dem Element klarkommen.

Wer auch für die restlichen 7% vorsorgen will, kann das mittels eines Polyfills tun. Beschreibungen dazu sind im SELFHTML-Wiki und im Modernizr-Github-Wiki verlinkt.

Das war mal ausnahmsweise eine angenehm schnelle Lösung für ein Problem!

Goodbye, JUHMAIL

nospam@example.com (Thomas Hochstein) — Thu, 09 Jan 2020 09:00:00 +0000

Ich bin nicht besonders gut darin, Dinge aufzugeben - aber immerhin habe ich 2019 damit begonnen, einige alte Projekte, die sich lange überlebt haben, zu beenden. Im September war das KRG-online, die Ehemaligen-Seiten meiner alten Schule (deutlich älter als Stayfriends und Konsorten), zum Jahreswechsel ist es mein wohl ältestes Projekt: die 1997 gestartete JUH-Mailingliste JUHMAIL und die zugehörigen Webseiten.

Das war fast zwei Jahrzehnte lang das Design der JUHMAIL-Webseiten.

Während der letzten Jahre meiner Schulzeit und durch mein Studium hindurch war ich sehr aktiv bei den Johannitern bzw. der Johanniter-Unfall-Hilfe, einer der großen deutschen Hilfsorganisationen, noch bevor ich online aktiv wurde. Was lag da näher, als zum Zwecke der Diskussion und Vernetzung (und nach dem Vorbild anderer Organisationen) eine Mailingliste einzurichten? Nach dem Beginn als GMX-Verteilerliste und einen Monat später im Batch-Betrieb auf dem heimischen Rechner wechselte die Liste noch im ersten Jahr ihres Bestehens auf den Majordomo-MLM meines damaligen Providers, einer Regionaldomain des Individual Network. Wiederum ein Jahr später (1999) kamen dann Webseiten hinzu, zunächst mit einer Beschreibung der Liste und einem Formular zur Anmeldung sowie einem passwortgeschützten Bereich mit (von Hand gepflegter) Mitgliederliste, Webarchiv der Mails und einem Downloadbereich für Dateien, anfänglich alles manuell betrieben. Im Verlauf der nächsten Jahre wurde das Angebot professionalisiert: Mitgliederliste, Downloadbereich, Linkliste, Terminkalender und Kleinanzeigenmarkt waren datenbankgestützt, An- und Abmeldung bei der Mailingliste funktionierten über die Webseiten, weil das für viele einfacher war als kryptische Kommandos per Mail zu schicken, und ab 2001 wurde das ganze auch optisch ansehnlicher gestaltet.

So sah die erste Version der JUHMAIL-Webseiten 1999/2000 aus.

Die Webseiten waren allerdings das Ergebnis meiner ersten Gehversuche mit PHP, und in den kommenden Jahren kamen zwar immer mal wieder Neuerungen dazu - so unter anderem eine komplette Datenbank aller Standorte der Organisation mit hierarchischer Einbindung (Ortsverband, Kreisverband, Landesverband) und der Möglichkeit, die Adressdaten, Angebote und verantwortliche Mitarbeiter (wiederum mit Adressdaten) durch den Verband selbst zu pflegen -, es gab aber - obschon oft geplant nie eine wirkliche Überarbeitung oder eine Umstellung auf einen zeitgemäßeren MLM wie bspw. Mailman. Und so alterte alles vor sich hin; im Laufe der Zeit (in den 10er-Jahren) änderten sich dann auch Nutzungsgewohnheiten und Kenntnisse der Nutzer: Mailinglisten sind heute in der Breite ein völlig unbekanntes Kommunikationsmedium.

Ich erwog zwischendurch, den Relaunch zugleich mit einer Ergänzung oder gar Umstellung des Kernmediums von einer Mailingliste zu einem Webforum zu verbinden oder gar beides miteinander (und einem Newsserver) zu kombinieren, wie bspw. im - mittlerweile ebenfalls eingeschlafenen bzw. seit 2018 abgeschalteten - Syncom-Projekt der Piratenpartei. All das dauerte aber seine Zeit, und mit den Jahren wurde mir bewusst, dass ich mittlerweile gar nicht mehr der Richtige wäre, ein solches Medium für eine Hilfsorganisation zu betreiben, bei der ich nicht mehr wirklich aktiv bin.

Der logische Schritt war daher die Abschaltung, die ich zum 31.12.2019 dann vollzogen habe.

Eine moderne Adaption des Designs für die Platzhalterseiten.

Aber jedes Ende ist natürlich auch ein neuer Anfang; so brachte die Ankündigung der geplanten Einstellung viele schöne Erinnerungen, weil seit Jahr(zehnt)en nicht mehr gehörte Aktive und Mitstreiter aus der Anfangszeit das zum Anlass nahmen, sich noch einmal zu melden, und ich habe so auch den zeitgemäßen Nachfolger meines Projekts kennengelernt: 4juh, ein auf COYO basierendes “Social Intranet”, das dankenswerterweise diesmal ein Projekt der Organisation selbst ist. Und die Ressourcen eines “Vereins” mit mehr als einer Milliarde Jahresumsatz sind natürlich ganz andere als die eines einzelnen Ehrenamtlichen. Es freut mich zu sehen, dass sie - auch - in ein zeitgemäßes Kommunikationsmedium fließen, das neben den Mitarbeitern auch die Ehrenamtlichen einbindet.

Und so hat alles auch sein Gutes.

Man muss auch loslassen können

nospam@example.com (Thomas Hochstein) — Tue, 10 Sep 2019 13:30:00 +0000

Meine spärliche Freizeit teile ich schon lange, vielleicht zu lange auf viele, vielleicht zu viele Hobbys und Projekte auf; und demzufolge gibt es immer etwas, was ich eigentlich schon lange, lange einmal angegangen sein wollte. Und trotz aller Erfolge wächst die Projektliste eher als sie schrumpft.

Außerdem fällt es mir manchmal schwer, zu der Erkenntnis zu gelangen, dass manche Dinge sich einfach überlebt haben und ich sie loslassen sollte - insbesondere dann, wenn ich sowieso keine Zeit dazu finde. Und so habe ich dieser Tage eine meiner ältesten Websites (neben meiner Homepage, natürlich) endlich aufgegeben.

KRG-online war ein 1998 begonnenes Angebot für Ehemalige meiner alten Schule, um auch nach dem Abitur weiterhin in Kontakt miteinander - und auch mit Freunden und Bekannten aus anderen Jahrgängen - bleiben zu können. Es sollte für jeden (ehemaligen) Schüler die Möglichkeit bestehen, einen Steckbrief mit persönlichen Daten einschließlich verschiedener Adressen (Heimat und Studienort oder Wohnung und Arbeistplatz), telefonischer Erreichbarkeiten, Mailadressen und Webseiten, Freitextfeldern für einen Lebenslauf und persönliche Bemerkungen und ein Foto online zu stellen.

KRG-online.de anno 2001.

Die erste Fassung bestand aus von Hand gepflegten HTML-Seiten und stand ungeschützt im Netz; daran dachte man damals noch nicht so wirklich. Ab 2002 und vor allem nach einer erneuten Überarbeitung 2004 gab es dann eine datenbankgestützte PHP-Anwendung mit persönlichen Logins und der Möglichkeit, den eigenen Datensatz selbst zu pflegen (und auch Fotos hochzuladen und wieder zu löschen), eine Mailingliste, eine Linksammlung von Webseiten der Abiturjahrgänge und einen Terminkalender; optisch war die Seite an Farbe und Design der damaligen Schul-Homepage angepasst.

KRG-online.de anno 2008.

Danach teilte die Seite das Schicksal der meisten anderen meiner Webprojekte aus Studien- und Ausbildungszeit: begonnen mit viel Elan, aber wenig Ahnung, und mit Beginn der Berufstätigkeit wurde die freie Zeit zuerst weniger und dann nochmals sehr viel weniger. Eine Überarbeitung hätte Not getan, aber es gab ja noch so viele andere Ideen, Projekte und Arbeitsfelder … und dann kam allmählich die professionelle Konkurrenz. 2002 ging StayFriends online, vorher schon Passado, seit 2005 gab es den Facebook-Clon StudiVZ (erinnert sich noch jemand daran?), 2006 folgte das gerade in Rheinland-Pfalz sehr populäre wer-kennt-wen, seit 2008 gibt es das 2004 veröffentlichte Facebook mit deutscher Oberfläche, Twitter, Instagram und überhaupt das Web 2.0. Für handgestrickte proprietäre Dienste, die letztlich nur ein Adressverzeichnis ohne weitere Kommunikationsmöglichkeiten bieten, war die Zeit eigentlich vorbei.

2012 hatte ich daher alle mehr als 400 Nutzer von KRG-online angeschrieben und die mögliche Einstellung des Dienstes, vor allem aus Zeitmangel meinerseits, angekündigt - soweit es Antworten gab, stimmten die meisten mir zu, dass die Welt sich weitergedreht habe, wenngleich eine Handvoll den Dienst auch vermissen würde. Dazu passt, dass es zwar bis zum Schluss Registrierungen gab, aber aus den Abiturjahrgängen nach 2004 nur noch einzelne Versprengte - und auch für die Abitreffen meines eigenen Jahrgangs mussten wir die aktuellen Mailadressen aus anderer Quelle besorgen, weil die Daten auf KRG-online von den Nutzern nicht gepflegt wurden. 2014 habe ich den Dienst daher offline genommen und durch eine Wartungsseite ersetzt, immer in der Hoffnung, vielleicht einen neuen Anlauf starten zu können oder die Seiten einer neuen Nutzung zuzuführen, bspw. als Online-Adress-Portal des Ehemaligenvereins (der immer noch alle paar Jahre sein aktualisiertes Adressverzeichnis per Post verschickt).

Wiederum fünf Jahre später ist nichts dergleichen geschehen - und ich habe (mindestens!) vier vergleichbar große oder größere Projekte, die für mich mittlerweile höhere Priorität haben (und bei denen sich natürlich auch nichts tut). Und so nützlich es grundsätzlich auch sein mag, eine Plattform zu haben, die nicht von den dort hinterlassenen Daten lebt und auf der man seine Erreichbarkeit mit einer nur überschaubaren Personenzahl teilen kann - ehrlicher wäre es wohl gewesen, den Dienst schon 10 Jahre früher einzustellen.

Nun also: der Schlussstrich. (Immer noch etwas schweren Herzens. Aber wenigstens ist es ein optisch ansprechender Schlussstrich geworden.)

Shariff - sichere Sharing-Buttons

nospam@example.com (Thomas Hochstein) — Mon, 07 May 2018 16:45:00 +0000

Im Zeitalter sozialer Netzwerke lebt auch das Web vom “Teilen” von Seiten - dem Veröffentlichen von Links zu Webseiten, Blogbeiträgen und anderen Ressourcen in diesen Netzwerken, bei Twitter, Facebook und Co. Das Open Graph Protocol und Twitter Cards, die ich vor ungefähr zwei Jahren vorgestellt habe, ermöglichen es dabei dem Seitenbetreiber, das Aussehen solcher Links - insbesondere ihren Titel, die textuelle Beschreibung und ein hinzugefügtes Bild - zu steuern; und weil Mobilgeräte zwar regelmäßig aus jeder App heraus (und somit auch aus dem Webbrowser) das “Teilen” von Seiten ermöglichen, der auf Desktops und Laptops verwendete Browser aber oft nicht, baut man als Seitenbetreiber gerne Buttons ein, mit denen die Seite “geteilt” werden kann.

Die verschiedenen sozialen Netzwerke bieten dafür in der Regel Codeschnippsel an, die aber den Nachteil haben, bereits beim Aufruf Daten des Nutzers an den jeweiligen Netzwerkanbieter zu übermitteln - nicht nur in Zeiten der Datenschutzgrundverordnung (DSGVO) ein No-Go. Hier hilft das Shariff-Projekt der c’t weiter, das Sharing-Buttons ohne Datenübermittlung an die sozialen Netzwerke anbietet.

In Serendipity lassen sich solche Buttons ganz einfach mit dem Plugin serendiptiy_event_social hinzufügen, das seit anderthalb Jahren auch hier im Blog werkelt. Aber auch auf der eigenen Homepage ist Shariff schnell eingebaut.

Installation von Shariff

Die Installationsanleitung findet sich direkt im Github-Repository und ist dort auch auf Deutsch verfügbar.

Im Prinzip genügt es, das aktuelle Release herunterzuladen und die dort enthaltenen Dateien auf den eigenen Webspace zu packen; die Schriftdateien von Font Awesome, das CSS und das Javascript. Verwendet man auf der eigenen Seite bereits Font Awesome, genügt als CSS-Datei shariff.min.css; muss Font Awesome noch eingebunden werden, muss man zu shariff.complete.css greifen. Ähnlich sieht es mit dem Javascript aus: wird JQuery bereits verwendet, genügt shariff.min.js, ansonsten ist shariff.complete.js erforderlich.

Packt man die Schriftdateien nicht direkt zum CSS, muss in der CSS-Datei jeweils der Pfad entsprechend angepasst werden.

Danach müssen CSS (im <HEAD>) und Javascript (am Ende der Seite) eingebunden werden, und schon ist alles vorbereitet. Jetzt fehlt nur noch das Einfügen der eigentlichen Share-Buttons an der passenden Stelle im Seitengerüst, mit den passenden Parametern, die in der Anleitung erläutert sind.

Shariff-Backend

Will man sich nicht auf Buttons beschränken, sondern auch anzeigen, wie oft die Seite im jeweiligen sozialen Netzwerk bereits geteilt wurde, muss zusätzlich ein Backend her, bspw. Shariff-Backend-PHP. Hier im Blog kann man besichtigen, wie das dann aussehen kann.

Installation

Auch die Installation des Backends ist vergleichsweise einfach. Es genügt, die Releasedatei zu entpacken und in ein Verzeichnis hochzuladen, in dem PHP-Dateien ausgefürt werden. In der mitgelieferten index.php sollte man dann noch die Konfiguration anpassen - und schon ist das Backend bereit! Ein Aufruf des Scripts mit der URL einer geteilten Seite als Parameter, bspw. in der Form http://example.com/my-shariff-backend/?url=http%3A%2F%2Fwww.example.com, sollte dann eine Reihe von Zahlen zurückliefern (nicht aber null). Funktioniert dieser Test, ist das Backend an sich bereits funktionsfähig.

Konfiguration und Dienste

Man möchte es vielleicht noch etwas anpassen - bspw. den Aufruf nur für bestimmte Domains - die eigenen nämlich - gestatten, oder die Liste der unterstützten Dienste einschränken oder erweitern.

Twitter wird als Dienst nicht mehr unterstützt, weil keine freie API mehr für solche Abfragen zur Verfügung steht; die Anzahl der Tweets der eigenen Seite lässt sich daher mit Shariff nicht mehr anzeigen.

Dies gilt auch für Google+.

Für die Unterstützung von Facebook muss man sich bei Facebook als Entwickler registrieren und eine Facebook-“App” aufsetzen. Der Ablauf ist in der Facebook-Entwicklerdokumentation Schritt für Schritt dargestellt:

Als erstes muss man sich bei Facebook einloggen.
Danach muss man sich zu seinem Account einen Entwickler-Account anlegen
Als nächstes muss man sich eine App erzeugen.

Dabei wird eine App-ID und ein zugehöriger geheimer Key erzeugt. Diese benötigt man für die Konfiguration des Shariff-Backends. Es ist nicht erforderlich, die App tatsächlich zu aktivieren.

Auf der eigenen Webseite muss die Adresse des Backends dann noch im Attribut data-backend-url hinterlegt werden. Dort kann ein relativer Pfad, aber auch eine absolute URL wie https://shariff.example.com/ angegeben werden.

Fußangeln

Wenn das Backend an und für sich funktioniert, aber keine Zähler in den Share-Buttons auf der eigenen Webseite angezeigt werden, sollte man zunächst prüfen, ob man die Ausführung von Javascript freigegeben hat. Das gilt insbesondere dann, wenn das Backend unter einer anderen Domain läuft als die eigenen Webseite, weil man sich bspw. für mehrere Domains ein Backend unter einer einheitlichen Adresse wie https://shariff.example.com/ angelegt hat.

Im letzteren Fall muss man sich auch noch Gedanken über Cross-Origin Resource Sharing, kurz CORS, machen. Im Zweifel sollte man den Webserver für shariff.example.com einen HTTP-Header Access-Control-Allow-Origin: * übermitteln lassen. Für den Apache-Webserver lässt sich das mit der Zeile

Header set Access-Control-Allow-Origin "*"

in der vhost-Konfiguration lösen.

Workflow für die Erstellung und Pflege von Webseiten

nospam@example.com (Thomas Hochstein) — Wed, 17 May 2017 05:20:00 +0000

Ich stelle die von mir betriebenen Webseiten, die nicht auf interaktive Funktionen angewiesen sind, Stück für Stück auf statisch generierte Seiten um, zuletzt meine Homepage. Dabei setze ich auf einen Workflow, der nanoc als static site generator und git als Versionsverwaltungssystem umfasst und dafür sorgt, dass Änderungen der Seiten automatisch eingespielt werden.

Entwicklung, Test und Veröffentlichung

Bei Verwendung eines static site generators werden die Webseiten zunächst aus Quelldateien erzeugt und müssen dann veröffentlicht, d.h. in das passende Verzeichnis des Webservers befördert werden, der sie anzeigen soll. Darüber hinaus ist es generell sinnvoll, “Code” im weitesten Sinne - und dazu gehören dann auch HTML- und CSS-Dateien bzw. die Quellen, aus denen diese erzeugt werden - in einem Versionsverwaltungssystem zu speichern, in dem Änderungen nachverfolgbar sind und wo jederzeit auf ältere Versionen zurückgegriffen werden kann. Nimmt man dies zusammen, unterscheiden sich Webseiten damit letztlich kaum mehr von Webapplikationen oder anderer Software: es gibt den Quellcode und das Kompilat (die fertigen Seiten, das ablauffähige Programm), Quellcode muss verwaltet und das Ergebnis getestet und schließlich veröffentlicht (deployed) werden.

Für die drei Schritte - entwickeln, testen, veröffentlichen - werden zumeist mehrere Rechner (Systeme, Umgebungen) benötigt, die unterschiedlichen Zwecken dienen:

Entwicklungsumgebung
Der Rechner, auf dem die Seiten entworfen, bearbeitet und ggf. auch getestet werden.
Git-Server
Git ist zwar ein verteiltes Versionsverwaltungssystem, aber es ist generell sinnvoll, das Repository nicht nur auf dem eigenen Arbeitsrechner vorzuhalten, sondern auch auf (mindestens) einem Server. Das schafft Redundanz und ermöglicht es, auf verschiedenen Rechner zu arbeiten und die Ergebnisse jeweils zu synchronisieren.
Testumgebung
Es ist sinnvoll, ein Testsystem vorzuhalten, dass dem Echtsystem weitgehend entspricht, um testen zu können, ob die Webseiten auch wirklich so aussehen und “funktionieren”, wie man sich das vorstellt.
Echtumgebung
Am Ende des Tages sollen die Webseiten auf einem Rechner im Netz liegen, der sie mithilfe eines Webservers weltweit abrufbar macht.

Grundsätzlich kann man das alles auf ein- und demselben Gerät betreiben: eine im Netz verfügbare Maschine, auf der man sich einloggt und entwickelt, auf der Git verfügbar ist und die zugleich Test- und Echtumgebung darstellt. Meistens wird man aber doch auf dem heimischen Desktoprechner oder dem Laptop arbeiten wollen und einen Webserver (oder auch nur Webspace) irgendwo angemietet haben. Letzteres gilt auch für mich.

Mein Workflow

Ich bearbeite die Quelldateien (den Sourcecode) meiner Webseiten auf meinem Desktoprechner oder dem Laptop unter Windows, zumeist mit Sublime Text, reine Markdown-Dateien manchmal auch mit MarkdownPad.

nanoc unterstützt einen sehr bequemen Testmodus mit eingebautem Webserver: nach dem Compilieren mit nanoc genügt ein nanoc view, um einen Webserver zu starten, der dann unter http://localhost:3000/ die Website zur Ansicht bereitstellt. Leider funktioniert das für mich noch nicht, denn zwar lässt sich nanoc grundsätzlich auch unter Windows installieren und betreiben, aber das für den LESS-Filter erforderliche Ruby-Gem leider nicht - jedenfalls ist mir das nicht gelungen. Daher arbeite ich weiterhin “nach alter Väter Sitte” und lade die geänderten Dateien per SCP bzw. SFTP entweder auf einen lokalen Linux-Server oder direkt auf den externen Webserver hoch bzw. sorge für eine automatische Synchronisierung mit WinSCP. Dort wird dann compiliert und im Browser das Ergebnis angeschaut.

Auch das Veröffentlichen der Seiten unterstützt nanoc mit dem Kommando nanoc deploy, das ein Deployment per git, per rsync oder mittels fog unterstützt. Das ist sicherlich sehr nützlich, wenn man die Webseiten auf dem Entwicklungsrechner testet und dann von dort auf den Webserver überspielt; nachdem nanoc aber auf meinen Windows-Rechnern nicht läuft, gehe ich einen anderen Weg und compiliere direkt auf dem Webserver. Ich lade also den Quellcode hoch, lasse nanoc auf dem Server laufen und das Ergebnis dann unmittelbar in das Webserver-Verzeichnis ausgeben (in der Regel durch ein passend gesetztes output_dir in der nanoc.yaml).

Ich halte regelmäßig neben der aktuellen Fassung meiner Webseiten auch eine Testfassung vor, die ich über eine passwortgeschützte URL aufrufen kann. Das hat den Vorteil, dass ich von überallher testen kann und zudem die Testumgebung und die Echtumgebung identisch sind, weil sie auf demselben Server (in zwei unterschiedlichen virtual hosts) laufen.

Das jeweilige Git-Repository für eine Website hat daher immer mindestens den master- und einen staging-Zweig; im letzteren wird getestet, der erstere enthält die aktuelle Echtversion. Wenn ich einen dieser Zweige per git push auf meinen Git-Server schiebe, wird er automatisch auf den Webserver kopiert (in das Quellverzeichnis für die Echtfassung oder dasjenige für die Testversion der Website), dort compiliert und bereitgestellt. Auch für dieses “Kopieren” oder generell das Aktualisieren einer Website über git gibt es eine Reihe von Möglichkeiten: man kann bspw. einfach das Git-Repository auf dem Webserver auschecken, oder aber man checkt via git archive wirklich nur den Inhalt des Repositorys aus. Ich habe mich für letzteres entschieden; einziger Nachteil ist, das aus dem Repository entfernte Dateien nicht automatisch gelöscht werden, ggf. also “Leichen” verbleiben. Dafür habe ich nicht das komplette Repository mit der ganzen History herumliegen.

Ein Beispiel

In der Praxis sieht das dann ungefähr so aus:

Ich aktualisiere mein lokales Git-Repository auf dem jeweiligen Arbeitsrechner, damit es auf dem aktuellen Stand ist.
Ich verändere oder ergänze meine Webseiten, indem ich die entsprechenden Dateien auf dem Arbeitsrechner bearbeite.
Wenn umfangreichere Tests erforderlich sind, lade ich die geänderten Dateien auf meinen Webserver in das Quellverzeichnis für die Test-Instanz der jeweiligen Website hoch und führe - auf dem Server - nanoc aus, so dass die Testinstanz der jeweiligen Webseiten aktualisiert wird. Im Browser kann ich dann die geänderten Seiten durch Aufruf von http://test.meine-website.example/ ansehen. Alternativ kann ich natürlich auch auf einem anderen Rechner im lokalen Netz testen.
Wenn ich mit dem Ergebnis zufrieden bin, aktualisiere ich den test-Zweig meines lokalen Git-Repositorys und schiebe ihn per git push auf den externen Git-Server.

Dort wird ein post-receive-Hook ausgeführt, der auf dem richtigen Webserver ein PHP-Script mit den passenden Paramtern aufruft. Das Script sorgt dann dafür, dass die Dateien aus dem Git-Repository ausgecheckt werden, und führt danach nanoc aus. Für den test-Zweig des Repositories websites/meine-website auf dem Server git.server.example mit dem Zielverzeichnis /var/www/sources/meine-website/ auf dem Webserver sähe das dann so aus:

$ git archive --format=tar --remote=ssh://git@git.server.example/websites/meine-website test | tar -C /var/www/sources/test.meine-website.example/ -xf -
$ cd /var/www/sources/test.meine-website.example/
$ nanoc

nanoc hat dann als output_dir bspw. /var/www/html/test.meine-website.example/ konfiguriert, was zugleich das DocumentRoot für den virtual host http://test.meine-website.example/ ist.

Will ich später die gesammelten Änderungen aus der Testinstanz auf die Echtinstanz übernehmen, geht das ebenfalls ganz einfach: ich bringe sie in den master-zweig meines Repositorys und veröffentliche diesen: git checkout master; git merge test; git push; git checkout test

Der post-receive-Hook wird das Deployment-Script mit anderen Parametern aufrufen, so dass nicht der test-Zweig, sondern der master-Zweig ausgecheckt und nicht nach /var/www/sources/test.meine-website.example/, sondern nach /var/www/sources/www.meine-website.example/ kopiert wird. Und das ist dementsprechend das DocumentRoot für http://www.meine-website.example/.

Die nanoc-Ausgaben gibt das Deployment-Script aus, so dass der Git-Server sie an den Git-Client übermittelt; sollte nanoc die Compilation also mit einer Fehlermeldung abbrechen, ist das erkennbar und ermöglicht ein manuelles Eingreifen. Ansonsten sind manuelle Eingriffe nur noch erforderlich, wenn eine bereits deployte Datei gelöscht werden muss; es liegt in der Natur der Sache, dass der gewählte Weg über git archive neue und geänderte Dateien (und Verzeichnisse) anlegt, alte Dateien aber nicht löscht.

Conclusio

Viele Wege führen nach Rom; dies ist meiner.

Er lässt sich fraglos vereinfachen; ein Hemmschuh ist insbesondere die Entwicklung unter Windows, die den Workflow erschwert.

Kommentare und Kritik nehme ich gerne entgegen, ebenso wie andere Wege zum selben Ziel.

Markup mit HAML

nospam@example.com (Thomas Hochstein) — Mon, 08 May 2017 07:15:00 +0000

Websites bestehen - hoffentlich - in der Regel aus (wenigen) Templates, die dann mit (vielen verschiedenen) Inhalten gefüllt werden. So arbeiten Blogs und CMS, so arbeitet auch ein static site generator. Die Templates können dabei HTML-Dateien sein - müssen es aber nicht, wie ich schon anno 2015 beschrieb.

Bei der Arbeit mit meinen Webseiten habe ich mit HTML-Templates angefangen, die ich dann in der Regel mit Markdown gefüllt habe - oder, um in der Diktion von nanoc, dem von mir verwendeten static site generator, zu bleiben: die Layouts in layouts/ waren HTML-Dateien, die Inhalte in content/ in der Regel Markdown, beides (soweit erforderlich) kombiniert mit embedded ruby (ERB). Beim Compilieren durchliefen die Layouts dementsprechend einen ERB-Filter, die Inhalte zwei Filter (Markdown und ERB).

Direkt mit HTML macht die Arbeit aber - gerade bei ein wenig komplexeren Gestaltungen - auf die Dauer nur wenig Spaß: ständig muss man Tags öffnen und schließen (gut, dabei unterstützen Editoren), und die Übersicht leidet. Daher habe ich mich nach kurzer Zeit entschieden, statt auf HTML auf HAML zu setzen, eine Template-Sprache, die von HTML abstrahiert.

Ein typisches Seitengerüst wie

<!DOCTYPE html>
<html lang='de'>
  <head>
    <meta charset='utf-8'>
    <meta content='IE=edge' http-equiv='X-UA-Compatible'>
    <meta content='width=device-width, initial-scale=1' name='viewport'>
    <title><%= @item[:title] %></title>
  </head>
  <body>
    <header>
      <div class='header-container'>
        <div class='row'>
           [...]
        </div>
      </div>
    </header>
    <div class='main'>
      <h1>Überschrift</h1>
      <p>
        Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed
        diam nonumy eirmod tempor invidunt ut labore et dolore magna
        aliquyam erat, sed diam voluptua. At vero eos et accusam et
        justo duo dolores et ea rebum. Stet clita kasd gubergren, no
        sea takimata sanctus est. 
      </p>
    </div>
    <footer class='footer'>
      [...]
    </footer>
  </body>
</html>

sieht in HAML so aus:

!!!
%html{:lang => "de"}
  %head
    %meta{:charset => "utf-8"}
    %meta{:content => "IE=edge", "http-equiv" => "X-UA-Compatible"}
    %meta{:content => "width=device-width, initial-scale=1", :name => "viewport"}
    %title #{@item[:title]}
  %body
    %header
      .header-container
        .row
          [...]
    .main
      %h1 Überschrift
      %p
        Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed
        diam nonumy eirmod tempor invidunt ut labore et dolore magna
        aliquyam erat, sed diam voluptua. At vero eos et accusam et
        justo duo dolores et ea rebum. Stet clita kasd gubergren, no
        sea takimata sanctus est. 
    %footer
      [...]

Das ist kürzer, klarer strukturiert - und die logische Struktur wird unmittelbar erkennbar. Außerdem wird das Ende eines Elements nicht durch ein schließendes Tag, sondern das Zeilenende (beziehungsweise das Ende einer Einrückungsebene) gekennzeichnet. HAML schließt Tags im generierten HTML daher selbständig. Nie mehr vergessene Tags, die sich öffnen, aber nicht wieder schließen! Fehler kann man im Prinzip nur noch beim Einrücken machen - aber fehlerhafte Einrückungen führen zu einem Fehler beim Compilieren und werden daher sofort erkannt. Zudem erhält das aus dem Template generierte HTML wunderbare Einrückungen, die es ebenfalls gut lesbar machen.

Für Templates ist HAML demnach hervorragend geeignet - für Inhalte allerdings nicht so sehr. Die große Stärke - die klaren Einrückungen - wird bei Texten, die immer wieder innerhalb von Blöcken Textauszeichnungen enthalten, zu einer großen Schwäche.

Man denke an folgendes Beispiel:

<p>
  Lorem ipsum dolor sit amet, consetetur <strong>sadipscing</strong>
  elitr, sed diam nonumy eirmod tempor invidunt ut labore et
  <em>dolore magna</em> aliquyam erat, sed diam voluptua. At
  <a href="https://netz-rettung-recht.de/vero/"><strong>vero</strong></a> eos et accusam et justo duo
  dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus
  est. 
</p>

Das sieht in HAML dann so aus:

%p
  Lorem ipsum dolor sit amet, consetetur
  %strong sadipscing
  elitr, sed diam nonumy eirmod tempor invidunt ut labore et
  %em dolore magna
  aliquyam erat, sed diam voluptua. At
  %a{:href => "/vero/"}
    %strong vero
  eos et accusam et justo duo
  dolores et ea rebum. Stet clita kasd gubergren, no sea takimata
  sanctus est.

Das ist … weniger schön, und beim Schreiben nicht mehr angenehm, sondern schnell die Hölle.

Es fragt sich also, was man am besten tut, wenn Markdown allein für Inhalte nicht genügt, weil es bspw. keine Elemente wie <section> oder <span> kennt und auch Tabellen nicht ohne weiteres abgebildet werden können. Man könnte natürlich wieder auf HTML zurückgreifen, das sich bekanntlich mit Markdown mischen lässt.

Oder man nutzt ein weiteres Feature von HAML: es unterstützt nämlich Filter, d.h. die Verwendung anderer Markupsprachen innerhalb eines Templates. So kann man die Verwendung von HAML auf die Templates und Strukturen beschränken und die Inhalte - bspw. - in Markdown beisteuern:

  %body
    %header
      .header-container
        .row
          [...]
    .main
      %h1 Überschrift
      :markdown
        Lorem ipsum dolor sit amet, consetetur **sadipscing** elitr,
        sed diam nonumy eirmod tempor invidunt ut labore et *dolore
        magna* aliquyam erat, sed diam voluptua. At [**vero**](/vero/)
        eos et accusam et justo duo dolores et ea rebum. Stet clita
        kasd gubergren, no sea takimata sanctus est.
    %footer
      [...]

Best of both worlds!

Außerdem unterstützt HAML embedded ruby - statt HTML-Templates und Markdown-Inhalten bleiben also nur noch .haml-Dateien, die einen HAML-Filter durchlaufen. Fertig - Markdown und ERB gibt es quasi gratis dazu. (Und Textile, LESS, SASS und vieles andere, wenn man das möchte, auch.)

Bootstrap mit nanoc

nospam@example.com (Thomas Hochstein) — Fri, 05 May 2017 15:15:00 +0000

Unter anderem für den Relaunch meiner Homepage habe ich mich damit beschäftigt, wie ich das CSS-Framework Bootstrap am besten mit nanoc, meinem bevorzugten static site generator, zur Anwendung bringen kann.

Bootstrap bringt einen ganzen Haufen CSS, etwas Javascript und Glyphicon Halflings als Webfont mit. Webfont und Javascript können unverändert bleiben, das CSS hingegen sollte aus den LESS-Dateien kompiliert werden, um so mit wenigen Anpassungen in variables.less das Aussehen der Website zu personalisieren.

Meine nanoc-Quelldateien habe ich dementsprechend folgendermaßen strukturiert:

content/
 :
 :--bootstrap/
 :   :
 :   :--js/
 :   :
 :   :--fonts/
 :   :
 :   :--less/
 :    
 :--res/
     :
     :--css/
     :
     :--fonts/
     :
     :--js/

In content/bootstrap/js/ landet das Javascript aus Bootstraps dist/js/, in content/bootstrap/fonts/ die Schriften aus dist/fonts/, und die Dateien aus less/ kommen nach content/bootstrap/less/. Dabei müssen jedenfalls in meiner alten Version 3 von nanoc noch einige Dateien umbenannt werden, weil sich nur in der Endung unterscheiende Dateien unzulässig sind: aus bootstrap.min.js wird so bootstrap-min.js, bei den Schriftdateien wird die Endung auch in den Dateinamen übernomme, so dass aus glyphicons-halflings-regular.ttf dann glyphicons-halflings-regular-ttf.ttf wird.

Der Inhalt von content/bootstrap/js/ landet dann beim Kompilieren in content/res/js/, derjenige von content/bootstrap/fonts/ unter Entfernung der “doppelten” Endungen in content/res/fonts/, und aus content/bootstrap/less/bootstrap.less wird (unter Einbindung aller anderen LESS-Dateien) content/res/css/bootstrap.css kompiliert.

Fertig.

In den Rules sieht das dann ungefähr so aus:

#!/usr/bin/env ruby

#########################
### compilation rules ###
#########################

# compile Bootstrap CSS (only) from bootstrap.less
compile '/bootstrap/less/bootstrap' do
  filter :less
end
compile '/bootstrap/*' do
  nil
end

# main rule
compile '*' do
  [...]
end

#####################
### routing rules ###
#####################

# copy font files and move last -XXX to extension
route '/res/fonts/*/' do
  # /bootstrap/fonts/foo-eot/ -> /res/fonts/foo.eot
  item.identifier.sub('/bootstrap/less/','/res/css/').sub(/-[^-]+\/$/, '') + '.' + item[:extension]
end

# copy bootstrap files
route '/bootstrap/less/bootstrap' do
  item.identifier.sub('/bootstrap/less/','/res/css/').chop + '.css'
end
route '/bootstrap/less/*' do
  nil
end
route '/bootstrap/*/' do
  item.identifier.sub('/bootstrap/','/res/').chop + '.' + item[:extension]
end

# main rule
route '*' do
  [...]
end

Es geht sicherlich einfacher und weniger komplex, aber so geht es jedenfalls auch.

Wenn man in seinem Git-Repository auch direkt einen bootstrap-Branch anlegt, kann man Bootstrap-Updates dort einspielen und in der Regel durch ein einfaches git checkout master; git merge bootstrap für die eigenen Seiten übernehmen.