Tutorial: Freelancer-Seiten mit Statamic entwickeln

Kleine Portfolio- oder Freelancer-Webseiten lassen sich mit WordPress meist problemlos realisieren: Ein hübsches Theme wählen, Plugins suchen, ein paar Anpassungen vornehmen, fertig. Dass man dabei vielfach mit Kanonen auf Spatzen schießt, muss erst einmal nicht stören. Machen die Anforderungen der Webseite jedoch ein eigenes Theme oder Plugin erforderlich, steht man als Nicht-WordPress-Entwickler vor einer steilen Lernkurve. Spätestens dann kommt die Frage auf, ob das alles nicht auch eine Nummer kleiner und einfacher geht. Es geht. Zum Beispiel mit dem Flat-File-CMS Statamic.

Vorab: Statamic ist keine Open-Source-Software, sondern kostet 29 oder 99 Dollar für eine einmalige Lizenz. Wer also ausschließlich mit Open Source arbeitet, für den ist dieser Beitrag nichts. Alle anderen können beruhigt weiterlesen, denn hier findet keine Werbung, kein Affiliate oder Ähnliches statt. Der Beitrag ist entstanden, weil mir Statamic gefällt. Und er ist der dritte Teil einer Serie über Webseiten für Freelancer. Der ersten beiden Teile beschäftigen sich mit Website-Buildern wie Squarespace und Profildiensten wie Flavors.me, Behance oder Pressfolio.

Als ich vor der Frage nach einer Alternative für kleine Webprojekte stand, verlief meine Suche eher pragmatisch: Wenn mich eine Review zu einem kleinen CMS überzeugt hatte, habe ich das System kurz installiert und mir erst einmal die Autorenoberfläche angeschaut. Wenn der Workflow für Autoren einigermaßen akzeptabel war, habe ich grob die Möglichkeiten und Grenzen des Systems überflogen und mir zum Schluss den Entwicklungsprozess angeschaut. Kurz getestet habe ich die Systeme Stacey, Kirby, Dropplets, Anchor CMS, Koken, Leeflets und Statamic. Am Ende ist die Entscheidung auf Statamic gefallen. Am Schluss dieses Tutorial-Artikels gibt es ergänzend ein paar Worte zu den anderen Systemen.

Statamic – Was es nicht kann und was es kann

Der Name “Statamic” leitet sich von “static” und “dynamic” ab. Damit wird schon erklärt, was das CMS ausmacht: Statamic ist ein statisches, file-basiertes System, mit dem sich jedoch ebenso problemlos dynamische Inhalte wie Blogs oder Kalender realisieren lassen. Geht man tiefer ins Detail, stößt man auf eine Menge Vorteile, aber auch einige Schwächen des Systems.

Damit ihr nicht erst am Ende des Beitrags mögliche K.O.-Kriterien entdeckt, fangen wir mal mit den Besonderheiten von Statamic an:

• Statamic ist wie gesagt kostenpflichtig. Die Lizenz schlägt mit 29 Dollar für private oder 99 Dollar für kommerzielle Webseiten zu Buche. Alle Updates danach sind kostenfrei, allerdings gibt es mit Raven kostenpflichtige Plugins, die ich mir jedoch noch nicht angeschaut habe. Anders als bei dem preislich ähnlich gelagerten Kirby kann man leider keine Testversion runterladen, sondern man kauft die “Katze im Sack”, was ich etwas unglücklich finde.
• Statamic ist ein Flat-File-System, d.h. es arbeitet nicht mit einer Datenbank, sondern mit Dateien, die auf dem Server gespeichert werden. Allerdings ist die zusätzliche Nutzung einer Datenbank wohl möglich.
• Statamic basiert auf PHP, nutzt jedoch ebenfalls YAML in Kombination mit einer eigenen, sehr einfachen Template-Sprache. Man kann PHP in Templates verwenden, empfohlen wird es jedoch nicht.
• In der Autorenoberfläche setzt Statamic nicht auf einen WYSIWYG- oder Rich-Text-Editor wie man es von WordPress kennt, sondern wie viele junge Systeme auf einen Markdown-Editor, ähnlich wie zum Beispiel Github. Man kann ebenso einen HTML-Editor, Textile oder andere Alternativen aktivieren.
• Die Bild- und Medienverwaltung war bei fast allen getesteten Systemen ein massiver Schwachpunkt. Bei Statamic ist es kein Problem, ein einzelnes Bild hochzulanden und dann an einer vordefinierten Stelle der Seite anzuzeigen. Will der Autor jedoch mehrere Bilder frei in einen Beitrag einbinden, muss er den Link zum Bild per Markdown in den Text platzieren. Das ist unschön, möglicherweise gibt es dafür jedoch eine einfache Lösung, auf die ich noch nicht gestoßen bin.
• Statamic ist ein Entwicklungs-Framework. Wer nicht entwickeln kann, wird mit Statamic nicht weit kommen, da es nur vergleichsweise wenige Themes und Plugins gibt bzw. auch nicht vorgesehen sind. Weil die Template-Sprache recht simpel ist, könnte sich Statamic als Einstiegs-Framework für Nicht-Entwickler eignen. Vermutlich macht es für völlige Neulinge jedoch mehr Sinn, sich erst einmal in eine „Standard“-Programmiersprache einzuarbeiten.

Bevor alle vorschnell K.O. gehen, liste ich die Vorteile von Statamic auf:

