Dies ist kein Artikel darüber, welches Content-Management System das Beste ist. Eine Frage, die man sowieso nicht mit dem Namen eines einzelnen Systems beantworten kann.
Zu verhärtet schienen eine zeitlang die Fronten zwischen den Anhängern einzelner Systeme. Ich nehme mich hier nicht aus – als TYPO3-Entwickler bin ich großer Fan dieses Systems, kenne durch über zehnjährige Arbeit damit dessen Vor- und Nachteile und selbstverständlich auch die anderer Redaktionssysteme wie WordPress, Drupal oder Neos.
Features über Features … oder?
Wenn man sich die Diskussionen ansieht, gewinnt man den Eindruck, es drehe sich alles um den Funktionsumfang: Mehrsprachigkeit, Benutzerverwaltung, einfache Bedienung/WYSIWYG, Entwurfs- und Live-Umgebung, Multi-Site, Domainverwaltung, Erweiterbarkeit durch Plugins …
Seltener erwähnt: Stabilität und Code-Qualität, Support und Gesamtkosten (Total Cost of Ownership). Und nahezu ignoriert: Flexibilität und Anpassungsmöglichkeiten des Content Models.
Was ist ein Content Model?
Besinnen wir uns einmal auf die Kernfunktion eines Content-Management Systems zurück – der Verwaltung von Inhalten. Natürlich mit einer sauberen Trennung von Inhalt und Layout.
Das Content Model definiert verschiedene Inhaltstypen, deren Eigenschaften sowie Beziehungen zu anderen Inhalten. Dieses Model kann hinsichtlich Komplexität und Granularität höchst unterschiedlich sein: von atomar (eine Überschrift, ein Absatz, ein Bild, eine Liste, …) bis relativ grob (eine Seite, eine News, ein Inhaltselement mit einem Rich-Text-Feld).
Je nach Anwendungsgebiet kann es sinnvoll sein, Inhalte ineinander zu verschachteln. Hierdurch entsteht dann eine Content-Hierarchie, die sich als Baum darstellen lässt – das bekannteste Beispiel ist wohl der Seitenbaum. Selbiges Prinzip kann aber auch auf tiefere Ebenen des Content Models angewandt werden.
Beispiel: WordPress
Bei WordPress ist die Basis des Content Models ein „Post“ (gespeichert in der Tabelle wp_posts). Dieser kann unterschiedliche Formen annehmen, definiert durch den sogenannten „Post Type“, um damit unterschiedliche Inhaltstypen wie Artikel, Seiten oder weitere, eigene Typen abzubilden. Jeder Post hat dann in der Regel eine Überschrift sowie ein Rich-Text Feld für den eigentlichen Text.
Es findet keine Abstraktion zwischen Post und dem Inhalt des Posts statt – es gibt also keine kleinere Einheit als den Post. Bei komplexen Seiten stößt man hier schnell an die Grenzen, wenn man nicht alles über den Rich-Text Editor abbilden kann. Erst über Plugins wie Advanced Custom Fields (ACF) oder andere Template Builder wie Divi wird ein modularer Seitenaufbau möglich.
Beispiel: TYPO3 CMS
TYPO3 geht hier einen kleinen, aber bedeutenden Schritt weiter: es wird unterschieden zwischen Seiten (gespeichert in der Tabelle pages) und Inhaltselementen (gespeichert in der Tabelle tt_content). Dies ermöglicht eine flexiblere Erstellung von Seiten, da der Seiteninhalt aus mehreren verschiedenen Inhaltselementen (z.B. Überschrift, Text, Text mit Bild, Bildergalerie, oder ein Plugin) aufgebaut werden kann.
Leider können im TYPO3 Core diese Inhalte nicht ineinander verschachtelt werden. Dies ist erst über Extensions wie DCE, Grid Elements, FluidTYPO3 oder (früher) TemplaVoila möglich.
Beispiel: Neos
Und hier setzt Neos an. Bei diesem relativ jungen CMS dreht sich alles um Nodes. Ein Node kann unterschiedliche Formen annehmen, definiert durch den NodeType. Durch beliebig tiefe Verschachtelung von Nodes lassen sich komplexe Node-Hierarchien aufbauen, die zur Darstellung aller nur denkbarer Inhalte geeignet sind.
Zwei grundlegende Node-Typen unterschiedet Neos von Haus aus: die Document-Nodes (quasi eine Seite im Seitenbaum) und die Content-Nodes, die dann Inhalte auf einer Seite darstellen (ähnlich TYPO3). Durch die Verschachtelung von Content-Nodes lassen sich beispielsweise Layout-Strukturen wie mehrspaltige Inhalte oder Slider mit komplexen Slide-Items umsetzen.
Warum ist das Content Model so wichtig?
Weil es bestimmt, welche Inhalte es gibt, wie diese gepflegt werden können, wie diese in der Datenbank gespeichert werden und dadurch nicht zuletzt: wie (schnell) diese durch den Entwickler angepasst werden können.
Müssen die Datenbanktabellen erweitert werden, um Eigenschaften zu einem Inhalt hinzuzufügen (TYPO3)? Werden diese über eine Meta-Tabelle normalisiert, und dadurch sehr verteilt, in der Datenbank abgelegt (WordPress)? Oder werden diese Daten schemalos, ähnlich einer dokumentbasierten Datenbank wie MongoDB, als JSON oder XML in einem Feld der Tabelle gespeichert (Neos, FluidTYPO3, TemplaVoila …)?
Durch das zugrundeliegende Konzept wird maßgeblich der Workflow der (Weiter-)Entwicklung und des Deployments bestimmt, da bei Änderungen des Content Models möglicherweise Datenbankmigrationen durchgeführt werden müssen. Zudem können leicht Datenleichen in der Datenbank entstehen, wenn bestimmte Merkmale später doch nicht mehr genutzt werden.
Auch für die Inhaltsmigration ist das Content Model relevant: es bestimmt, auf welche Weise und in welcher Struktur Inhalte importiert und exportiert werden können.
Das Content Model ist daher eine sehr wichtige, oft vernachlässigte Funktion eines Content-Management Systems – die bei der Systementscheidung aber eine zentrale Rolle spielen sollte.