Glossar
Content Blocks
Ein Ansatz, um eigene Inhaltselemente in TYPO3 kompakt zu definieren, statt Konfiguration über mehrere Dateien zu verteilen.
Was der Ansatz löst
Eigene Inhaltselemente sind in fast jedem TYPO3-Projekt nötig. Der klassische Weg verteilt ihre Definition über mehrere Dateien, was funktioniert, aber bedeutet, dass man für eine kleine Änderung an mehreren Stellen suchen muss.
Content Blocks fassen zusammen, was zusammengehört: Felder, Beschriftungen und Template liegen beieinander. Ein Element ist damit als Einheit erkennbar und lässt sich als Ganzes verschieben oder entfernen.
Was das für die Redaktion ändert
Aus Sicht der Redaktion ändert sich nichts. Ein Inhaltselement sieht im Backend gleich aus, unabhängig davon, wie es definiert wurde.
Der Unterschied liegt in der Wartbarkeit auf der Entwicklungsseite und damit indirekt darin, wie schnell Änderungswünsche umgesetzt werden können.
Wann der klassische Weg bleibt
Es gibt Fälle, in denen die ausführliche Konfiguration über TCA weiterhin passender ist, etwa bei sehr speziellen Feldtypen oder wenn ein Element eng mit einer bestehenden Extension verzahnt ist.
Beides parallel zu nutzen ist möglich. Wichtig ist nur, im Projekt eine Linie zu wählen und sie zu dokumentieren, damit nicht die Hälfte der Elemente so und die andere Hälfte anders gebaut ist.
Wie ein Content Block aufgebaut ist
Ein Content Block ist ein Verzeichnis. Darin liegt eine Beschreibung der Felder, dazu die Beschriftungen für die Oberfläche, das Fluid-Template für die Ausgabe und alles, was sonst dazugehört, etwa ein Vorschaubild für die Auswahlliste im Backend.
Aus dieser Beschreibung erzeugt die Erweiterung, was TYPO3 sonst erwartet: die Einträge im TCA, die nötige Datenbankspalte und die Verbindung zum Template. Der klassische Weg ist damit nicht abgeschafft, er wird nur nicht mehr von Hand geschrieben.
Nicht nur Inhaltselemente
Derselbe Ansatz deckt auch Seitentypen ab. Ein eigener Seitentyp mit eigenen Feldern, etwa für eine Pressemitteilung mit Datum und Ansprechpartner, entsteht auf demselben Weg wie ein Inhaltselement.
Das ist der praktische Vorteil gegenüber der Vorstellung, es gehe nur um ein paar Formularfelder: Zusammengehalten wird eine Struktur, nicht eine Ansammlung von Eingaben.
Der Bezeichner ist die eigentliche Entscheidung
Jeder Block trägt einen Bezeichner, und aus ihm leiten sich Tabellenwerte, Feldnamen und Sprachschlüssel ab. Er steht später in den Daten der Redaktion.
Ihn nachträglich zu ändern ist deshalb kein Umbenennen, sondern eine Datenmigration. Wer am Anfang zehn Minuten in die Benennung steckt, spart sich das später zuverlässig. Dasselbe gilt für Feldnamen innerhalb eines Blocks.
Verhältnis zu Mask
Mask verfolgt ein ähnliches Ziel, geht aber einen anderen Weg: Dort werden Elemente über eine Oberfläche im Backend zusammengeklickt, hier über Dateien im Sitepackage beschrieben.
Der Unterschied entscheidet sich weniger an den Funktionen als an der Arbeitsweise. Was in Dateien liegt, liegt in Git, lässt sich reviewen und wandert mit einem Deployment mit. Was im Backend entsteht, ist schneller da, muss aber zwischen Umgebungen anders übertragen werden.
Grenzen
Für den überwiegenden Teil der Inhaltselemente reicht der Ansatz aus. An seine Grenzen stößt er dort, wo ein Element eng mit eigener Logik verzahnt ist: eigene Datenbankabfragen, Formularverarbeitung, Anbindung an eine Schnittstelle.
Dann ist eine Extbase-Extension der passendere Ort, und der Content Block bleibt für das, wofür er gedacht ist: strukturierte Inhalte, die die Redaktion pflegt.