• Hat man sich einmal in die Template-Sprache, in YAML und in das Konzept von Statamic eingearbeitet, kann man extrem schnell und enorm flexibel Webseiten mit statischen und dynamischen Elementen bauen.
• Zwar gehen Installation und Einarbeitung nicht ganz so schnell, wie Statatmic glauben machen will. Aber auch andere Tester berichten, dass man nur bei wenigen Systemen so schnell das Gefühl hat, die Grundlagen zu beherrschen und sehr frei arbeiten zu können.
• Für die meisten Anwendungsfälle wie Blogs, statische Seiten oder sogar Kalender-Funktionen benötigt man bei Statamic schlicht keine Plugins oder Drittlösungen, weil man solche Standards innerhalb kürzester Zeit selbst entwickelt hat.
• Anders als beispielsweise Kirby liefert Statamic die Administrations-Oberfläche für Autoren sofort mit. Und diese Oberfläche ist erst einmal sehr nutzerfreundlich und leicht konfigurierbar: Überflüssiges lässt sich ausblenden und Formularfelder für die Autoreneingaben sind in Windeseile erstellt.
• Die Dokumentation ist sehr gut und umfangreich. Allerdings ist sie – typisch für Entwickler – teilweise sehr abstrakt geschrieben, was den Einstieg als weniger erfahrener Hobby-Coder doch etwas erschwert. Hat man das Konzept einmal begriffen, kann man die Dokumentation wunderbar nutzen.
• Statamic und die Autorenoberfläche sind grundsätzlich für responsive Webseiten ausgelegt und das CMS liefert gleich ein Grid-System mit.
• Da Statamic keine Datenbank braucht, kann man es auch auf den kleinsten Serverpaketen hosten. Statamic stellt eine Test-Datei zur Verfügung, mit der man vor dem Kauf prüfen kann, ob der Server den Ansprüchen genügt.

Für mich überwiegen derzeit ganz eindeutig die Vorteile. Größter Pluspunkt ist der Spaßfaktor bei der Entwicklung, weil man mit Statamic sehr schnell und ohne große Kopfschmerzen zum Ergebnis kommt.

Damit jeder für sich entscheiden kann, ob Systeme wie Statamic eine Alternative für künftige Projekte darstellen (Kirby ist beispielsweise sehr ähnlich), stelle ich in den nächsten Kapiteln in Kurzform die Installation, die Autorenoberfläche und die Theme-Entwicklung vor. Wer auf den Geschmack kommt, kann mit den Learning-Seiten von Statamic, zwei Screencasts und der Dokumentation direkt einsteigen und eigene Seiten bauen.

Statamic – Die Installation

Bevor man sich für Statamic entscheidet, sollte man die Server-Anforderungen mit dem Testfile von Statamic überprüfen (auf den Server hochladen und das File aufrufen). Ist alles klar, kann man sich eine Lizenz kaufen und das CMS herunterladen. Statamic hat folgende Ordner:

• _add-ons: Hier sind bereits diverse Add-Ons abgelegt, anrühren muss man den Ordner nicht.
• _app: Das sind die Core-PHP-Dateien, die bleiben natürlich unangetastet.
• _cache: Wie der Name schon sagt …
• _content: Hier werden die Inhalte der Seite abgelegt, mit dem Ordner arbeitet man also intensiv.
• _logs: Hier werden Log-Dateien gespeichert, falls aktiviert …
• _themes: Hier liegen die Themes, damit arbeitet man ebenfalls intensiv.
• admin: Das optionale Admin-Board fasst man eigentlich nicht an.
• assets: Hier werden vor allem die Bilder und Medien der Webseite gespeichert, die der Autor hochlädt.

In der Regel (und auch in dieser Einführung) bearbeitet man nur die drei Ordner _content, _themes und assets.

Die Installation ist relativ mühelos: Man trägt den Lizenzschlüssel ein, nimmt ein paar Konfigurationen vor, lädt die Dateien auf den Server, macht ein paar Ordner beschreibbar und legt los. Es gibt allerdings ein paar Unterschiede, je nachdem, ob man Statamic im Root-Verzeichnis oder in einem Sub-Folder installiert, was vermutlich eher die Regel als die Ausnahme ist. Im Detail:

So installierst du Statamic im Root-Verzeichnis:

• Viele der notwendigen Dateien werden mit dem Zusatz “sample” mitgeliefert. Um die Originaleinstellungen nicht zu verlieren, sollte man jeweils eine Kopie erstellen und darin das “sample” im Dateinamen entfernen.
• Das gilt erst einmal  im obersten Ordner für die htaccess-Datei, die man kopiert und durch das Entfernen von “sample” aktiviert (wichtig für die Sicherheit des CMS).
• Anschließend geht man in den Ordner “_config” und trägt in der Datei “(sample.)settings.yaml” den Licence-Key ein. In der Datei wird man später noch diverse Grundeinstellungen wie Sprache, Seitentitel, Control-Panel etc. vornehmen. Um die Seite erst einmal zum Laufen zu bringen, sind weitere Einstellungen jedoch nicht nötig.
• Um einen Admin-User anzulegen, mit dem man sich in das Control-Panel (die Autorenoberfläche) einloggen kann, geht man im Ordner “_config” unter “user” und trägt in der dortigen “(sample.)admin.yaml” die entsprechenden Daten ein (Name, Rolle, Passwort). Einloggen kann man sich nun mit „admin“ und dem Passwort. Das Passwort wird beim ersten Einloggen verschlüsselt. Will man weitere Nutzer anlegen, legt man einfach eine neue Datei mit den gleichen Inhalten an. Der Name der Datei („admin“) ist gleichzeitig auch immer der Login-Name.
• Anschließend lädt man die Dateien auf den Server und macht folgende Ordner “writable”:
  • _cache
  • _logs
  • _content
  • _config/users

Jetzt ist die Webseite mit dem Standardtheme erreichbar und man kann sich unter der url /admin.php/login anmelden.

So installierst du Statamic in einem Subfolder:

In den meisten Fällen wird man Statamic in einem Subfolder installieren, denn selbst wenn es zu Beginn die einzige Seite bzw. Installation sein sollte, weiß man ja nie, ob nicht später noch mehr Seiten hinzukommen, und ein nachträgliches Verschieben in einen Subfolder ist eher lästig.

Wenn Statamic in einem Subfolder installiert wird, sind nur zwei zusätzliche Schritte erforderlich:

• In der htaccess-Datei muss in der letzten Zeile der Name des Subfolders in die RewriteRule eingetragen werden: ^(.*)$ /subfolder/index.php [QSA,L]
• Der Name des Subfolders muss auch in die _config/settings.yaml eingetragen werden (die dritte Einstellung _site_root: /subfolder/).

Man merkt, dass die Installation doch etwas aufwändiger ist, als Statamic in seinem Installations-Screencast vermittelt. Sonderlich schwer ist es aber nicht. Zwar gibt es z.B. bei Anchor-CMS deutlich einfachere Installations-Routinen. Da sich Statamic jedoch an Entwickler richtet, hat man darauf vielleicht auch zu Recht verzichtet.

