Backend-Pflege ist der Normalfall und für die meisten Aufgaben der richtige Weg. Für einen bestimmten Fall taugt sie aber schlecht: den Aufbau eines neuen Projekts mit siebzig Seiten, die alle noch nicht existieren.

Was eine Seed-Datei ist

Ein PHP-Array, das die Startinhalte eines Projekts enthält: Einstellungen, Seitenangaben, Themenseiten, Beiträge, Lexikoneinträge, Autorenprofile, Verzeichniseinträge und die Bestenliste. Eingelesen wird sie bei der Einrichtung und danach bei jedem Build.

Die Regel, auf die es ankommt

Beim Bauen werden nur Datensätze angelegt, die es noch nicht gibt. Der Abgleich läuft über den Slug. Wo einer schon existiert, passiert nichts.

Das klingt nach einer Kleinigkeit, ist aber der Unterschied zwischen einem brauchbaren und einem gefährlichen Werkzeug. Wer im Backend an einem Text gearbeitet hat, verliert dabei nichts – auch wenn die Seed-Datei eine ältere Fassung desselben Textes enthält.

Was das ermöglicht

  • Inhalt in Wellen. Zehn Lexikoneinträge schreiben, Datei ergänzen, hochladen, bauen. Nächste Woche die nächsten zehn.
  • Versionierung. Die Datei liegt im Dateisystem und lässt sich in eine Versionsverwaltung legen. Wer wann was geändert hat, ist damit nachvollziehbar.
  • Wiederholbare Einrichtung. Ein Projekt lässt sich aus der Seed-Datei neu aufbauen, etwa auf einem Testsystem.
  • Massenarbeit im Editor. Dreißig Einträge in einer Datei zu überarbeiten geht schneller als dreißig Formulare zu öffnen.

Aufteilung bei großen Beständen

Eine Datei mit zweihundert Beiträgen wird unhandlich. Vorgesehen ist deshalb die Aufteilung in Teildateien, die im Hauptarray zusammengeführt werden – etwa je Themenblock oder je Lieferwelle. Das hält die einzelnen Dateien lesbar und Änderungen überschaubar.

Wo die Grenze liegt

Der Seed ist ein Werkzeug für den Aufbau, nicht für den Alltag. Sobald ein Projekt läuft und redaktionell gepflegt wird, ist das Backend der richtige Ort. Zwei Wahrheiten für denselben Text sind eine Fehlerquelle: Die Datei sagt das eine, die Datenbank das andere, und beim nächsten Neuaufbau gewinnt die falsche.

Praktikabel ist die Trennung nach Zeitpunkt: Was zum Start gehört, kommt aus der Datei. Was danach entsteht, entsteht im Backend. Wer die Datei danach noch pflegt, sollte wissen, warum.

Ein Zwischenschritt: der Abgleich

Damit man nicht raten muss, gibt es einen Abgleich, der zeigt, welche Einstellungen von der Seed-Datei abweichen und welche Inhalte darin stehen, aber noch nicht in der Datenbank sind. Das ist der Weg, um nach ein paar Monaten festzustellen, was von der ursprünglichen Planung tatsächlich umgesetzt wurde.

Und wenn doch überschrieben werden soll?

Für den Fall einer grundlegenden Neuausrichtung gibt es einen ausdrücklichen Modus, der den Seed-Stand erzwingt. Er ist bewusst nicht die Voreinstellung: Wer ihn aufruft, sollte wissen, dass im Backend geänderte Texte danach weg sind.