Du hast deinen AdBlocker an?

Es wäre ein Traum, wenn du ihn für t3n.de deaktivierst. Wir zeigen dir gerne, wie das geht. Und natürlich erklären wir dir auch, warum uns das so wichtig ist. Digitales High-five, deine t3n-Redaktion

t3n 36

Publishing für Hacker: Seitengenerator Jekyll vorgestellt

    Publishing für Hacker: Seitengenerator Jekyll vorgestellt

Statische Websites sind wieder „en vogue“. Darüber freuen sich nicht nur HTML-Puristen, denn die Seiten sind sicher, leicht zu deployen und praktisch wartungsfrei. Seitengeneratoren wie Jekyll beweisen, dass man dabei nicht auf Flexibilität und Entwicklungskomfort verzichten muss.

Wenn Webdesigner an statische Websites denken, kommen häufig schlimme Erinnerungen an längst vergangene Projekte hervor. Wie oft etwa hat man Kopf und Fuß einer Website nach einer Änderung manuell in jede einzelne HTML-Datei kopieren müssen? Wie schön, dass es irgendwann dynamisch wurde. Aber sind statische Websites seit der Verbreitung komfortabler CMS-Systeme nun komplett passé?

Nicht ganz, denn auch Wordpress & Co. haben ihre Schwächen. Zum Beispiel müssen regelmäßig Sicherheitsupdates eingespielt werden, damit die Site nicht von Spam-Bots als Virenschleuder missbraucht wird. Auch die Entwicklung gestaltet sich nicht ganz so einfach, denn um vor signifikanten Änderungen eine realistische Vorschau des Produktionssystems zu erhalten, muss jedes mal die Produktionsdatenbank auf das Entwicklungssystem geklont werden. Strickt man dagegen mit heißer Nadel direkt auf dem Produktionssystem, sehen die Besucher schnell mal Layout-Müll.

Statische Sites dagegen bringen hier einige Vorteile mit. So laden sie etwa wesentlich schneller als dynamisch generierte Inhalte. Dass keine serverseitigen Skripte ausgeführt werden, trägt zur Sicherheit der statischen Seiten bei. Admins müssen sich nicht mit lästigen Datenbank- oder Serverkonfigurationen herumschlagen, da ein einfacher Webspace für die Auslieferung der Plain-HTML-Dateien genügt. So fällt auch das Einspielen von Patches und Updates für Datenbank, Skriptsprachen oder Server weg.

Seitengenerierung vor Ort

Wer wegen dieser Vorteile auf statische Sites setzen möchte und trotzdem nicht auf einen gewissen Entwicklungskomfort verzichten will, greift auf Seitengeneratoren wie den in Ruby geschriebenen Jekyll zurück. Die mit Jekyll erzeugten Inhalte und Markups liegen in strukturierten, statischen Textdateien vor; eine Templating-Engine sorgt dafür, dass HTML-Fragmente wiederverwendet werden können. Mit Hilfe des Entwicklungsservers lässt sich die Website in aller Ruhe begutachten, bevor sie auf das Produktionssytem übertragen wird. Bei jedem Speichern werden die HTML-Dateien automatisch im Hintergrund generiert.

Auch die Darstellung dynamischer Inhalte auf statischen Sites ist mittlerweile kein Problem mehr. Viele SaaS-Anbieter bieten die einfache Einbindung der typischen Engagement-Tools wie zum Beispiel Kontaktformulare oder Kommentare per JavaScript. Das macht Jekyll auch als Bloglösung interessant. Nebenbei sind diese externen Dienste oft besser als selbst gehostete Lösungen, weil die SaaS-Anbieter dem Spam-Problem mithilfe ihrer wesentlich größeren Datenbasis effektiver begegnen können.

Nicht nur für Entwickler, auch für Blogger bietet Jekyll interessante Features. Wer von Wordpress & Co. migrieren möchte, nutzt dafür Jekylls Importfunktionen.
Nicht nur für Entwickler, auch für Blogger bietet Jekyll interessante Features. Wer von Wordpress & Co. migrieren möchte, nutzt dafür Jekylls Importfunktionen.