Statamic – Die Autoren-Oberfläche (Control-Panel)

Werfen wir erst einmal einen Blick auf die Autorenoberfläche, die im unteren Bild schon leicht angepasst und reduziert ist:

Wie man sieht ist die Oberfläche sehr aufgeräumt: Die Inhaltsseiten werden schlichtweg hierarchisch dargestellt und erhalten als Schnellfunktionen die Buttons “Vorschau”, “Neu” und “Löschen”. Wenn eine Seite nicht statisch ist, sondern aus einzelnen dynamischen Einträgen besteht, kann man die Einträge als Liste ansehen (“List”) oder einen neuen Eintrag erstellen (“Create”). Solche dynamischen Ordner werden seit Kurzem ebenfalls in der Headnavigation aufgeführt, damit das Navigieren noch schneller geht.

Alle anderen Optionen habe ich erst einmal ausgeblendet, weil Sie für den Autoren aus meiner Sicht nicht relevant sind. Ausgeblendet sind im oberen Beispiel: members, system, logs und help. Dazu geht man wieder in die Datei _config/settings.yaml. Dort kann man in dem Block „Control Panel Configuration“ die einzelnen Punkte per true/false ein- und ausblenden. Außerdem kann man dort die Landingpage nach dem Einloggen bestimmen und einiges mehr.

Natürlich sind auch die Bearbeitungsfelder für die Seite interessant:

In diesem sehr simplen Fall gibt es nur vier Felder:

• Title (Überschrift)
• Slug (File-Name)
• Image
• Content

„Slug“ ist der Name der Datei, in dem die Inhalte auf dem Server gespeichert werden. Der Slug wird per default automatisch vom Titel-Feld abgeleitet, kann danach aber manuell geändert werden. Man könnte ihn zwar für den Nutzer ausblenden, weil er etwas erklärungsbedürftig ist. Allerdings sollte man vorher seine beiden Funktionen kennen:

• Aus dem Dateinamen (Slug) baut Statamic die URL der Seite.
• Aus dem Anfang des Datei- bzw.  Ordnernamens (Nummer oder Datum) ergibt sich die Reihenfolge und damit die Navigationsfolge von Seiten.

Es gibt natürlich noch viele andere Eingabefelder wie Datum, Ort oder auch ganze Gruppen von Feldern, die man frei bestimmen kann. Wie das geht, dazu gleich mehr.

Ein Blick auf die Files

Wie alle Flat-File-Systeme kann man die Inhalte bei Statamic auch ohne Autorenoberfläche erstellen, bearbeiten und organisieren. Bearbeitet man im Ordner _content den Inhalt einer Datei oder ändert den Namen, so ändert man damit gleichzeitig die Inhalte, die URL oder die Navigation auf der Webseite. Schiebt man die Ordner in eine andere Hierarchie-Ebene, so ändert sich auch in der Navigation der Webseite die Hierarchie. Schaut man in die Autorenoberfläche, so wird dort immer genau diese Ordner- und Datei-Struktur abgebildet.

Dabei gibt es zwei unterschiedliche Sortier-Möglichkeiten: nach Nummern oder nach Datum. Wie man im Screenshot sieht, werden die Ordner auf der untersten Ebene von „1-“ bis „5-“ durchgezählt. Dagegen fangen die rechts sichtbaren Blogeinträge immer mit dem Datum an. Entsprechend werden die Inhalte sowohl auf dem File-System, als auch auf der Webseite sortiert. Das funktioniert also nach einer sehr intuitiven Logik.

Aus all diesen Dateien im Ordner _content generiert Statamic also die Webseite. Doch wie sieht so ein Inhalts-File aus? Alle Inhalts-Dateien haben bei Statamic die Endung „.md“ und sehen, wenn man sie mit einem Editor öffnet, etwa so aus:

---
title: Home
_template: start
_fieldset: with_image
image: /assets/img/munkt-2.jpg
---
Lorem ipsum dolor sit amet, consetetur sadipscing elitr, 
sed diam nonumy eirmod tempor.
## Ich bin eine Überschrift
invidunt ut labore et dolore magna aliquyam erat, 
sed diam voluptua.

Eine md-Datei besteht immer aus zwei Blöcken:

• Dem Header-Bereich, der jeweils durch drei Striche nach oben und unten abgegrenzt ist. Im Header stehen Meta-Angaben wie der Seiten-Titel, aber auch welches Template genutzt werden soll, welches Set von Eingabe-Felder es in der Autorenoberfläche geben soll oder wie die URLs des dazugehörigen Bildes lautet. Die Syntax des Headers ist YAML.
• Unterhalb des Headers findet man den Inhalt der Webseite in Markdown-Syntax.

Man kann solche Inhalts-Seiten mit einem Editor erstellen und anschließend per FTP auf den Server laden. Statamic generiert daraus eine normale HTML-Seite. Doch auch wenn eine Autorenoberfläche eigentlich nicht nötig ist, werden wohl nur die wenigsten Autoren mit dieser Nutzungsvariante zurechtkommen.

Die Anzahl der md-Files pro Ordner hängt vom Seitentyp ab: Wenn man eine statische Seite anlegt, liegt immer nur eine Inhaltsseite mit dem Namen “page.md” in dem Ordner. Legt man dynamische Seiten mit mehreren Einträgen an (z.B. Blog oder Termine), dann gibt es eine „page.md“ mit Meta-Angaben und ggf. statischen Inhalten sowie für jeden Eintrag noch einmal eine eigene md-Datei mit den jeweiligen Inhalten des Eintrags. Außerdem gibt es bei dynamischen Inhalten noch eine YAML-Datei, in der verschiedene Einstellungen vorgenommen werden (dazu später mehr).

Mit der Entwicklung starten: Themes, Assets, Content

Wenn wir schon bei den einzelnen Files sind, können wir auch mit der Entwicklung starten und mal ein eigenes Theme erstellen. Dazu legen wir drei neue Ordner an bzw. erstellen Kopien von bestehenden Ordnern:

