Flat-File oder Datenbank: Wie Statamic Inhalte speichert

Die kurze Antwort: als Dateien. Jede Seite, jeder Artikel, jede FAQ ist eine Textdatei mit den Feldern oben und dem Inhalt darunter. Collections, Navigation, globale Einstellungen, Taxonomien und Benutzer liegen ebenso in Dateien. Statt einer relationalen Datenbank wie MySQL fasst Statamic diese Dateien in einem schnellen Index zusammen, dem Stache ^[1].

Der Stache ist ein Zwischenspeicher. Er lässt sich jederzeit löschen und neu aufbauen, ohne dass Daten verloren gehen ^[1]. Die Wahrheit steht in den Dateien. Das ist der Kern dessen, was „Flat-File“ heißt, und daraus folgt fast alles, was in diesem Artikel steht: wie man sichert, wie man Änderungen nachvollzieht und wie man eine Version zurückholt.

Diese Website arbeitet genau so. Ihre Seiten, Artikel und Fragen liegen als Markdown-Dateien im Ordner content/collections des Projekts, neben dem Code.

Was alles als Datei vorliegt, zeigt die Liste der Bereiche, aus denen der Stache seinen Index baut: Taxonomien und Begriffe, Collections und Einträge, die Seitenbäume, Navigationen, globale Einstellungen, Ablagen für Bilder und Dokumente und die Benutzer ^[1]. Fast jeder dieser Bereiche hat einen eigenen Ordner, den man bei Bedarf verlegen kann ^[1]. Für Ihre Agentur heißt das: Es gibt keinen Teil der Website, der nur in einem schwer lesbaren Datenbankformat existiert. Wer das Projekt öffnet, sieht Inhalte und Struktur im Klartext, auch ohne Statamic zu kennen.

Weil Inhalte Dateien sind, lassen sie sich mit Git versionieren wie Code. Statamic kann jede Änderung, die jemand im Control Panel speichert, automatisch committen und auf Wunsch gleich pushen ^[3]. Die Git-Integration ist Teil von Statamic Pro ^[4]. Damit gibt es für jede Änderung einen Zeitstempel und einen Namen, und jeder Stand lässt sich wiederherstellen.

Für Ihre Agentur heißt das vor allem Ruhe. Löscht jemand beim Kunden versehentlich eine Seite, holen wir sie aus dem letzten Commit zurück. Testen wir ein Update, passiert das in der Regel auf einer Kopie mit denselben Inhalten. Und zieht die Website zu einem anderen Hoster um, wandern Inhalte und Code mit dem Repository mit, ohne Datenbank-Export und -Import; Bilder und Uploads ziehen separat mit.

Nach jedem Deployment wird der Stache neu aufgebaut, damit die Änderungen sofort sichtbar sind ^[1]. Auf dem Live-Server schalten wir die automatische Dateiüberwachung ab; sie ist für die lokale Entwicklung gedacht und würde jede Anfrage unnötig verlangsamen ^[1].

Wir hosten nicht selbst. Kundenprojekte laufen beim Hoster, den Ihr Kunde schon hat oder wünscht. Auf Wunsch wählen wir Hoster und Tarif aus und buchen ihn auf Namen und Rechnung Ihres Kunden; die Einrichtung übernehmen wir so oder so. Für Statamic 6 braucht der Server PHP ab Version 8.3 ^[5]. Eine Datenbank ist für Inhalte nicht nötig, was die Auswahl bei kleinen Tarifen erweitert und eine Fehlerquelle weniger bedeutet.

Das Backup ist einfach, aber nicht automatisch erledigt. Bilder und hochgeladene Dateien liegen meist nicht in Git, sondern in einem eigenen Ordner oder Speicher. In unserer Wartung sichern wir beides und prüfen in der Regel, ob sich die Sicherung zurückspielen lässt. Die Tarife stehen unter Wartung.

Eine Datenbank nehmen wir, wenn sehr viele Einträge zu erwarten sind, etwa Tausende Produkte, Formulareinsendungen oder Benutzerkonten in einem Portal. Statamic fragt bei der Installation, ob Inhalte in Dateien oder in einer Datenbank liegen sollen, und der Wechsel geht in beide Richtungen ^[2]. Sie müssen sich also nicht für immer festlegen. Sie bringen die Daten, der Rest klappt. Was die Laravel-Basis sonst ermöglicht, steht unter Was Laravel als Basis bedeutet.