Entscheidungshilfe

Eigene Inhaltselemente: Content Blocks, Mask oder TCA

Individuelle Inhaltselemente sind der größte Einzelposten in vielen TYPO3-Projekten. Wie sie gebaut werden, entscheidet nicht darüber, wie sie im Backend aussehen, sondern darüber, was jede spätere Änderung kostet.

Warum diese Entscheidung Geld kostet

Ein eigenes Inhaltselement besteht aus drei Teilen: der Definition seiner Felder, der Beschriftung im Backend und dem Template für die Ausgabe. Wo diese drei Teile liegen und wie eng sie zusammengehören, bestimmt den Aufwand jeder späteren Änderung.

Genau hier liegt der Unterschied zwischen den Wegen. Alle drei erzeugen am Ende dasselbe Ergebnis im Backend. Sie unterscheiden sich darin, wie viele Stellen jemand anfassen muss, wenn nach zwei Jahren ein Feld dazukommt.

Der klassische Weg über TCA

Die Felddefinition steht im TCA, die Ausgabe in einem Fluid-Template, die Verbindung dazwischen in TypoScript. Das ist die ausführliche Variante, und sie ist nach wie vor der Weg mit den wenigsten Einschränkungen.

Sie lohnt sich, wenn ein Element eng mit einer Extension verzahnt ist, wenn ungewöhnliche Feldtypen gebraucht werden oder wenn die Logik über das hinausgeht, was ein Werkzeug abbilden soll. Der Preis ist Verteilung: drei Orte für eine Sache, und man muss wissen, wo man sucht.

Mask und der Stand heute

Mask hat diese Verteilung in eine Oberfläche gebracht. Felder anlegen, benennen, Template hinterlegen, fertig. Für Teams ohne eigene Entwicklungskapazität war das über Jahre der praktikabelste Weg.

Für TYPO3 v14 wird Mask nicht weiterentwickelt. Wer heute neu baut, sollte deshalb nicht mehr damit anfangen. Wer es im Bestand hat, hat Zeit bis zum nächsten großen Versionssprung und sollte die Umstellung dort einplanen.

Content Blocks als heutiger Standardweg

Content Blocks verfolgen dieselbe Grundidee, sind aber im Kern angekommen. Ein Element ist ein Verzeichnis: Feldbeschreibung, Beschriftungen, Template und Vorschaubild liegen beieinander. Was TYPO3 sonst erwartet, wird daraus erzeugt.

Für den Alltag heißt das zweierlei. Ein Element lässt sich als Ganzes verschieben, kopieren oder entfernen, ohne an drei Stellen aufzuräumen. Und es ist im Repository als Einheit sichtbar, was bei der Übergabe an andere Personen einen erheblichen Unterschied macht.

Der Weg setzt Entwicklungsarbeit voraus. Wer eine Oberfläche erwartet, in der die Redaktion selbst Elemente zusammenklickt, findet sie hier nicht.

Wo FlexForm wirklich hingehört

FlexForm taucht in dieser Diskussion regelmäßig auf, gehört aber eigentlich nicht in dieselbe Reihe. Es ist kein Weg, ein Inhaltselement zu bauen, sondern eine Möglichkeit, einzelne Datensätze mit zusätzlichen Einstellungen zu versehen, typischerweise die Konfiguration eines Plugins.

Als solches ist es nützlich. Problematisch wird es, wenn es als bequemer Ersatz für richtige Felder benutzt wird: Die Werte liegen in XML in einer einzigen Spalte, sind dadurch schlecht durchsuchbar, und eine spätere Strukturänderung wandert nicht automatisch in bestehende Datensätze. Ein Element mit fünfzehn FlexForm-Feldern ist ein Element, das jemand am falschen Ort gebaut hat.

Woran die Entscheidung tatsächlich hängt