• _assets: Hier werden Bilder und Medien abgespeichert, die der Autor im Autorensystem hochlädt.
• _content: Hier liegen wie gesagt die Inhalte der Seite. Man kann einfach einen neuen Ordner anlegen und in der _config/settings.yaml diesen Ordner als neuen Content-Ordner angeben.
• _themes: Unter Themes befindet sich bereits das Standard-Theme “denali”. Daneben legt man einen eigenen Theme-Ordner an (z.B. “meintheme”) und erstellt die nötigen Unterordner. Auch hier gibt man kurz das verwendete Theme in der _config/settings.yaml an.

Jedes Theme hat folgende Unterordner, wie man auch oben im Screenshot sieht:

• css: Selbsterklärend, hier werden die CSS-Dateien abgelegt.
• img: Hier werden nur statische Bilder wie z.B. ein Header-Bild, Icon-Sets oder Sprites abgelegt, die für das Theme global genutzt werden. Bilder, die zu Seiten oder Blog-Einträgen gehören, werden wie gesagt im Ordner _assets gespeichert.
• js: Wie zu erwarten kommen hier Javascript-Dateien rein, falls vorhanden.
• layouts: Hier wird der HTML-Rahmen der Webseite abgespeichert, der normalerweise einen Meta-Header, einen inhaltlichen Header-Bereich, einige Includes und einen Footer enthält. In der Regel hat man nur ein Default-Layout, man kann aber natürlich auch mehrere Layouts erstellen, wenn z.B. ein Seitentyp komplett anders aussehen soll als der Standard.
• partials: Wie in anderen Systemen üblich, werden die Inhaltsbereiche bei Statamic so gut wie möglich strukturiert. In den Partials-Ordner legt man daher einzelne Elemente ab, die eine eigene Einheit bilden. Das kann zum Beispiel die Hauptnavigation oder eine Sidebar sein. Diese Trennung ist nicht absolut zwingend, aber man ist gut beraten, sich an solche Konventionen zu halten.
• templates: Hier kommen natürlich die einzelnen Templates rein. Anders als “partials” ändern sich Templates von Seite zu Seite. Beispielsweise kann die Startseite schlicht aus statischem Inhalt bestehen, während die Inhalte unter “Blog” oder “Termine” aus mehreren Files dynamisch per Schleife ausgelesen und dann natürlich anders dargestellt werden. Für die andere Darstellung benötigt man Templates.

Durch die Angabe des Themes und des Content-Ordners in der _config/settings.yaml kann man mit einer Statamic-Installation in der Entwicklung sehr leicht mit verschiedenen Themes und unterschiedlichen Beispiel-Inhalten arbeiten, was sehr praktisch ist. Bevor es jedoch richtig losgeht, sollte man noch die Zusammenhänge von Layouts, Templates und Pages verstehen.

Wie alles zusammenhängt: Layouts, Templates, Pages

Das Verständnis dieser Zusammenhänge erleichtert die Arbeit hinterher enorm. Und so in etwa funktioniert das System in Kurzform: Zunächst wird über die URL der entsprechende Ordner mit der page.md oder einem dynamischen Eintrag gesucht. Aus der page.md erfährt Statamic dann, welches Layout und welches Template genommen werden soll. So einfach kann das sein. Noch einmal im Detail:

Die URL setzt sich immer aus der Struktur im _content-Ordner und aus dem Namen der md-Dateien zusammen (in der Autorenoberfläche als “Slug” sichtbar). Ruft ein Nutzer eine URL auf, weiß Statamic also, in welchem Ordner er unter “_content” suchen muss. Bei statischen Seiten liest Statamic per Default die page.md aus, die daher nicht in der URL steht. Bei dynamischen Seiten wird zusätzlich die md-Datei mit dem dynamischen Eintrag ausgelesen, dessen Name ebenfalls aus der URL bekannt ist (z.B. www.meineseite.de/blog/mein-erster-blogeintrag). Die page.md ist also immer der Ausgangspunkt für den Aufbau der Seite.

Wie oben gezeigt, wird in jeder page.md im Header-Bereich angeben, welches Layout und welches Template für die Darstellung der Inhalte verwendet werden sollen. Wenn dort nichts eingetragen ist, schaut Statamic in den Ordnern “Layout” und “Template” jeweils nach einer Datei “default.html”, d.h. diese Dateien sollten immer als Standard angelegt werden.

Als Beispiel:

---
Title: Titel der Seite
_layout: MeinLayout
_template: MeinTemplate
---

In diesem Fall wird die Datei MeinLayout.html im Ordner _themes/meinTheme/layouts und die Datei MeinTemplate.html im Ordner _themes/meinTheme/templates verwendet. Ganz einfach.

Themes entwickeln: Die Template-Sprache

Bis vor Kurzem war ich eher skeptisch gegen proprietäre Template-Sprachen eingestellt: PHP ist ja bereits als Template-Sprache angelegt und ich sah bislang keinen Sinn darin, eine Extra-Sprache zu lernen, mit der man dann nie die vollen Möglichkeiten von PHP ausnutzen kann. Nur um eine hübschere Syntax zu haben oder Fehler von Copy&Paste-Anwendern zu vermeiden? Inzwischen hat sich meine Einstellung etwas geändert: Tatsächlich braucht man mit der Template-Sprache von Statamic selten mehr als eine Zeile Code, um auch komplexere Abfragen zu erstellen, was die Templates in Kombination mit der ohnehin recht simplen Syntax wirklich sehr übersichtlich und gut pflegbar macht. Außerdem gibt es diverse nette Hacks wie zum Beispiel “in_future”, mit denen sich gängige Anforderungen (z.B. Kalender) schnell lösen lassen.

Die Template-Sprache von Statamic folgt einem durchaus bekannten Muster: Sie wird durch doppelte geschweifte Klammern abgegrenzt. Innerhalb der Klammern steht dann die Anweisung oder die Variable. Z.B.:

{{ layout_content }}

um die Inhalte der Seite im Template auszugeben, oder

{{ entries:listing }}
  HTML-Code
{{ /entries:listing }}