Die Seitengenerierung findet bei Jekyll auf dem Entwicklungssystem statt. Daher werden relativ hohe Anforderungen an das System gestellt. Am besten funktioniert die Erzeugung auf Linux oder OS X, die Installation auf Windows ist möglich, aber höchst beschwerlich. Entwickler sollten auch keine Angst vor Texteditoren und der Kommandozeile haben, mit denen bei Jekyll Installation und Build-Prozess gesteuert werden.

Vorausgesetzt, dass Ruby in Version 1.9.3 oder neuer vorhanden ist, kann Jekyll mit RubyGems installiert werden. Mit dem nun vorhandenen Jekyll-Binary lässt sich die Grundstruktur einer neuen Site erzeugen:

Grundstruktur erzeugen:

gem install jekyll 
jekyll new website
cd website

Listing 1

Um sich das Ergebnis dieser Arbeit anzuschauen, startet man den Jekyll-Entwicklungsserver mit einer einfachen Anweisung:

Entwicklungsserver starten:

jekyll serve --watch

Listing 2

Den aktuellen Stand der Dinge bestaunt man nun im Browser unter "http://localhost:4000".

Anatomie eines Jekyll-Projekts

Jetzt gilt es, sich das Dateigerüst von Jekyll genauer anzuschauen. Den wichtigen Anfang macht die Datei „_layouts/default.html“, die das Layout der neuen Website vorgibt. Es handelt sich um eine HTML-Datei, die mit Tags der Template-Engine liquid angereichert wird. Platzhalter wie {{ page.title }} und {{ content }} werden später durch Werte der konkreten Posts oder Seiten ersetzt. Es ist möglich, mehrere „layout“-Dateien zu definieren. Dadurch können auch komplett unterschiedlich gestaltete Unterseiten, zum Beispiel Microsites für Marketing-Aktionen, aus einer singulären Jekyll-Installation heraus generiert werden.

Die Datei _layouts/default.html (gekürzt):

<!DOCTYPE html>
<html>
   <head><title>{{ page.title }}</title></head>
   <body>
      <div class="site">
         <div class="header">
            <h1 class="title"><a href="/">{{ site.name }}</a></h1>
         </div>
         {{ content }}
      </div>
   </body>
</html>

Listing 3

Eine der späteren Seiten soll die „index.html“ im Wurzelverzeichnis sein. Die Variablendefinitionen, mit denen nun die Platzhalter gefüllt werden, finden sich im so genannten „Front Matter“ im Kopf der Datei. Das Front Matter ist mit Bindestrichen eingezäunt und vom folgenden HTML-Inhalt mit einer Leerzeile getrennt. Hier können beliebige Variablen im Ruby-YAML-Format definiert werden, um sie anschließend im HTML per „liquid“-Tag auszugeben.

index.html:

‐‐‐
layout: default
title: Your New Jekyll Site
‐‐‐

<div id="home">
   <h1>Blog Posts</h1>
   <ul class="posts">
      {% for post in site.posts %}
         <li>
            <span>{{ post.date | date_to_string }}</span>
            <a href="{{ post.url }}">{{ post.title }}</a>
         </li>
      {% endfor %}
   </ul>
</div>

Listing 4

In Listing 4 korrespondiert die „title“-Variable in unserem „index.html“-Front-Matter mit dem „{{ page.title }}“-Tag in der „_layouts/default.html“-Datei aus Listing 3. In der Regel sind die Variablennamen frei wählbar. Um zum Beispiel den Betreiber eines Blogs auszugeben, können wir dessen Namen in das Front Matter der index.html aufnehmen:

Variable festlegen:

---
author_name: Ralph von der Heyden
---
<p>Dieses Blog wird betrieben von {{page.author_name}}.</p>

Listing 5

Neben dem Front Matter enthält die index.html in Listing 4 noch den eigentlichen Inhalt, ein HTML-Fragment. Dieses wird im „default“-Template anstelle des „{{ content }}“-Platzhalters angezeigt. Besonders interessant ist die „for“-Schleife, mit der durch die „site.posts“-Variable iteriert wird. Dadurch wird die Seite von Jekyll automatisch mit den Dateien im „_posts“-Verzeichnis befüllt.