Wer pflegt das Projekt danach? Steht laufend Entwicklungskapazität zur Verfügung, ist der Standardweg über Content Blocks unproblematisch. Gibt es sie nicht, ist die Frage wichtiger, wie oft überhaupt Änderungen zu erwarten sind.

Wie lange soll die Installation halten? Ein Auftritt, der fünf Jahre laufen soll, wird mindestens einen großen Versionssprung erleben. Ein Weg, der dort weiterläuft, spart genau diesen Umbau.

Wie viele Elemente sind es wirklich? Bei drei Elementen ist die Wahl zweitrangig. Bei dreißig wird sie zum Kostenfaktor, und dann lohnt sich die Frage, ob es wirklich dreißig sein müssen.

Was diese Entscheidung im größeren Rahmen bedeutet, steht unter Was ein TYPO3-Projekt teuer macht. Wie so ein Bestand technisch entsteht, behandelt die Seite TYPO3-Entwicklung.

Der Fehler, der teurer ist als jede Werkzeugwahl

Elemente entstehen leichter, als sie verschwinden. In fast jedem gewachsenen Projekt gibt es Elemente, die einmal für eine Kampagne gebaut wurden und seitdem in der Auswahlliste stehen, ohne irgendwo verwendet zu werden.

Der Aufwand dafür fällt zweimal an: bei jedem Versionssprung, weil sie geprüft werden müssen, und bei jeder Einarbeitung, weil jemand herausfinden muss, wofür sie gedacht waren. Eine jährliche Durchsicht mit der Frage „wo wird das benutzt“ ist die billigste Maßnahme in diesem ganzen Themenfeld.

Häufige Fragen

Merkt die Redaktion, welcher Weg gewählt wurde?

Im Alltag nicht. Ein Inhaltselement zeigt im Backend seine Felder, gleichgültig ob sie aus einem Content Block, aus Mask oder aus handgeschriebenem TCA stammen. Die Bedienung ist dieselbe.

Spürbar wird der Unterschied an anderer Stelle: bei der Frage, wie schnell ein zusätzliches Feld ergänzt oder eine Beschriftung geändert werden kann.

Wir setzen Mask ein. Müssen wir jetzt sofort umstellen?

Nicht sofort. Solange die Installation auf einer Version läuft, die noch gepflegt wird, funktioniert der Bestand weiter. Handlungsbedarf entsteht mit dem Sprung auf TYPO3 v14.

Sinnvoll ist es, die Umstellung in denselben Zug zu legen wie den Versionssprung. Die Elemente müssen bei einem Update ohnehin geprüft werden, und zweimal durch dieselben Elemente zu gehen ist die einzige wirklich vermeidbare Arbeit dabei.

Wie viele eigene Elemente sind normal?

Weniger, als in den meisten Projekten entstehen. Der übliche Verlauf: Für jede Gestaltungsidee entsteht ein eigenes Element, und nach zwei Jahren steht in der Auswahlliste eine Sammlung, in der niemand mehr den Überblick hat.

Der bessere Ansatz ist, wenige Elemente mit ein paar Einstellungen zu bauen statt vieler Varianten desselben Gedankens. Das reduziert nicht nur den Entwicklungsaufwand, sondern vor allem die Fehlbedienung in der Redaktion.

Kann man Wege mischen?

Technisch ja, und in gewachsenen Projekten ist es die Regel. Empfehlenswert ist es trotzdem nicht als Dauerzustand: Wer eine Änderung machen will, muss dann zuerst herausfinden, nach welchem Muster das betroffene Element gebaut ist.

Wenn gemischt wird, sollte die Linie wenigstens dokumentiert sein: Neue Elemente auf dem einen Weg, Bestand bleibt vorerst, Migration bei Gelegenheit.

Unübersichtliche Elementliste?

Wir sehen uns an, welche Elemente wirklich benutzt werden und was sich zusammenfassen lässt. Das Ergebnis ist meist eine deutlich kürzere Liste.