Es gibt zwei Arten von CMS, und der Unterschied entscheidet dauerhaft darüber, wie viel Handarbeit Ihre Website kostet. Das eine speichert Seiten. Das andere speichert Daten und erzeugt daraus Seiten. Das zweite nennt man relational, die meisten Website-Baukästen bieten es nicht an, und der Unterschied wird erst offensichtlich, sobald Sie ein paar hundert Einträge haben und diese auf mehr als eine Art ordnen müssen.
Was bedeutet relational eigentlich?
Es bedeutet, dass Ihre Sammlungen aufeinander verweisen können und die Datenbank diese Verknüpfungen durchsetzt. Zwei Formen decken fast alles ab:
- Eins zu viele. Ein Beitrag gehört zu einer Kategorie, eine Bestellung zu einem Kunden, eine Immobilie zu einer Stadt. Der besitzende Datensatz speichert einen Verweis auf genau ein Ziel, es können also unmöglich zwei werden.
- Viele zu viele. Ein Beitrag trägt mehrere Schlagworte, eine Agentur bietet mehrere Leistungen an. Dafür braucht es eine echte Verknüpfung zwischen beiden Sammlungen und kein Textfeld voller Kommas.
Das entscheidende Wort ist durchsetzt. In einem relationalen System kann ein Verweis nicht auf etwas zeigen, das es nicht mehr gibt, weil die Datenbank sich weigert. In einem flachen System hinterlässt das Löschen einer Kategorie in jedem Beitrag stillschweigend eine tote Bezeichnung.
Warum ist das für eine Website wichtig?
Weil Beziehungen es einer Sammlung erlauben, ganze Seitengruppen zu erzeugen. Definieren Sie Beiträge und Kategorien sauber, und Sie erhalten Kategorieseiten, gefilterte Listen, Blöcke mit verwandten Einträgen und die Brotkrumennavigation automatisch aus derselben Struktur, und sie bleiben richtig, während sich die Inhalte ändern.
Ohne Beziehungen bauen Sie jedes davon von Hand. Eine Kategorie hinzuzufügen heißt: eine Seite anlegen, sie in ein Menü eintragen und daran denken, künftige Beiträge dort einzuordnen. Eine umzubenennen heißt, jede Stelle zu finden, an der der alte Name getippt wurde. Diese Arbeit hört nie auf, sie sammelt sich nur leise an, bis die Pflege der Website zu mühsam wird.
Woran flache Inhaltsmodelle scheitern
Drei Schwachstellen, ungefähr in der Reihenfolge, in der man auf sie stößt.
- Getippt statt ausgewählt. Wenn eine Kategorie ein Textfeld statt eines Verweises ist, haben Sie irgendwann „Design“, „design“ und „Desgin“ als drei Kategorien, und keine Liste zeigt alles.
- Umbenennen wird zur Migration. Ändern Sie einen Kategorienamen, und jeder Datensatz mit der alten Zeichenkette ist falsch, bis jemand sie alle gefunden hat.
- Nur eine Ordnung möglich. Flache Inhalte lassen sich nur auf eine Art auflisten. Verknüpfte Inhalte lassen sich nach Kategorie, Schlagwort, Autor, Ort und jeder Kombination auflisten, ohne einen einzigen Datensatz zu duplizieren.
Die Felder zählen ebenfalls
Eine Sammlung ist nur brauchbar, wenn sich jedes Feld so bearbeiten lässt, wie es sein Inhalt verdient. Überall nur Textfelder, so landet am Ende rohes HTML in einer Beschreibung. Was ein ernsthaftes CMS bieten sollte:
- Rich Text mit einem echten Editor für Artikel- und Seitentexte
- Bilder mit Vorschau, Austausch und direkt daneben bearbeitetem Alternativtext, dazu geordnete Galerien, in denen jedes Bild seinen eigenen Alternativtext trägt
- Dateien für alles, was kein Bild ist: PDFs, Tabellen, Archive
- Farbe als Farbfeld mit Auswahldialog statt eines Hex-Codes, bei dem man sich vertippen kann
- Zeitstempel vom System verwaltet, damit Erstellt und Geändert der Wahrheit entsprechen und nicht dem, was jemand eingetragen hat
Der Alternativtext verdient eine eigene Erwähnung. Wenn er direkt neben dem Bild steht statt in einem separaten Feld an anderer Stelle, wird er tatsächlich ausgefüllt, und genau das ist der Unterschied zwischen einer barrierefreien Website und einer Beanstandung im Audit.
Wie macht Modulify das?
Die Datenbank hinter einem Projekt ist echtes PostgreSQL, per SQL abgefragt, und kein proprietärer Inhaltsspeicher. Deshalb sind die oben beschriebenen Beziehungen echte Datenbankbeziehungen und keine Bequemlichkeit im Editor, und deshalb lassen sich die Daten auch als CSV, JSON oder SQL exportieren und in jedes gängige System übernehmen.
Text aus der Datenbank lässt sich außerdem direkt auf der Seite bearbeiten: Klicken Sie in der Vorschau auf eine Überschrift oder eine Beschriftung, tippen Sie darüber, und die Änderung wird in diesen Datensatz zurückgeschrieben. Auf einer mehrsprachigen Website landet sie in der Sprache, die Sie gerade ansehen, was erstaunlich viel Hin und Her zwischen Reitern erspart.
Eine ehrliche Einschränkung. Sie können Datensätze selbst anlegen, bearbeiten, durchsuchen, duplizieren und löschen, aber Sie können im CMS keine Tabellen erstellen oder umbauen und keinen Feldtyp ändern. Das geschieht auf Anfrage, was die Struktur schlüssig hält, aber eben bedeutet, dass strukturelle Änderungen über eine Anfrage laufen und nicht über einen Einstellungsdialog.
Woran erkenne ich, ob mein CMS relational ist?
Zwei schnelle Tests, ganz ohne Dokumentation.
- Ist das Kategoriefeld eine Auswahlliste vorhandener Datensätze oder ein Textfeld? Eine Auswahlliste, die aus einer anderen Sammlung gespeist wird, ist ein Verweis. Ein Textfeld ist eine Zeichenkette, und Zeichenketten driften auseinander.
- Benennen Sie eine Kategorie um. Was geht kaputt? Wenn sich alles aktualisiert, was auf sie verwiesen hat, ist es relational. Wenn Sie jetzt jeden Datensatz einzeln finden und korrigieren müssen, ist es das nicht.
Wenn Ihre Inhalte aus ein paar Dutzend Seiten bestehen, die sich selten ändern, wird Sie nichts davon stören. Sobald Sie Einträge haben, die zu etwas gehören, und die sich auf mehr als eine Art auflisten lassen müssen, entscheidet es darüber, ob die Website von selbst wächst oder durch Ihre Hand. Den größeren Zusammenhang finden Sie unter wie KI eine vollwertige Anwendung mit echter Datenbank baut, und wie dieselbe Struktur mehrere Sprachen trägt.
