Beim Aufbau einer Seite gibt es genug Dinge, die man im Kopf behalten sollte. Die Botschaft. Die Zielgruppe. Das richtige Bild. Den einen Satz, der noch immer nicht ganz sitzt. Ob genau dieses Element an genau dieser Stelle erlaubt ist, sollte vermutlich nicht dazugehören.
Genauso wenig die exakte Anzahl, die dort noch hineinpasst, welche Auswahl an anderer Stelle sinnvoll ist oder hinter welcher Dropzone etwas abgelehnt wird, nachdem man schon versucht hat, es dort abzulegen. Das sind hervorragende Probleme, um die sich Software kümmern sollte.
Und wenn ein System seine eigene Struktur gut genug kennt, kann es mit diesem Wissen etwas wirklich Nützliches anfangen. Nicht indem es mehr Anweisungen, mehr Optionen oder noch mehr Dinge hinzufügt, die man sich merken muss, sondern indem es die tägliche Arbeit selbstverständlicher macht.
Und genau da wird ein bisschen Zauberei überraschend nützlich.
Geschätzte Lesezeit: 5 Minuten
Grid Elements brachte keine völlig neue Vorstellung davon mit, wie Struktur in TYPO3 funktionieren kann. Ein Teil dieser Idee war längst im Core angekommen.
Der Grid Wizard gehört zu derselben Entwicklungslinie, die 2009 mit Grid View und Backend Layouts begann. Zeilen, Spalten und klar benannte Bereiche machten Seitenstruktur im Backend greifbar. Grid Elements führte genau diesen Gedanken später auf der Ebene einzelner Content-Elemente weiter.
Auch der New Content Element Wizard war längst da. Er ist in TYPO3 der vertraute Weg, neue Inhalte anzulegen. Grid Elements ersetzt ihn nicht, sondern nutzt das Wissen der umgebenden Struktur, damit er an jeder Stelle nur das anbietet, was dort tatsächlich sinnvoll ist.
Und dann kam der dritte Zauberer ins Spiel. Der Drag-In Wizard ist die eigentliche Ergänzung von Grid Elements. Er bringt die passenden Möglichkeiten direkt dorthin, wo Redakteure gerade arbeiten.
Einer gibt die Struktur vor. Einer hilft bei der Auswahl. Einer bringt die passenden Elemente direkt an ihren Platz. Aus drei einzelnen Wizards wird so ein gemeinsamer Authoring-Workflow.
Beim Grid Wizard beginnt die Struktur. Ein Layout kann mehrere Zeilen, unterschiedlich viele Spalten, über mehrere Zellen reichende Bereiche und die gesamte Geometrie beschreiben, die nötig ist, damit diese Struktur im Backend sichtbar wird. Das funktioniert auf Seitenebene wie gewohnt und mit Grid Elements zusätzlich genauso innerhalb einzelner Content-Elemente.
Doch Geometrie ist nur der sichtbare Teil. Ein Bereich kann auch wissen, was dort überhaupt hingehört.
Er kann bestimmte Content-Typen erlauben, andere ausschließen und festlegen, wie viele Elemente dort sinnvoll sind. Aus einer Spalte wird damit mehr als nur ein leeres Rechteck. Ein Bereich kann bereits einen Teil seiner Funktion tragen, bevor überhaupt Content hineinkommt. Derselbe Gedanke findet sich auch bei den Backend Layouts auf Seitenebene wieder.
TYPO3 14 unterstützt allowed und disallowed Content Types für Backend-Layout-Spalten inzwischen direkt im Core. Das ist ein willkommener Schritt in dieselbe Richtung. Grid Elements verbindet solche Regeln schon sehr viel länger mit seinem umfassenderen Strukturmodell, einschließlich Begrenzungen wie maxitems.
Für Redakteure ist der entscheidende Punkt viel einfacher. Die Struktur merkt sich, was wohin gehört. Ein zuverlässiger Authoring-Workflow sollte nicht davon abhängen, dass jeder Mensch, der damit arbeitet, all diese Regeln im Kopf behält.
Sobald ein Bereich weiß, was dort sinnvoll ist, wirkt es ziemlich absurd, darin trotzdem jedes denkbare Content-Element anzubieten. Stell dir vor, du öffnest den New Content Element Wizard für einen klar definierten Bereich, in den genau eine bestimmte Art von Teaser gehört.
Dann bringt es wenig, sich erst an Plugins, Formularen, Tabellen und allem anderen vorbeizuscrollen, was die Installation sonst noch zu bieten hat. Das System weiß längst genug, um die Auswahl sinnvoll einzugrenzen.
Grid Elements nutzt die Restrictions des jeweiligen Zielbereichs, um genau das zu tun. Öffnest du den New Content Element Wizard an einer anderen Stelle, kann die Auswahl ganz anders aussehen, weil dort ein anderer Kontext gilt. Das klingt zunächst nach einem kleinen Detail. Im redaktionellen Alltag macht es aber einen erstaunlich großen Unterschied und kann Redakteure spürbar schneller machen.
Statt sich merken zu müssen, welche zwanzig Optionen man ignorieren kann, konzentriert sich der Redakteur einfach auf die wenigen, die an dieser Stelle sinnvoll sind. Neue Kollegen brauchen dafür nicht erst dieselbe Sammlung ungeschriebener Regeln wie jemand, der seit fünf Jahren am Projekt arbeitet. Und was an anderer Stelle genau richtig ist, muss hier nicht unnötig die Auswahl überladen.
Mehr Wissen im System bedeutet weniger unnötige Entscheidungen für den Menschen davor. Ein ziemlich guter Tausch.
Der New Content Element Wizard weiß bereits, welche Elemente hier angelegt werden dürfen. Der Drag-In Wizard setzt genau dort an und holt diese Auswahl direkt in den Arbeitsbereich.
Öffnest du ihn im Page Module, berücksichtigt er die Strukturen, die auf der aktuellen Seite tatsächlich zur Verfügung stehen. Hat ein Element nirgendwo einen sinnvollen Platz, taucht es gar nicht erst auf. Gibt es mindestens ein gültiges Ziel, steht es zur Auswahl.
Und dann wird es richtig praktisch. Sobald du ein Element ziehst, reagiert die Struktur. Zonen, in denen es landen darf, werden zu gültigen Zielen. Wo es nicht hingehört, gibt es auch nichts zum Ablegen. Und wenn eine Zelle ihr Limit erreicht hat, ist die Gästeliste eben voll.
Auswahl und Platzierung greifen damit direkt ineinander. Der Drag-In Wizard baut dabei nicht heimlich neue Strukturen. Unter der Haube läuft auch kein automatischer Grid-Generator. Er arbeitet mit dem, was bereits vorhanden ist, und nutzt dessen Regeln, um den nächsten Schritt möglichst einfach zu machen.
Der Unterschied ist klein, aber entscheidend. Der Redakteur bestimmt weiterhin, was aus der Seite wird. Das System sorgt nur dafür, dass auf Anhieb sichtbar ist, wo etwas sinnvoll hinpasst.
Structure-first Authoring bleibt damit keine abstrakte Idee mehr. Man kann es einfach mit der Maus in die Tat umsetzen.
Am Anfang steht das Erlebnis des Nutzers. Von dort aus arbeitet man sich zurück zur Technik.
In der Softwarewelt gibt es diese eigentümliche Vorstellung, Einfachheit ließe sich daran messen, wie wenig ein System kann. Bei Code oder beim Umfang eines Pakets mag das noch eine brauchbare Größe sein. Für jemanden, der den ganzen Tag mit dem Ergebnis arbeiten muss, ist sie deutlich weniger hilfreich.
Redakteure erleben weder die Zahl interner Klassen noch Listener oder Features. Sie erleben Entscheidungen. Welches Element brauche ich? Darf es hierhin? Ist dieser Bereich schon voll?
Kann das in diese Struktur? Warum wurde das Element, das ich gerade dort ablegen wollte, abgewiesen?
Jede dieser Fragen, die das System selbst beantworten kann, unterbricht die eigentliche Arbeit ein Stück weniger. Genau hier werden „Keep it simple“ und „Don’t make me think“ interessant. „Einfach“ sollte sich darauf beziehen, wie sich die Arbeit im Backend anfühlt. Die Technik darunter muss deshalb noch lange nicht simpel sein.
Manchmal ist mehr Leistungsfähigkeit unter der Haube genau das, was die Oberfläche ruhiger macht. „Mächtig“ muss deshalb nicht „kompliziert“ heißen, auch nicht für Power-User. Grid Elements kann Zeilen, Spalten, Verschachtelungen, Restrictions, Berechtigungen, Kontext und gültige Ziele kennen. Ein Redakteur muss die Mechanik dahinter nicht verstehen, um davon zu profitieren.
Diese Stärke zeigt sich genau dann, wenn daraus weniger irrelevante Optionen, klarere Ziele und weniger vermeidbare Fehler entstehen. Entwickler sind allerdings nicht die einzigen Gäste auf dieser Party. Ein Backend ist für Menschen da, die Content erstellen und verwalten. Wenn zusätzliche Logik ihnen hilft, sicherer und mit weniger Reibung zu arbeiten, hat diese Komplexität ihren Platz verdient.
Inzwischen haben die drei Zauberer etwas deutlich Wichtigeres getan, als nur ein paar Klicks zu sparen. Der Grid Wizard gibt der Struktur eine sichtbare Form und klare Regeln. Der New Content Element Wizard nutzt diese Regeln, um die Auswahl sinnvoll einzugrenzen. Der Drag-In Wizard bringt sie direkt in den Arbeitsbereich und lässt die Struktur schon beim Platzieren zeigen, was wohin gehört.
All das nimmt Redakteuren keine Freiheit. Es nimmt ihnen Dinge ab, die sie ohnehin nicht im Kopf behalten sollten.
Über die Botschaft muss weiterhin jemand nachdenken. Über die Zielgruppe auch. Das richtige Bild ist noch immer wichtig, und dieser eine Satz kann sich weitere zehn Minuten weigern, endlich zu sitzen. Das sind menschliche Probleme, für die sich Zeit lohnt. Sich zu merken, ob ein bestimmtes Content-Element in einer bestimmten Spalte erlaubt ist, darf das System dagegen gerne selbst übernehmen. So sieht Built for Humans in der Praxis aus.
Ein mächtiges, modernes Authoring-System muss nicht seine gesamte Leistungsfähigkeit auf einmal zeigen. Es kann diese Stärke nutzen, um die richtigen Möglichkeiten leichter auffindbar zu machen, falsche Entscheidungen zu vermeiden und komplexe Strukturen überraschend angenehm bedienbar zu machen. Und sobald die Struktur genug weiß, um den Menschen beim Aufbau einer Seite zu unterstützen, wird eine andere Frage interessant.
Was passiert mit all diesem Wissen über die Struktur, nachdem das Backend seine Arbeit getan hat? Layout, Kind-Elemente und Beziehungen haben für den Redakteur bereits eine Bedeutung. Wie viel davon kann mit dem Content weiterreisen, wenn jemand anderes oder etwas anderes zum Konsumenten wird?
Hier verlassen unsere drei Zauberer die Bühne. Vorerst.
Grid Elements bringt drei Wizards zu einem Structure-first-Authoring-Workflow zusammen. Der Grid Wizard definiert Struktur und Regeln. Der New Content Element Wizard grenzt die Auswahl ein. Der Drag-In Wizard bringt gültige Optionen und Ziele direkt in den Arbeitsbereich. Das Ergebnis ist eine mächtige Software, die ihrerseits Redakteuren weniger abverlangt. Die Struktur merkt sich, was wohin gehört, damit Menschen sich auf den eigentlichen Inhalt konzentrieren können. Das ist Built for Humans. Und als Nächstes schauen wir uns an, was passiert, wenn diese Struktur das Backend verlässt.
© Copyright 2026 Cybercraft GmbH