Ein einzelner Post ist dabei ähnlich aufgebaut wie eine Seite. Unser Beispielpost im „_posts“-Verzeichnis beginnt wie auch die „index.html“-Seite mit dem Front Matter, in dem zunächst die verschiedenen Variablen definiert werden. Der Inhalt liegt nicht in HTML, sondern im Markdown-Format vor. Jekyll konvertiert die Markdown-Daten später automatisch in HTML.

Beispiel-Post im Markdown-Format:

_posts/2014‐04‐06‐welcome‐to‐jekyll.markdown :
‐‐‐
layout: post
title: "Welcome to Jekyll!"
date: 2014‐04‐06 13:56:13
categories: jekyll update
‐‐‐
You'll find this post in your `_posts` directory.

Listing 6

Der Inhalt einer Website sollte gut mit den URLs korrespondieren, die darauf verweisen. Deshalb ist Jekyll sehr flexibel bei der Umsetzung eigener URL-Schemata. Grundsätzlich werden alle Dateien mit dem Suffix .html verarbeitet, zum Beispiel kann im Wurzelverzeichnis eine Datei mit dem Namen „about.html“ angelegt werden. Deren Front Matter wird befüllt und es wird noch etwas Inhalt eingefügt:

about.html:

---
layout: default
title: Über diese Website
---
<div id="home">
   <h1>Über diese Website</h1>
</div>

Listing 7

Anschließend können wir das Ergebnis unter „http://localhost:4000/about.html“ bestaunen.

Der Webauftritt von Jekyll selbst ist auf GitHub gehostet. Ein Blick in den "_posts"-Ordner zeigt die letzten Beiträge im Markdown-Format.
Der Webauftritt von Jekyll selbst ist auf GitHub gehostet. Ein Blick in den "_posts"-Ordner zeigt die letzten Beiträge im Markdown-Format.

Soll die „about.html“-Seite aber unter einer anderen URL angezeigt werden, ist auch das möglich. Dazu muss der Pfad aus der URL im Dateisystem angelegt und die Datei verschoben werden:

Pfad anlegen, Datei verschieben:

mkdir ‐p about/this/site
mv about.html about/this/site/index.html

Listing 8

Nun wird die Datei index.html erzeugt, die dann unter der URL „http://localhost:4000/about/this/site“ angezeigt wird.

Anders als für Seiten hat Jekyll für Posts bereits ein URL-Schema vordefiniert. Es bedient sich sowohl beim Dateinamen, zum Beispiel 2014‐04‐06‐jekyll.md, als auch aus dem Front Matter. Aus dem Dateinamen stammen Datum und Titel, sodass man sich zumindest das Datum im Front Matter sparen kann. Da im Dateinamen aber nur URL-kompatible Zeichen verwendet werden dürfen, ist die Angabe eines Titels im Front Matter unerlässlich. Beim Dateinamen der Posts ist das vorangestellte Datum und der nachgestellte URL-lesbare Titel Pflicht, damit der Post später in der „site.posts“-Variable auftaucht.

Rasend schnelles Deployment

Die lokal erstellte Website muss nun noch auf einen Host übertragen werden. Da Jekyll anfangs mit der „‐‐watch“-Option gestartet wurde, liegt die fertige Site bereits im Unterverzeichnis „_site“ vor. Generell kann der Inhalt des "_site"-Verzeichnisses nach erfolgreicher Generierung einfach auf einen Host übertragen werden. Viele FTP-Clients unterstützen mittlerweile Synchronisierung, die sich auch für Jekyll-Projekte empfiehlt. Gut geeignet ist etwa das Tool rsync, falls der Host SFTP unterstützt. In diesem Fall empfiehlt es sich, für das Deployment ein kleines Script anzulegen und mit „chmod +x _deploy.sh“ ausführbar zu machen:

Deployment mit _deploy.sh-Script:

#!/bin/sh
rsync ‐rltPz ‐‐delete _site/ ssh_host:public/webserver/path

Listing 9

