Weg mit den Klonen!
Kontext statt Content-Type-Explosion.
Stellen wir uns einen Redakteur vor, der mit einer völlig normalen Card arbeitet. Sie hat ein Bild, eine Überschrift, etwas Text und einen Link. Nichts besonders Exotisches. Dann braucht jemand eine kleinere Version. Später soll dieselbe Art von Card in einem Slider funktionieren. In einer weiteren Projektphase kommt eine hervorgehobene Variante hinzu.
Und ehe man sich versieht, hat diese harmlose kleine Card die Tür zu einem überraschend großen Familientreffen geöffnet: Card, Slider Card, Compact Card, Sidebar Card und Dark Sidebar Event Card with Image Left.
Niemand nimmt sich vor, eine solche Sammlung aufzubauen. Sie wächst mit einer vollkommen nachvollziehbaren Anforderung nach der anderen. Und jede einzelne Ergänzung wirkt harmlos. Ein weiterer Content-Type. Eine weitere Option im Wizard. Eine weitere Lösung für eine ganz bestimmte Situation. Bis irgendwann Jahre später jemand auf das Ergebnis schaut und die Frage stellt, die man wahrscheinlich viel früher hätte stellen sollen:
Geschätzte Lesezeit: 6 Minuten
Sind das wirklich unterschiedliche
Arten von Inhalten?
Oder erzeugen wir Klone nur weil derselbe Inhalt zufällig in einem anderen Kontext erscheint? Dieser Unterschied ist wichtig.
Eine andere Rolle bedeutet nicht automatisch eine andere Inhaltsidentität. Ein anderes Erscheinungsbild macht aus etwas nicht zwangsläufig neuen Inhalt. Und Struktur kann eigene Informationen tragen, ohne dass diese Informationen in einen weiteren Content-Type gezwungen werden müssen.
Genau hier verfolgt Grid Elements einen grundlegend anderen Ansatz. Statt zu fragen, wie einfach wir den nächsten spezialisierten Content-Type erzeugen können, können wir eine viel interessantere Frage stellen: Brauchen wir ihn überhaupt?
Diese Frage wird mit wachsenden Projekten immer wichtiger. Was mit einer Handvoll sinnvoller Varianten beginnt, kann sich langsam zu einem Content-Modell voller spezialisierter Auswahlmöglichkeiten, duplizierter Ideen und technischer Altlasten entwickeln. Die eigentliche Herausforderung besteht nicht darin, die nächste Variante zu erzeugen. Sie besteht darin zu entscheiden, welche Unterschiede zum Inhalt selbst gehören und welche zum Kontext, in dem dieser Inhalt verwendet wird.
Was gehört wohin?
Andere Aspekte, andere Aufgaben.
TYPO3 gibt uns dazu eigentlich schon seit Jahren einen nützlichen Hinweis. Öffnet man im Backend ein Inhaltselement, findet man getrennte Bereiche für den Inhalt selbst, sein Erscheinungsbild und sein Verhalten.
Diese Trennung fühlt sich vollkommen selbstverständlich an.
Wenn sich das Erscheinungsbild ändert, wird aus einem Inhalt nicht plötzlich etwas anderes. Dasselbe gilt für sein Verhalten. Es ändert sich, wie dieser Inhalt dargestellt wird oder wie er sich in einer bestimmten Situation verhält.
Die Idee reicht zurück bis zur User Experience Week 2009. In derselben Zeit, in der das strukturelle Denken hinter den Backend Layouts entstand, hielt auch diese Unterscheidung Einzug in die redaktionelle Arbeit. Inhalt, Erscheinungsbild und Verhalten wurden als getrennte Verantwortlichkeiten behandelt.
Warum also sollte Struktur anders behandelt werden? Warum sollte das Platzieren von Inhalten in einem anderen strukturellen Kontext automatisch einen weiteren Content-Type erfordern? Genau hier wird Kontext mächtig. Der Inhalt kann weiterhin beschreiben, was er ist, während seine Umgebung mitbestimmt, wie er an dieser konkreten Stelle aussehen, sich verhalten oder verwendet werden soll.
Manchmal ist es klüger, die Situation für sich selbst sprechen zu lassen.
Wenn Struktur zu Inhalt wird
Eine Abkürzung, viele Folgen.
Spätestens hier zeigt sich, warum dieser Unterschied in der Praxis wichtig ist. Eine Struktur beschreibt, wie Inhalte angeordnet sind. Sie kann Bereiche, Beziehungen und die Plätze definieren, an denen Inhalte erscheinen dürfen. Ein Content-Type hingegen beschreibt, was der Inhalt selbst tatsächlich ist. Das sind zwei unterschiedliche Aufgaben.
EXT:container trifft dabei eine sehr konkrete architektonische Entscheidung. Jede Container-Konfiguration wird als eigener Content-Type registriert. Damit wird jedes Grid ganz bewusst Teil des Content-Type-Modells.
Auf den ersten Blick wirkt das harmlos. Ein weiterer Content-Type, eine weitere konkrete Lösung. Doch sobald Struktur in die Inhaltsidentität hineinrutscht, vermehren sich die Klone schnell. Werkzeuge wie Content Blocks machen es leicht, spezialisierte Content-Types zu erstellen, während andere Pakete gleich ganze Sammlungen mitbringen.
Das ist sinnvoll, wenn der Inhalt tatsächlich neu ist. Problematisch wird es, wenn Unterschiede in Zweck, Darstellung oder Platzierung immer wieder zu neuen Typen werden, oft mit eigenen Feldern und technischem Ballast. Das Problem ist nicht, Content-Types zu erstellen. Das Problem ist, sie für Unterschiede zu erstellen, die nicht zur Inhaltsidentität gehören.
Struktur verdient eine eigene Ebene im Content-Modell.
Kontext verändert das Bild
Derselbe Inhalt kann anderswo etwas anderes bedeuten
Sobald Struktur unabhängig modelliert wird, passiert etwas Interessantes. Sie kann beginnen, eigene Informationen beizutragen. Eine Card innerhalb eines Sliders bleibt eine Card. Aber ihr Platz in dieser Struktur sagt uns etwas darüber, wie sie verwendet werden soll.
Dasselbe gilt für einen Teaser in einer Sidebar, ein Element innerhalb eines Akkordeons oder Inhalte in einem prominenten Feature-Bereich. Der Inhalt behält seine Identität. Seine Umgebung fügt Kontext hinzu.
Und Kontext ist oft der Ort, an dem Bedeutung beginnt.
Ohne Kontext haben Worte und Handlungen überhaupt keine Bedeutung.
Die richtigen Dinge trennen
Code ist nur die halbe Geschichte
„Separation of Concerns“ klingt beruhigend. Eine Extension übernimmt eine Aufgabe, eine andere kümmert sich um etwas anderes, und der Code bleibt sauber organisiert. Aber Redakteure arbeiten nicht mit Composer-Paketen. Sie arbeiten mit Inhalten.
Für sie ist die entscheidende Frage, ob das Content-Modell selbst Inhalt, Struktur, Erscheinungsbild, Verhalten und Kontext voneinander trennt. Diese Aspekte dürfen zusammenspielen, aber sie sollten nicht alle Teil derselben Identität werden müssen.
EXT:container hält seinen technischen Aufgabenbereich bewusst schmal. Dennoch wird jeder konfigurierte Container zu einem eigenen Content-Type. Content Blocks ergänzen diese technische Trennung auf einer weiteren Package-Ebene. Das hält die jeweiligen Pakete fokussiert, während Struktur und Inhaltsidentität im Content-Modell selbst wieder vermischt werden.
Grid Elements zieht diese Grenze an einer anderen Stelle.
Der Inhalt kann seine Identität behalten, während Struktur, Bereiche, Beziehungen und Regeln separat definiert werden. Kontext kann dann Bedeutung hinzufügen, ohne jede neue Situation in einen weiteren Content-Type zu zwingen. Dieser Unterschied wird immer wichtiger, wenn Projekte wachsen und Anforderungen sich weiter verändern. Separation of Concerns sollte nicht dort aufhören, wo Content beginnt.
Struktur braucht Regeln
Ein Platz kann eine Aufgabe vorgeben
Wenn Struktur eigenständig modelliert wird, kann sie mehr, als Inhalte nur auf einer Seite anzuordnen. Ein Bereich kann beschreiben, was dorthin gehört, wie viel davon sinnvoll ist und welche Art von Inhalt zu der Rolle passt, die dieser Bereich vorsieht.
Grid Elements unterstützt diese Idee schon seit den frühen Versionen. Bereiche können einschränken, was Redakteure darin platzieren dürfen und wie viele Elemente sie enthalten können. Neuere Implementierungen können sogar zusätzliche Eigenschaften des Inhalts berücksichtigen, statt nur auf seinen Content-Type zu schauen.
Eine Zeit lang wurden Teile dieser Idee in die separate Extension Content Defender überführt und dort in allgemeinerer Form verfügbar gemacht. Die Implementierung lag in einem anderen Paket, aber die Regeln gehörten weiterhin zu der Struktur, die sie brauchte.
Diese Unterscheidung ist wichtig. Funktionalität in ein anderes Paket zu verschieben, verschiebt nicht automatisch auch die Verantwortung dorthin. Eine Struktur, die ihren Zweck kennt, sollte auch beschreiben können, was in ihr sinnvoll ist.
Das ist keine zusätzliche Dekoration rund um das Content-Modell. Es ist Teil dessen, was Struktur Bedeutung gibt.
Den Klon-Kreislauf durchbrechen
Kontext verändert das Spiel
Wenn Inhalt, Struktur und Kontext unterschiedliche Aufgaben übernehmen dürfen, muss Vielfalt nicht länger aus einem ständig wachsenden Katalog spezialisierter Content-Types entstehen.
Einige wenige gut gestaltete Bausteine können plötzlich eine viel größere Bandbreite an Situationen abdecken. Dieselbe Card kann an unterschiedlichen Stellen funktionieren, ohne jedes Mal zu einer neuen Art von Card zu werden. Struktur liefert Beziehungen, Kontext fügt Bedeutung hinzu, und Erscheinungsbild oder Verhalten können sich dort anpassen, wo es nötig ist.
Für Redakteure bedeutet das weniger fast identische Auswahlmöglichkeiten und weniger Wissen über technische Konventionen, die ohnehin nie ihre Aufgabe sein sollten. Für Designer und Integratoren bedeutet es mehr Freiheit, Kombinationen zu gestalten, ohne jede neue Idee in weitere dauerhafte Typen zu verwandeln. Komplexität verschwindet nicht. Sie wandert einfach an eine bessere Stelle.
Statt immer mehr Bedeutung in Namen wie Slider Card, Compact Card oder Dark Sidebar Event Card with Image Left zu verstecken, kann das Modell diese Bedeutung über Struktur, Beziehungen und Kontext ausdrücken.
So hören die Klone auf, sich zu vermehren.
Bedeutung, die mitwandert
Klar für Menschen und Maschinen
Ein gutes Content-Modell sollte für die Menschen verständlich sein, die damit arbeiten. Redakteure sollten verstehen, was etwas ist, wohin es gehört und was passiert, wenn sich sein Kontext ändert, ohne dafür einen Katalog technischer Varianten auswendig lernen zu müssen.
Gleichzeitig machen explizite Struktur, Beziehungen und Kontext Bedeutung auch über die redaktionelle Oberfläche hinaus leichter verständlich. Was für Menschen klar ist, wird auch für Systeme klarer, die Inhalte später interpretieren müssen.
Grid Elements nähert sich beiden Seiten mit demselben Prinzip. Menschen bekommen eine Struktur, die sie verstehen können, während genug davon explizit bleibt, damit auch Maschinen sie verstehen können. Und sobald Inhalt seine Identität behalten und gleichzeitig in unterschiedlichen Kontexten verschiedene Rollen übernehmen kann, ergibt sich ganz natürlich die nächste Frage.
Was passiert, wenn derselbe Inhalt in mehr als einem Kontext erscheinen soll?
Das führt uns zum nächsten Schritt der Geschichte: Referenzen statt Content-Duplikation.
Inhalt braucht nicht jedes Mal eine neue Identität, wenn sich seine Rolle, sein Erscheinungsbild oder sein Kontext ändert. Grid Elements hält Inhaltsidentität, Struktur und Kontext bewusst getrennt. Dadurch wird nicht jedes neue Layout oder jede neue Variante automatisch zu einem weiteren Content-Type, und das langsame Wachstum fast identischer Klone wird vermieden. Für Redakteure bedeutet das klarere Auswahlmöglichkeiten und weniger unnötige Varianten. Für Designer und Integratoren bedeutet es mehr Freiheit durch Komposition. Und im Content-Modell bleibt Bedeutung dort, wo sie hingehört, statt in spezialisierten Typnamen versteckt zu werden. Erstellt neue Content-Types, wenn der Inhalt selbst tatsächlich neu ist. Lasst Struktur und Kontext den Rest übernehmen.
Empfehlungen
Coders.Care ist die logische Weiterentwicklung in der Zusammenarbeit zwischen Anbietern von TYPO3 -Extensions und deren Nutzern. Insbesondere das Thema Kommunikation im Vorfeld eines Projekts wird hierdurch optimiert. Die Entwickler können sich ganz auf ihre Stärken konzentrieren, während Coders.Care sich um Beantwortung von Fragen und Management kümmern kann. Die Folge eines solchen Angebots sind klare Aussagen zum Thema Pflege und Weiterentwicklung von TYPO3-Erweiterungen und somit wird das Vertrauen in TYPO3 und die damit umgesetzten Projekte gestärkt. Als TYPO3-Agentur können wir von einem solchen Angebot nur profitieren.
© Copyright 2026 Cybercraft GmbH