Wie vielleicht einige unserer Besucher schon bemerkt haben, erstrahlt unser Webauftritt seit ein paar Wochen in neuem Glanz. Um einen nutzerfreundlicheren Aufbau zu erzielen und unseren Recruiting Prozess besser zu unterstützen, wurde im Laufe der letzten Monate ein neues, modernes und schlichteres Design erarbeitet und umgesetzt.

devices

Die Umsetzung: CMS vs. Static Site Generator

Bisher basierte unsere Webseite auf Wordpress, doch bald stellte sich die Frage, ob das für uns wirklich sinnvoll ist. Für die meisten „Sonderwünsche“ - für die es nicht gerade ein passendes Plugin gibt, das aber auch nur wieder die Hälfte von dem kann, was man möchte - muss man solch ein Content Management System meist sehr stark zurecht biegen und hacken. Selten gibt es das perfekte Template und oft schlägt man sich mit Sicherheitslücken und haufenweise Updates (für noch mehr Plugins) herum. Deshalb haben wir uns letzten Endes für eine komplette Neuumsetzung entschieden, bei der sich Inhalte und deren Status durch einen besseren Workflow kontrollieren lassen - ohne ein bestehendes CMS. Da sich unsere Mitarbeiter mit Git und Atlassian Tools wie Bitbucket besonders wohlfühlen, entschlossen wir uns für eine Umsetzung mit Jekyll.

Was ist Jekyll?

Jekyll ist ein Open Source Static Site Generator, geschrieben in Ruby, mit dem sich Webseiten und Blogs ohne Datenbank erstellen lassen. Kein verworrener PHP Code, keine riesigen Datenbanken, die Serverkapazitäten verschlingen - stattdessen wird aus einfachen Markdown und HTML Dateien eine statische Webseite generiert. Diese generierten Dateien lädt man dann auf einen beliebigen Webserver und tada - fertig ist die Webseite! So steht zwar zur Bearbeitung des Contents keine GUI mehr zur Verfügung, aber mit den simplen Markdown Dateien und einer geordneten File-Struktur lässt sich Content auch ohne Code-Kenntnisse ganz leicht bearbeiten und hinzufügen. Wenn man trotzdem nicht auf ein grafisches Interface verzichten möchte, gibt es auch Plugins wie Jekyll Admin, die ein solches bereitstellen. Anstatt also, wie bei Wordpress, ein bestehendes CMS mit viel Custom Code und Konfiguration nach den eigenen Wünschen zu verbiegen, hat man mit solchen Static Site Generatoren alle Freiheiten und somit mehr Zeit sich auf das Wesentliche zu konzentrieren. Das macht Texter und Frontend Developer glücklich!

Frei nach Jekyll’s README Datei:

It does what you tell it to do, no more, no less. It doesn’t try to outsmart users by making bold assumptions, nor does it burden them with needless complexity and configuration. Put simply, Jekyll gets out of your way and allows you to concentrate on what truly matters: your content.

Wie geht Jekyll?

Um einen Eindruck zu geben, wie Jekyll funktioniert, hier eine kleine Übersicht über die Funktionsweise und Struktur unserer Seite.

Wichtiger Bestandteil von Jekyll ist der sogenannte Front Matter. Dieser wird im YAML Format an oberste Stelle in die HTML oder Markdown-Dateien geschrieben. Zwischen den Linien mit den drei Bindestrichen können vordefinierte, aber auch eigens erstellte Variablen festgelegt werden. Die Variablen können dann in diesem File (und in referenzierten Layouts) verwendet werden. Bei uns finden sich dort zum Beispiel Informationen zur Sprache der jeweiligen Seite, welches Layout verwendet wird, Keywords, URL, Header-Bild, etc..

So sieht zum Beispiel der Front Matter dieses Blogposts aus:

---
layout: post
published: true
title: Scandio Relaunch 2016
description: Wie vielleicht einige unserer Besucher schon bemerkt haben, erstrahlt unser Webauftritt seit ein paar Wochen in neuem Glanz. Um eine einfachere Struktur zu erzielen und unseren Recruiting Prozess besser zu unterstützen, wurde im Laufe der letzten Monate ein neues, modernes und schlichteres Design erarbeitet und umgesetzt.
keywords: Jekyll, Relaunch, Git, Atlassian, Static Site Generator, CMS, Wordpress
author: anachtmann
date: '2016-08-18 09:00:00 +0200'
name: 'relaunch-08-2016'
image: /media/2016/08/scandio-relaunch.jpg
---

Hauptbestandteil dieser Webseite sind die sogenannten Pages. Dazu zählen eigentlich alle Seiten außer dem Blog - also Unternehmen, Jobs, Leistungen, …. Für jede dieser Pages gibt es eine Collection, die die Unterkategorien der Pages enthält. Zum Beispiel gibt es für die Page „Unternehmen“ eine Collection, die die Inhalte zu „Historie“, „Management“, „Team“ und „Partner“ umfasst.