Anschließend funktioniert das Deployment mit ./_deploy.sh rasend schnell. Der Unterstrich zu Beginn des Dateinamens sorgt übrigens ebenso wie ein Punkt dafür, dass das Deployment-Script selbst nicht mit auf den Server kopiert wird. Alle anderen Verzeichnisse und Dateien werden eins zu eins übernommen. Interne Dateien wie eigene Scripts, Notizen oder Login-Daten sollten immer mithilfe von Unterstrich oder Punkt versteckt werden.

Fazit

Übernimmt ein an Browser gewöhnter Kunde die Aktualisierung der Website-Inhalte, so fährt man mit einem klassischen CMS auf alle Fälle besser. Entwickler oder auch Blogger, die von den vielen Vorteilen statischer Websites profitieren möchten, finden dagegen in Jekyll einen einfach zu bedienenden Seitengenerator, der fast keine Wünsche offen lässt und enormen Gestaltungsfreiraum bietet.

Ralph von der Heyden
Ralph von der Heyden

ist freiberuflicher Software-Entwickler aus Hamburg. Nach Jahren Konzentration auf Backend- und Devops-Themen arbeitet er aktuell vor allem an Single-Page-Apps mit JavaScript. Auf rvdh.de bloggt er mehr oder weniger regelmäßig.

Links und Literatur

  1. Jekyll
  2. rsync

Finde einen Job, den du liebst

3 Reaktionen
Frank Hübner
Frank Hübner

Schön, daß hier noch jemand eine Lanze für statische HTML-Seiten bricht.
Genau der große Vorteil "Komfortabel" ist genau das, was mich als Entwickler dabei stört. Es wird mir vom System einfach zuviel aus der Hand genommen. Überarbeiten wir Kunden-Sites wimmelt es nur so von JS-Dateien - die oftmals gar nicht benötigt werden und von der Ursprungs-Agentur nur deshalb im Quelltext eingebunden sind, weil sie mit dem Header kurzerhand aus einem früheren Projekt übernommen wurden. Was genau sie machen? Ob durch die Hintertür nicht vielleicht unerwünschte Software ausgeliefert wird? Wer weiß das schon?

"Wie oft etwa hat man Kopf und Fuß einer Website nach einer Änderung manuell in jede einzelne HTML-Datei kopieren müssen?" Eigentlich noch nie. Mit einem vernünftigen Editor (wir benutzen "Notepad++") und Suchen-und-Ersetzen über einen ganzen Ordner, habe ich diese Aufgabe in kürzerer Zeit erledigt als ich bei einem CMS zum Anmelden brauche.

Und was das Verwalten angeht: das klappt auch prima ohne herkömmlisches (PHP + DB) CMS, nämlich mit sogenannten "Hosted CMS".
Als Beispiele hierfür empfehle ich mal einen Blick auf http://www.cushycms.com oder http://www.edit-content.com (auch bekannt als "Surreal") zu werfen.

"Jekyll" klingt auf alle Fälle interessant und ich finde es schön, daß es Entwickler gibt die sich mit soetwas noch beschäftigen - und Autoren die darüber berichten und CMSe nicht nur durch die rosarote Brille sehen.

Frank Hübner
Senior Programmer
http://www.binary-garden.com

Antworten
Torsten
Torsten

Mal abseits des eigentlichen Artikels, aber muss ich mich als Webentwickler, Webdesigner etc.pp. nun auch Hacker nennen? Langsam strengt diese Bezeichnung an ...

Antworten
Felix
Felix

Ist die neue t3n-CI. Die Verschmelzung mit HEFTIG.CO ist fast abgeschlossen, siehe "Warum trägt Mark Zuckerberg bei jeder Präsentation das selbe T-Shirt?". Nur der Zusatz "DU WIRST NIE GLAUBEN [Titel]" fehlt noch....

Antworten
Bitte melde dich an!

Du musst angemeldet sein, um einen Kommentar schreiben zu können.

Jetzt anmelden

Hinweis

Du hast gerade auf einen Provisions-Link geklickt und wirst in Sekunden weitergeleitet.

Bei Bestellung auf der Zielseite erhalten wir eine kleine Provision – dir entstehen keine Mehrkosten.


Weiter zum Angebot