um die Einträge eines Blogs auszugeben, also analog zu einer Schleife in PHP. Natürlich gibt es daneben “conditional statements” wie if, else und so weiter. Wenn man mit Statamic entwickeln will, sollte man sich auf jeden Fall vorher mit der Syntax mit Hilfe der Dokumentation und der Learning-Seiten vertraut machen.

Beispiel: Ein Layout-File (html-Gerüst)

Fangen wir einmal mit dem Default-Layout-File an. Das enthält wie gesagt den Meta-Header, den Seiten-Header und den Footer und schließt die übrigen Inhalte per Template-Tag ein.

Ein ganz einfaches Default-Layout kann zum Beispiel so aussehen:

<!doctype html>
<html lang="de">
  <head>
    <meta charset="utf-8" />
    <title>Beispieltitel</title>
    <link rel="stylesheet" href="http://fonts.googleapis.com/css?family=Lato:300">
    <link rel="stylesheet" href="{{ theme:css }}" />
    <script type="text/javascript" src="{{ theme:js }}"></script>
  </head>
  <body>
    <header>
      <div class="row">
        <div class="span-12">
          <h1>Meine Überschrift</h1>
        </div>
      </div>
      <div class="row">
        <div class="span-12">
          <nav>
            {{ theme:partial src="navigation" }}
          </nav>
        </div>
      </div>
    </header>
      {{ layout_content }}
    <footer>
      <div class="row">
        <div class="span-12">
          <small>Impressum</small>
        </div>
      </div>
    </footer>
  </body>
</html>

In diesem einfachen HTML-Gerüst (das Grid-System kann man natürlich auch erst einmal weglassen) gibt es ein paar Template-Tags, um weitere Inhalte einzubetten. Die Template-Tags sind:

• {{ theme:css }} – gibt die URL zur CSS-Datei des Themes aus.
• {{ theme:js }} – gibt die URL der Javascript-Datei für das Theme aus.
• {{ theme:partial src=“navigation“ }} – Holt sich aus dem Ordner “partial” die Datei “navigation”
• {{ layout_content }} – Holt sich das entsprechende Content-File aus dem _content-Ordner eingebettet in das Template-File in dem _template-Ordner.

Mehr benötigt so ein Standard-Layout erst einmal nicht.

Beispiel: Ein Partial-File (Navigation)

Die im Layout eingebettete Partial-Datei mit der Navigation kann zum Beispiel so aussehen:

<ul class="nav sidebar-item clearfix">
  <li><a href="{{ homepage }}"{{ if !segment_1 }} class="current"{{ endif }}>Aktuell</a></li>
    {{ nav from="/" max_depth="1" }}
    <li><a href="{{ url }}"{{ if is_current || is_parent }} class="current"{{ endif }}>{{ title }}</a>
     {{ if is_current || is_parent }}
       {{ if children }}
        <ul>
        {{ children }}
          <li><a href="{{ url }}"{{ if is_current }} class="current"{{ endif }}>{{ title }}</a></li>
        {{ /children }}
        </ul>
      {{ endif }}
    {{ endif }}
    </li>
  {{ /nav }}
</ul>

Der Aufbau dürfte ziemlich selbst erklärend sein: Im HTML-Gerüst wird zunächst mit {{ homepage }} der “Home”-Link eingefügt, anschließend werden dynamisch die einzelnen Seiten als Navigationspunkte aufgelistet. Dabei kann man mit {{ nav from”/” max_depth=”1” }} angeben, von welcher Ebene aus die Unterseiten aufgelistet werden sollen und wie tief die Navigation gehen soll. In diesem Fall könnten wir die ganze {{ if children }}-Abfrage  auch weglassen, da wir mit max_depth=”1” ja ohnehin nur die oberste Navigationsebene auslesen. Ich lasse es aber stehen, damit man den Code bei einer anderen max_depth-Angabe direkt hat und nicht erst wieder rumschreiben muss. Zusätzlich gibt es überall noch die {{ if is_current }} – Abfrage, um zu prüfen, ob der Navigationspunkt gerade angesteuert ist, sodass man dem Punkt eine eigene CSS-Klasse geben und darüber den Link hervorheben kann.

Beispiel: Ein Default-Template-File

Ein Default-Template für eine Startseite kann so aussehen:

<div class="row">
  <article>
    {{ if image }}
      <div class="span-3">
        <img class="thumb left" src="{{ _site_root }}{{ image }}" width="200" />
      </div>
      <div class="span-9">
        {{ content }}
      </div>
    {{ else }}
      <div class="span-12">
         {{ content }}
      </div>
    {{ endif }}
  </article>
</div>

Lässt man wirklich alles (Bild-Abfrage und Grid-System) weg, könnte das Template auch aus drei Zeilen bestehen:

<article>
  {{ content }}
</article>

Der Inhalt aus der Seite (page.md) wird mit Hilfe des {{ content }}-Tags in das Template eingebunden. In dem längeren Beispiel gibt es eine Abfrage, ob der Autor ein Bild angehängt hat. Gibt es ein Bild, wird es in einer etwas anderen Grid-Struktur mit Hilfe des Tags {{ _site_root }}{{ image }} auf der linken Seite angezeigt, der Content-Text erscheint rechts daneben. Falls es kein Bild gibt, wird nur der Inhalt in einem einzigen Grid-Feld ausgegeben.

Woher weiß Statamic jetzt, woher das Bild kommt? Das geschieht natürlich über das {{ image }}-Tag, das den relativen Pfad zum Bild ausgibt. Doch woher kommt dieser relative Pfad? Auch das ist ganz einfach: Wenn man zu einem Beitrag ein Bild hochlädt, speichert Statamic dieses Bild in den Ordner “assets” ab. Der relative Pfad zu dem Bild wird wieder in der jeweiligen page.md in den Header-Bereich abgespeichert. Wenn also die page.md gelesen wird, weiß Statamic über die Angabe im Header nicht nur, welche Layouts und Templates genommen werden sollen, sondern auch, welches Bild zu der Seite gehört. Die page.md im _content-Ordner würde also zum Beispiel so aussehen:

---
title: Home
_template: start
image: /assets/img/mein_bild.jpg
---
## Ich bin eine Überschrift
Hier kommt ein normaler Text. Alle Inhalte unterhalb 
des Header-Bereichs hat der Autor in den Content-Editor 
eingegeben.