Loop pages
File-Struktur

Diese werden dann in der Layout-Datei für unsere Pages durch eine Loop (in Liquid geschrieben) zu einer Seite zusammengebaut. Die Variablen in den geschweiften Klammern ergeben sich aus dem Front Matter der jeweiligen Seite.


{%capture collection %}page-{{page.page_collection}}{%endcapture%}

{% for page in site.[collection] %}
      <div id="{{ page.scroll-link }}" class="anchor content-section">
            <div class="wrapper">
                {% if page.title-img %}
                    <div class="title-img"><img class="{{ page.menu-title }}" src="/img/{{ page.title-img }}" alt="{{ page.title }}"></div>
                {% else %}
                    <h3 class="{{ page.menu-title }}">{{ page.menu-title }}</h3>
                    <hr>
                {% endif %}

                {{ page.content }}

                 {% endif %}
            </div>
      </div>

{% endfor %}

Des Weiteren lassen sich wiederverwendbare Daten, wie zum Beispiel Informationen über die Autoren - die man hier in der „About“ Section am Ende des Blogposts sehen kann - ganz einfach in einem YAML-File sammeln und an beliebiger Stelle der Webseite verwenden. So wird zum Beispiel in diesem Blogpost author: anachtmann im Front Matter als Autor angegeben und im Layout für Blogposts werden die Informationen aus der authors.yml abgerufen.

Informationen über den Autor in der authors.yml:

anachtmann:
   name: Alina Nachtmann
   image: anachtmann.png
   description: Alina Nachtmann, B.A. Kunst und Multimedia, hat im Bereich Design und Frontend-Entwicklung bei der Scandio angefangen, tüftelt aber mittlerweile auch im Backend mit. Privat findet man den Zelda-Fan oft mit dem Controller in der Hand, oder mit der Kamera im Gepäck auf Reisen.
   email: <a href="mailto:alina.nachtmann@scandio.de" class="icon icon-cube mail">mail</a>
   xing: <a href="https://www.xing.com/profile/Alina_Nachtmann" class="icon icon-cube xing" target="_blank">xing</a>
   twitter: <a href="https://twitter.com/tigalinaa" class="icon icon-cube twitter" target="_blank"></a>

Wiederverwendung der Informationen im Layout:


<div class="author-meta">
    <div class="author-image"><img src="/img/user/{{ author.image }}" alt="author"></div>
    <div class="author-details">
        <h4>About {{ author.name }}</h4>
        <div class="author-description">{{ author.description }}</div>
        <div class="author-social">{{ author.email }} {{ author.xing }} {{ author.twitter }} {{ author.linkedin }}</div>
    </div>
</div>

Was Jekyll sonst noch so alles auf dem Kasten hat, kann man in ihrer Dokumentation nachlesen.

Herausforderungen mit Jekyll

Die größte Herausforderung mit Jekyll war die mehrsprachige Umsetzung. Es gibt zwar viele Tutorials, wie sich Webseiten mit Jekyll zweisprachig anlegen lassen und das funktioniert auch alles wunderbar - bis man einen zweisprachigen Blog hat, bei dem jede der Sprachen eine Pagination haben soll. Jekyll hat ein integriertes Pagination Plugin, das sich sehr leicht auf den Blog anwenden lässt. Allerdings nur für eine Index-Datei bzw. Sprache. Wir mussten also das Jekyll Pagination Plugin selber überarbeiten, so dass es unsere Ansprüche erfüllt. Das daraus resultierende Plugin haben wir auf Github veröffentlicht.

Workflow

Was für den Texter auf den ersten Blick wohl etwas kompliziert erscheinen mag, ist das lokale Arbeiten mit Jekyll. Da Jekyll ein Ruby Gem ist, lässt es sich aber recht unkompliziert installieren. Außerdem erstellt es beim Bearbeiten immer eine statische Version der Seite, wodurch sie auch jederzeit lokal aufgerufen werden kann. Nach einem kleinen Crash-Kurs in Markdown können die Texter also ohne WYSIWYG-Gefummel ihren Content anlegen und pflegen, während die Developer ohne Umschweife coden.

Wie anfangs bereits erwähnt, war uns ein einfacher Git Workflow wichtig. Durch verschiedene Branches lässt sich einfach ein Staging-Live-System aufbauen, in dem man den Status des Contents jederzeit im Blick hat. Für die lokale Entwicklung nutzen wir eine Vagrant Box - der fertige Content wird dann auf Git gepusht. Da wir als Atlassian Partner Bitbucket Server und Bamboo einsetzen, werden die Inhalte in einem Pull Request nochmal geprüft und dann freigegeben. Durch die Bitbucket Server GUI ist auch das für Nicht-Techies schnell gelernt.

Fazit

Bisher haben wir unsere Entscheidung für Jekyll nicht bereut und denken, dass solche Static Site Generatoren vor allem für kleinere Projekte eine gute Alternative zu bekannten CMS darstellen.