Zurück zum Inhalt
Wo es hingeht, brauchen wir keine Seiten.
Eine fertige Seite bringt Inhalt, Struktur und Kontext zusammen. Doch sie ist nur ein mögliches Ziel. Sobald dieselben Inhalte an anderer Stelle gebraucht werden, wird eine andere Frage interessant. Wie viel von dem, was bereits in TYPO3 organisiert wurde, sollte mit ihnen weiterreisen?
Wörter und Bilder sind meist der einfache Teil. Entscheidend ist oft, wie sie zusammengehören. Ein Redakteur hat vielleicht längst festgelegt, welche Inhalte eine Einheit bilden, was miteinander verbunden ist und welche Funktion eine Gruppe durch ihre Konfiguration bekommt. Wenn später ein anderes System diese Inhalte weiterverarbeitet, sollte es diese Zusammenhänge nicht erst wieder neu erschließen müssen.
Geschätzte Lesezeit: 7 Minuten
Das Bild verblasst
Datensatz-Listen sind nicht die ganze Geschichte
Sobald Inhalte ihre Seite verlassen, ist es meist kein Problem, an die einzelnen Datensätze zu kommen. Eine Überschrift bleibt eine Überschrift, ein Bild bleibt ein Bild und ein Textelement behält seinen Inhalt.
Trotzdem kann zwischen dem Einsammeln all dieser Teile und dem Verständnis dafür, wie sie zusammengehören, etwas verloren gehen. Stell dir einen Abschnitt mit einer Einleitung, zwei zusammengehörigen Elementen und einem zusätzlichen Hinweis vor, der zum zweiten der beiden gehört.
Als flache Liste können alle vier Datensätze vollständig und unversehrt ankommen. Was die Liste nicht unbedingt verrät, ist, welche Teile eine Gruppe bilden, welches Element ein anderes enthält oder welche Beziehung ihnen überhaupt erst ihre Rolle gibt. Das wird wichtig, sobald der nächste Consumer mehr tun soll, als Datensätze einfach der Reihe nach auszugeben.
Ein Renderer, ein Indexer oder eine andere Anwendung muss möglicherweise verstehen, welche Elemente zusammengehören, welche Teile eine Einheit bilden und wo eine Struktur endet und die nächste beginnt. Ohne diese Informationen sind die einzelnen Bestandteile zwar noch vorhanden, doch manche Entscheidungen, die beim Zusammenstellen getroffen wurden, sind nicht mehr sichtbar.
Sobald wir also über eine einzelne fertige Seite hinausdenken, lohnt sich die Frage, woher diese Beziehungen eigentlich kommen sollen.
Denk vierdimensional
Struktur prägt die Möglichkeiten von morgen
Structure-first Authoring beginnt lange bevor jemand über APIs, Suchindizes oder eine andere Anwendung nachdenkt, die Inhalte weiterverarbeitet. Es beginnt in dem Moment, in dem ein Redakteur entscheidet, dass mehrere Inhalte zusammengehören, dass ein Element in ein anderes gehört oder dass eine bestimmte Anordnung eine bestimmte Rolle erfüllt.
Diese Entscheidungen schaffen Möglichkeiten für alles, was später an Anwendungsfällen hinzukommt.
Werden Beziehungen von Anfang an explizit abgebildet, können sie auch dann noch verfügbar sein, wenn der Inhalt seine ursprüngliche Seite verlässt. Existieren diese Beziehungen nur implizit in einem bestimmten Rendering oder müssen sie daraus abgeleitet werden, wo etwas zufällig erscheint, bleibt für einen anderen Consumer deutlich weniger, womit er arbeiten kann.
Deshalb ist Struktur mehr als nur eine bequeme Möglichkeit, Inhalte im Backend anzuordnen. Sie kann Informationen darüber speichern, wie Inhalte miteinander zusammenspielen sollen. Je früher diese Information Teil des Modells wird, desto mehr Möglichkeiten bleiben für alles offen, was später kommt. Und genau hier kann Grid Elements den nächsten Schritt gehen. Die Struktur, die Redakteure bereits geschaffen haben, muss nicht im Backend verbleiben.
Zeitschaltkreise an!
Struktur kann mit dem Inhalt reisen
Hier wird aus der Idee etwas ganz Konkretes. Wenn Redakteure bereits eine sinnvolle Struktur geschaffen haben, stellt sich als Nächstes die Frage, ob diese Struktur die Seite gemeinsam mit dem Inhalt verlassen kann. Mit Grid Elements kann sie das.
Statt ein Grid Element als einzelnen Datensatz zu behandeln und alles andere später erneut erschließen zu müssen, lassen sich die enthaltenen Elemente als Teil der aufbereiteten Daten mitgeben. Dazu gehört nicht nur die Information, dass sie existieren, sondern auch, wie sie angeordnet sind.
Grid Elements nutzt dafür einen eigenen TYPO3 Data-Processor, den GridChildrenProcessor. Zeilen, Spalten und verschachtelte Gruppen müssen nicht in dem Moment verschwinden, in dem die Seite nicht mehr das einzige Ziel ist. Das ist wichtig, denn Struktur ist häufig selbst Teil der Information. Eine Gruppe zusammengehöriger Elemente ist etwas anderes als eine zufällige Reihenfolge. Ein Hinweis innerhalb einer bestimmten Spalte ist etwas anderes als einer, der lediglich zufällig in der Nähe erscheint.
Bleiben diese Beziehungen erhalten, kann der nächste Consumer mit Inhalten arbeiten, die bereits mehr von ihrem eigenen Kontext mitbringen. Genau darum geht es. Das System muss nicht so tun, als hätte es die Struktur nie gegeben, um sie später mühsam wieder herzuleiten. Es kann den Inhalt zusammen mit der Anordnung weitergeben, welche die Redakteure bereits geschaffen haben.
Wenn meine Berechnung stimmt ...
Nimm nur mit, was wirklich gebraucht wird
Struktur mitzunehmen bedeutet nicht, jedes Mal alles einzupacken. Unterschiedliche Consumer haben unterschiedliche Aufgaben, und damit kann sich auch die passende Darstellung desselben Inhalts je nach Einsatzbereich ändern.
Manchmal ist eine flache Liste genau das Richtige. Manchmal sind Zeilen und Spalten wichtig. Und manchmal profitiert der nächste Schritt davon, wenn mehrere verschachtelte Ebenen bereits vorbereitet sind.
Grid Elements kann die Verarbeitung genau an diesen Anforderungen ausrichten. Zeilen und Spalten können beibehalten oder weggelassen werden, Backend-Layout-Informationen lassen sich auflösen, und recursive steuert, wie viele zusätzliche Ebenen einer verschachtelten Struktur im selben Verarbeitungsschritt vorbereitet werden.
Das begrenzt weder die mögliche Verschachtelungstiefe von Grid Elements noch die Tiefe des Renderings. Es entscheidet lediglich, wie viel dieser Struktur für den aktuellen Consumer bereits zusammengestellt werden soll.
Dasselbe Prinzip gilt für die Konfiguration. FlexForm-Werte eines Grid Elements und bei Bedarf auch die seiner untergeordneten Elemente können bereits in direkt nutzbare Werte aufgelöst werden. Backend-Layout-Informationen lassen sich auf dieselbe Weise vorbereiten. So kann der nächste Consumer die relevante Layout-Struktur zusammen mit dem Inhalt erhalten, statt sie separat rekonstruieren zu müssen.
Auch das muss nicht pauschal geschehen. Ein Plugin, das seine eigenen FlexForm-Daten erwartet und selbst verarbeitet, sollte das womöglich weiterhin tun. Ein anderer Consumer kann dagegen davon profitieren, die vorbereiteten Werte direkt zu erhalten. Entscheidend ist, dass beides möglich ist.
Es geht also weniger darum, wie viele Daten Grid Elements bereitstellen kann, sondern darum, was der nächste Schritt tatsächlich braucht. Struktur, Tiefe und Konfiguration lassen sich entsprechend vorbereiten, ohne jede Reise zu einer Expedition zu machen, bei der gleich der gesamte Hausstand im Kofferraum landet.
Alles sollte so einfach wie möglich gemacht werden, aber nicht einfacher.
Kennen wir schon
Beziehungen muss man nicht zweimal entdecken
Sobald Struktur und Konfiguration Teil der vom DataProcessing aufbereiteten Daten sind, hat der nächste Consumer eine deutlich bessere Ausgangslage.
Er erhält nicht mehr nur eine Sammlung einzelner Datensätze. Zusätzlich kann er Informationen darüber bekommen, welche Elemente zusammengehören, wie sie gruppiert sind und welche Struktur bereits um sie herum aufgebaut wurde.
Das kann weit über das fertige Fluid-Template hinaus nützlich sein.
Ein anderes Frontend, eine API-Schicht, ein Such- oder Indexierungsprozess oder eine individuelle Anwendung können jeweils eine andere Darstellung desselben Inhalts benötigen. Grid Elements macht aus diesen Consumern nicht von selbst fertige Integrationen, kann ihnen aber über den GridChildrenProcessor Daten liefern, in denen bereits bekannte Beziehungen erhalten sind.
Das wird zunehmend auch für die maschinelle Verarbeitung relevant. Eine Maschine kann nur mit den Informationen arbeiten, die sie tatsächlich erhält. Sind Beziehungen explizit, müssen sie nicht aus visueller Nähe, Namenskonventionen oder der zufälligen Reihenfolge von Datensätzen erraten werden. Struktur erklärt nicht automatisch die vollständige Bedeutung von Inhalten, kann aber wertvollen Kontext dazu liefern, wie ihre Bestandteile miteinander zusammenhängen.
Die entscheidende Arbeit wurde bereits früher geleistet, als Redakteure die Struktur geschaffen haben und das System sie gespeichert hat. Es gibt kaum Gründe, dieses Wissen wegzuwerfen, nur um den nächsten Consumer anschließend dieselben Zusammenhänge noch einmal erschließen zu lassen.
Macht was Gutes draus
Für Menschen gemacht, bereit für Maschinen
Lange Zeit bedeutete das Veröffentlichen von Inhalten im Web vor allem, sie für Menschen aufzubereiten, die irgendwann auf einer Seite landen würden. Suchmaschinen brachten ein weiteres Publikum ins Spiel, doch das Ziel blieb weitgehend dasselbe.
Eine Seite finden, sie besuchen und lesen, was dort steht. Dieser Weg wird zunehmend weniger vorhersehbar. Informationen können gesammelt, zusammengefasst oder miteinander kombiniert werden, bevor jemand die ursprüngliche Seite überhaupt zu Gesicht bekommt.
Suchassistenten, KI-Systeme und andere maschinelle Consumer können zu einer zusätzlichen Ebene zwischen dem Inhalt und der Person werden, die danach fragt. In dieser Situation ist es nur ein Teil der Aufgabe, eine Seite leicht auffindbar zu machen. Die dahinterliegenden Informationen müssen außerdem in einer Form vorliegen, mit der Maschinen arbeiten können. Das geht über klassische Suchmaschinenoptimierung hinaus.
Keywords, Metadaten und gut geschriebene Texte bleiben wichtig, können aber nicht jede Beziehung ausdrücken, die innerhalb des Contents existiert. Eine Maschine profitiert davon, wenn sie weiß, dass mehrere Datensätze eine Einheit bilden, etwas zu einem bestimmten Abschnitt gehört oder eine Konfiguration die Rolle einer Gruppe verändert. Je mehr davon explizit vorliegt, desto weniger muss aus der visuellen Darstellung rekonstruiert oder aus dem umgebenden Text erraten werden. Damit sind wir wieder beim Structure-first Authoring.
Redakteure erstellen Inhalte für Menschen und nutzen Strukturen, die ihnen helfen, Bedeutung und Kontext zu organisieren. Können diese Strukturen mit dem Inhalt weiterreisen, werden sie auch für Maschinen nützlich, einschließlich Consumern, die wir heute vielleicht noch gar nicht kennen. Die Zukunft von Content wird kaum von einem einzigen Ausgabekanal abhängen.
Was wir heute tun können, ist Inhalte von Anfang an so zu strukturieren, dass sie auch dann noch nutzbar bleiben, wenn später neue Ausgabekanäle dazukommen.
Grid Elements kann mehr weitergeben als nur einzelne Inhalte. Auch Struktur, Beziehungen, Layout-Informationen und Konfiguration können erhalten bleiben und passend für den nächsten Consumer aufbereitet werden. Das ist weit über die fertige Seite hinaus nützlich. APIs, Suche, individuelle Anwendungen und zunehmend auch KI-Systeme profitieren davon, wenn Zusammenhänge nicht immer wieder neu erschlossen werden müssen. Mit Structure-first Authoring schaffen Redakteure diesen Kontext von Anfang an, und Grid Elements hält ihn im DataProcessing auch für spätere Verarbeitungsschritte verfügbar. Für Menschen gemacht, bereit für Maschinen.
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