Man sieht also, dass es bei Statamic keine großen Geheimnisse gibt, sondern alles nach dem gleichen Muster abläuft, das man einmal verstanden haben sollte. Und immer ist die page.md der Ausgangspunkt, in dem alle Informationen für den Seitenaufbau zusammenlaufen.

Eine Sache vorweg: Das Template-Tag muss nicht {{ image }} heißen, sondern man kann es mit ein paar Handgriffen auch anders nennen. Darauf kommen wir später noch einmal zurück, wenn es darum geht, die Eingabefelder im Autorensystem anzulegen.

Beispiel: Ein Blog-Template-File

Wenn wir ein dynamisches Template zum Beispiel für einen Blog oder eine Terminliste anlegen möchten, dann sieht das so aus:

{{ entries:listing folder="werkschau" }}
  <div class="row">
    <article>
      <div class="span-3">
        <img class="thumb" src="{{ _site_root }}{{ transform src="{ image }" width="200" height="150" action="smart" }}" />
      </div>
      <div class="span-9">
        <h2>{{ title }}</h2>
        {{ content }}
      </div>
    </article>
  </div>
{{ /entries:listing }}

Wie man sieht, gibt es  keinen Unterscheid, außer dass der Inhalt in zwei Tags eingeschlossen wird:

{{ entries:listing folder="blog" }}
{{ /entries:listing }}

Damit wird eine Schleife erzeugt, die alle Dateien aus einem bestimmten Ordner ausliest (in diesem Fall folder=”blog”). Die Reihenfolge, wie die Files ausgelesen werden, entspricht wieder dem Filenamen. Der beginnt entweder numerisch mit “1-”, “2-” etc., oder – typisch für Blogeinträge – mit dem Datum wie z.B. “2013-08-24-titel”, “2013-08-13-titel”. In WordPress wären diese Informationen in der MySQL-Datenbank gespeichert und man würde das mit einer “if post”-Schleife realisieren.

Zu jedem Beitrag wird der Titel {{ title }} und der Inhalt {{ content }} ausgegeben. Die einzige kleine Variation, die ich hier eingebaut habe, betrifft das Bild:

<img src="{{ _site_root }}{{ transform src="{ image }" 
width="200" height="150" action="smart"}}" />

Mit dem {{ transform }}-Tag kann man ein Bild in eine bestimmte Größe (hier 200 x 150) umwandeln. Statamic schaut dann im asset-Ordner, ob es das Bild in dieser Größe bereits gibt. Wenn nicht, erstellt das System eine Kopie des Originalbildes in dieser Größe und speichert sie ab. Sehr einfach und nützlich. An diesem Beispiel sieht man zudem, wie Statamic mit der Verschachtelung von Tags umgeht: Wird ein Tag innerhalb eines anderen Tags eingefügt, dann nutzt man nur einfache geschweifte Klammern: { image }.

Stellt sich abschließend noch die Frage, wie die Files für solche dynamischen Inhalte im _content-Ordner aussehen. Auch bei dynamischen Inhalten hat man standardmäßig immer eine page.md. Darin steht dann oft nur der Titel und das Template im Header:

---
title: Blog
_template: blog-listing
---

Die einzelnen Blog-Einträge werden dann nach dem Muster “datum-titel.md” angelegt, z.B. “2013-03-22-das-ist-mein-erster-blogeintrag.md”. Die einzelnen Einträge haben ebenfalls einen Header und einen Content-Bereich, z.B.:

---
title: Risiken und Nebenwirkungen
image: /assets/img/run.jpg
---
Hier steht der eigentliche Inhalt meines Blog-Eintrags.

Statamic geht all diese md-Files in dem Ordner durch und gibt deren Inhalte in der Schleife im Template aus. So einfach kann das gehen.

Im letzten Schritt stellt sich nur noch die Frage, wie man im Autorensystem die nötigen Eingabefelder einrichtet. Denn der Autor muss ja alle Felder vorfinden, die er für die Erstellung der Inhalte benötigt.

Beispiel: Eingabefelder für den Autoren definieren

Um Inhalte zu erstellen, braucht der Autor natürlich für jeden Inhalts- bzw. Seitentyp auch unterschiedliche Eingabefelder. Das ist der letzte fehlende Schritt, um selbständig eigene Seiten mit Statamic bauen zu können.

Statamic bietet dafür “fields” und “fieldsets” an:

• Ein Field ist ein simples Eingabefeld, zum Beispiel ein Text-Feld, ein Datums-Feld, ein Content-Feld mit Editor oder ein File-Upload-Feld für Bilder oder Dateien.
• Ein Fieldset ist eine Kombination aus mehreren Eingabeldern. Ein Standard-Eintrag besteht zum Beispiel aus einem Title-Feld, einem Slug-Feld und einem Content-Feld mit Editor. Das würde man als Fieldset abspeichern. Für einen anderen Inhaltstyp mit zusätzlich einem Datumsfeld und einem Datei-Upload würde man lediglich ein neues oder ergänzendes Fieldset anlegen.

Aus diesen Fields und Fieldsets generiert Statamic automatisch die passenden Eingabefelder und kümmert sich um die Validierung und das Aussehen. Das nimmt dem Entwickler natürlich enorm viel Arbeit ab.

Ein Eingabefeld wird bei Statamic denkbar einfach als .yaml-File mit der YAML-Syntax angelegt und in der Regel im Ordner _config/fieldsets abgespeichert. Will man zum Beispiel ein Eingabe-Feld für einen Beschreibungstext anlegen, sieht das so aus:

fields:
  description:      ## the template tag, {{ description }}
  display: Describe ## the field label (optional)
  required: false   ## true/false for validation (optional)
  type: redactor    ## fieldtype (optional, text by default)

Die Field-Definition beginnt mit dem Keyword “fields:”, darauf folgt der frei wählbare Name des Feldes, den man später als Template-Tag verwendet. Hier heißt das Feld “description”, den Inhalt des Feldes kann man im Template dann mit dem Template-Tag {{ description }} ausgeben.

Unter dem Feldnamen werden die Eigenschaften des Feldes angegeben: In diesem Fall “display” (das Label im Autorensystem), “required” (true or false) und “type” (hier soll dem Autor der in Statamic integrierte Redactor-Editor angezeigt werden). Es gibt zahlreiche andere Eigenschaften und sogar Felder, die mehrere Unterfelder einschließen (das nennt Statamic “Grids”, nicht verwechseln mit den CSS-Grid-Systemen). Die Details kann man in der Dokumentation nachlesen.

Wichtig ist die Einrückung: Unterfelder werden immer mit zwei zusätzlichen Leerschlägen gruppiert. Vor einem neuen Feld (hier: description) werden also zwei Leerschläge eingefügt, die zugehörigen Eigenschaften des Feldes werden dann durch insgesamt vier Leerschläge eingerückt. Man muss bei einigen Editoren wie Notepad++ aufpassen, da dort oft automatisch bei einer neuen Zeile ein Tab für den Abstand eingefügt wird. Dann funktioniert es nicht.

Das Feld für ein Bild (und ein normale Titel-Feld) könnte man beispielsweise auch so definieren:

fields:
  mein_bild:
    type: file
    display: Upload an Image
    destination: assets/img
    show_thumbnail: true
  ein_titel:
    display: Überschrift
    required: true
    type:text

In dem Beispiel oben haben wir ein Fieldset mit den beiden Feldern “mein_bild” und “ein_titel” angelegt. Im Template kann man die Inhalte dieser Felder nun mit den Tags {{ mein_bild }} und {{ ein_titel }} ausgeben.

Fragt sich nur noch, wo man diese Fields und Fieldsets abspeichert und wie man sie einbindet?

Fieldsets abspeichern und einbinden

Alle Fieldsets werden in dem Ordner “_config/fieldsets” als YAML-Datei abgespeichert. Dort kann man beliebig viele eigene Fieldsets anlegen (z.B. meinFieldset.yaml).

Will man das Fieldset in einen Seitentyp einbinden, kann man das wieder in der page.md im Header angeben. Beispiel: Erinnern wir uns an unsere Homepage von oben. Dort hatten wir dem Autor optional die Möglichkeit gegeben, ein Titel-Bild einzufügen. Dazu habe ich ein eigenes (sehr kleines) Fieldset im Ordner “_config/fieldsets” mit dem Dateinamen “with_image.yaml” angelegt. Das sieht so aus:

title: With Image
fields:
  image:
    type: file
    display: Upload an Image
    destination: assets/img
    show_thumbnail: true

Um das Fieldset in die Autorenoberfläche der Seite einzubinden, gibt man es in die page.md im Header an:

---
title: Home
_template: start
_fieldset: with_image
image: /assets/img/mein_bild.jpg
---

Im Autorensystem wird nun wie durch Zauberhand ein Feld für das Bild-Upload angezeigt. Kein Designen, kein aufwändiger Regex, keine weitere Arbeit:

So funktioniert es also bei statischen Seiten: Man legt unter _config/fieldsets ein neues Fieldset an und bindet das Fieldset in die page.md ein. Bei Ordnern mit dynamischen Einträgen funktioniert es ein wenig anders: Um global für alle Einträge Fieldsets anzulegen, wird eine eigene .yaml-Datei in dem Content-Ordner mit den Einträgen abgelegt. Grundsätzlich reicht es, darin einfach nur den entry-type anzugeben und auf ein fieldset im Config-Ordner zu verweisen (_fieldset: mein_fieldset). Man kann jedoch auch direkt in dem Yaml-File die Feldtypen definieren. Das macht vor allem dann Sinn, wenn es recht individuelle Fieldsets sind. Denn so bleiben die Definition der Fieldsets lokal im _content-Ordner. Andernfalls würde man für jedes neue Projekt neue Fieldsets im globalen _config-Ordner ablegen, was auf Dauer ziemlich unübersichtlich wird.

Der Inhalt der lokalen .yaml-Datei im _content-Ordner mit den Einträgen kann so aussehen:

type: date
fields:
  image:
    type: file
    display: Upload an Image
    destination: assets/img
    show_thumbnail: true
  venue:
    type: text
    display: Veranstaltungsort

Der einzige Unterschied zu einem normalen Fieldset im config-Ordner ist am Beginn des YAML-Files die erwähnte Definition “type: date”. Damit weiß Statamic, dass es sich um einen Ordner handelt, in dem die Einträge nach Datum sortiert werden. Damit wird im Autorensystem auch automatisch ein Feld zur Eingabe des Datums angelegt, man muss es also nicht extra in dem YAML-File noch einmal aufschlüsseln. Entsprechend der beiden Sortier-Methoden gibt es als zweite Definition noch “type:number”.

Nochmal zusammenfassend: Bei statischen Seiten legt man ein eigenes Fieldset unter _config/fieldset an, bei dynamischen Seiten legt man die globalen Fieldsets, die für alle Einträge gelten sollen, am besten in einer eigenen fields.yaml direkt unter _content in dem entsprechenden Ordner (z.B. blog) an. Das war der ganze Zauber.

Fazit zu Statamic

Wie man sieht, muss man einmal die Logik von Statamic verstanden haben und die lernt man am besten, indem man eine eigene kleine Beispiel-Seite baut und neben dieser Anleitung auch noch die Dokumentation von Statamic durchgeht. Die zweite Seite wird dann schon rasend schnell gehen. Klar ist, dass wir hier nur wenige Punkte gestreift haben: Statamic bietet, wenn man sich in die Tiefe einarbeitet, noch deutlich mehr Möglichkeiten an bis hin zu eigenen Plugin- und Addon-Entwicklungen. So weit bin ich allerdings selbst noch lange nicht. Für kleine Projekte wie Freelancer- oder Portfolio-Seiten werde ich künftig wohl nur noch selten auf WordPress zurückgreifen, weil Systeme wie Statamic dafür oft deutlich handlicher, schneller und passender sind. Allerdings kann ich mir vorstellen, dass man bei einigen Anforderungen mit Statamic an Grenzen stößt. Das wird sich bei künftigen Projekten zeigen.

Alternativen zu Statamic

Wem Statamic nicht gefällt, der kann sich andere Systeme anschauen. Als kurzer Einstieg:

• Kirby: Kirby ist deutlich bekannter als Statamic, funktioniert aber in vielen Bereichen ähnlich (und ist ebenfalls kostenpflichtig). Kirby basiert auf PHP und arbeitet mit YAML. Allerdings nutzt Kirby reines PHP als Template-Sprache. Außerdem hat Kirby eine sehr gute Dokumentation. Was mir an Kirby weniger gefällt ist das Admin-Panel für Autoren, das nicht im Standard-Download enthalten ist, sondern zusätzlich heruntergeladen und integriert werden muss. Daher habe ich mich am Ende für Statamic entschieden.
• Dropplets: Dropplets ist Open Source und ein reines Flat-File-System für simple Blogs. Dropplets hat das Problem des FTP-Uploads von Flat-File-Systemen sehr eigenwillig gelöst: Anders als Statamic, das eine Autorenoberfläche zur Erstellung der Inhalte eingebaut hat, kann man bei Dropplets die Markdown-Text-Files per Drag&Drop in die Webseite schieben. Die Lösung ist wirklich kreativ und witzig, allerdings halte ich es nicht für zumutbar, dass der Autor seine Inhalte unbedingt offline mit einem Text-Editor erstellen muss. Außerdem weiß ich nicht, wie einfach man mit Dropplets entwickeln kann. Installiert habe ich es trotzdem mal unter einer brachliegenden URL.
• Leeflets: Leeflets ist leider noch nicht öffentlich nutzbar. Allerdings sind die wenigen Einblicke über Entwickler-Videos sehr vielversprechend. Auch mit Leeflets kann man offenbar nur sehr simple Seiten bauen. Allerdings gibt es wohl zu jeder Seite einen aufklappbaren Editor, mit dem der Autor die Inhalte sehr schnell bearbeiten kann, ohne die Seiten zu verlassen. Sollte man auf jeden Fall im Auge behalten.
• Anchor-CMS: Anchor-CMS ist eine kleine Open-Source-Alternative für WordPress, bei der auch die Template-Entwicklung sehr stark an WordPress erinnert. Anchor ist kein Flat-File-System, sondern basiert auf einer Datenbank. Das ganze System ist nur etwa 100 kB groß und Entwickler schwärmen hier und da über den wohl sehr saubern Code. Was leider auch bei Anchor (zumindest bis vor Kurzem) noch nicht funktionierte, waren die Medien-Verwaltung und das Bild-Management. Tatsächlich musste man Bilder per FTP hochladen und dann manuell einbinden, was für mich erst einmal ein K.O.-Kriterium ist. Sollte das behoben werden, wird es wirklich interessant.
• Koken: Koken ist nicht wirklich lightweight, sondern eher ziemlich groß. Ich hatte es mal kurz runtergeladen, bin damit aber nicht zurechtgekommen. Es richtet sich scheinbar ausschließlich an Fotografen und erinnert von der Oberfläche an Adobe-Lightroom, das wohl mühelos integriert werden kann. Jenseits der Fotografie dürfte das CMS kaum in Frage kommen.
• Ghost: Gerade ziemlich hip ist das neue Blog-System Ghost, über das wir hier auch schon kurz berichtet hatten. Ghost wird sicherlich sehr spannend sein, mich schreckt allerdings im Moment noch das Hosting ab, da bislang nur die wenigsten Hoster node.js anbieten. Ghost will selbst eine Hosting-Lösung anbieten, schauen wir mal. Spannend ist es auf jeden Fall, um sich mal mit node und dem Frontend-Trend intensiver zu beschäftigen.

Lesetipps und Links

Zum Schluss ein paar Links und Quellen:

• Statamic: Hier kann man Statamic kaufen und dann herunterladen.
• Statamic Learn: Bevor man anfängt, sollte man sich auf jeden Fall die Learn-Einheit bei Statamic zu Gemüte führen.
• Statamic Doku: Ohne die Doku geht es nicht, sollte man beim Entwickeln immer griffbereit halten.
• Statamic Screencasts: Auf jeden Fall mal anschauen, bevor man es sich kauft. Damit bekommt man schon ein gutes Gefühl für das System.
• My Simple Workflow to Design and Develop a Portfolio-Website: Klasse Beitrag, um sich auf den neuesten Stand zu bringen. Man muss sicherlich nicht alles übernehmen, aber hier werden aktuelle Trends wie SASS, LESS, eigene Grid-Systeme für Responsive-Webdesign etc. erklärt. Der Autor schlägt dann WordPress für die Umsetzung vor, was aber austauschbar ist
• Fluid Grid Builder: Angeregt von dem Smashing-Beitrag hatte ich einen super simplen Grid-Builder (ohne offsets) gebaut, bei dem man sich dann das fertige CSS kopieren kann. Es gibt dutzende von solchen Grid-Buildern und die anderen sind wohl etwas solider und in den Funktionen umfangreicher. Wer es jedoch schlicht mag, kann sich bedienen ;-)
• Kleine CMS-Systeme im Vergleich: Nach wie vor eine sehr gute Übersicht des t3n Magazins über verschiedene kleine CMS-Alternativen. Auch die hier aufgeführten werden dort fast alle genannt.
• Choosing a CMS: Der Beitrag ist von 2012 und vielleicht ist nicht alles darin taufrisch. Allerdings hat mir der Artikel sehr dabei geholfen, die verschiedenen Namen und CM-Systeme auseinanderzuhalten und grob einzuordnen.

---

Dieser Artikel gehört zu: UPLOAD Magazin 2

Passend zur Bundestagswahl drehen sich zwei der fünf Artikel um Politik, genauer um Politiker im Social Web. Dazu: Portfolio-Seite mit Statamic erstellen, Anbieter für Minimalvideos auf einen Blick und das Interspecies Internet.

• Weitere Artikel aus dieser Ausgabe kostenlos auf der Website lesen ...
• Bleib auf dem Laufenden über neue Inhalte mit dem „Update am Montag“ …

Schon gewusst? Mit einem Zugang zu UPLOAD Magazin Plus oder zur Content Academy lädst du Ausgaben als PDF und E-Book herunter und hast viele weitere Vorteile!