
T3ppy gibt TYPO3 ein freundliches Gesicht
TYPO3 ist leistungsstark — muss sich aber nicht unpersönlich anfühlen. Das ist T3ppy, unser freundlicher Begleiter fürs Backend.
weiterlesen: T3ppy gibt TYPO3 ein freundliches Gesicht
Wer regelmäßig mit größeren TYPO3-Installationen arbeitet, kennt die Situation: Die Webseite wird immer ausgefeilter, die Anzahl individueller Content-Elemente wächst stetig — im Backend, also in der Redakteurs-Oberfläche — ist davon jedoch oft nur wenig sichtbar.
Gerade bei individuellen Content Typen sind die Content-Previews im Seitenmodul häufig sehr rudimentär oder nahezu leer. Abgesehen von der Überschrift bleibt oft nur ein Mix an grauen Boxen zurück — aus Redakteurssicht ist das der Worst Case.
Natürlich gibt es auch Installationen, in denen für einzelne Inhaltselemente bereits eigene Preview-Templates existieren. Das ist grundsätzlich ein Schritt nach vorn. Ohne ein übergreifendes Konzept führt dies jedoch schnell zu neuen Problemen: isolierte Templates, unterschiedliche Darstellungslogiken und mit der Zeit ein unübersichtliches Nebeneinander verschiedener Stile. Redaktionelle Arbeit wird dadurch schwieriger, der Wartungsaufwand steigt und die Komplexität wächst mit jedem Projektjahr.
Genau hier setzt unsere Extension EXT:backendpreviews an. Wir setzen sie inzwischen in all unseren Projekten ein — und möchten hier erklären, warum wir sie entwickelt haben, welches Problem sie löst und wie sie eingesetzt wird.

TYPO3 bietet von Haus aus die Möglichkeit, eigene Content-Previews für Inhaltselemente zu definieren:
1
mod.web_layout.tt_content.preview.my_custom_ctype = my_custom_element.html
Über eine einzelne Zeile PageTSConfig kann einem Inhaltselement ein eigenes Fluid-Template zugewiesen werden. Das ist grundsätzlich sinnvoll — bringt jedoch eine entscheidende Einschränkung mit sich:
In kleinen Projekten ist das oft noch gut beherrschbar. In größeren Installationen mit vielen Custom-CTypes — und über Jahre wechselnden Entwicklerteams — skaliert dieser Ansatz jedoch nicht.
Was wir in der Praxis regelmäßig beobachten, ist ein schleichender Wildwuchs im Backend. Jedes neue Inhaltselement bringt seine eigene Preview-Logik mit. Ohne gemeinsame Basis entstehen viele leicht unterschiedliche Lösungen für eigentlich identische Probleme.
Typische Symptome sind:
Einige konkrete Beispiele aus der Praxis:
Link: <url>, mal inklusive Linktitel oder BeschreibungDas Ergebnis sind inkonsistente Content-Previews im Backend, die weder gut wartbar noch besonders redakteursfreundlich sind. Das Konzept der „Content-Blocks“, bei dem es für jeden neuen „CType“ eine eigene Komponente gibt, löst das Problem auch nicht.
Mit EXT:backendpreviews wollten wir genau dieses strukturelle Problem lösen.
Die Kernidee ist einfach:
Statt für jeden CType ein einzelnes, in sich geschlossenes Template zu definieren, nutzen wir das volle Fluid-Programm — mit Layouts, Partials und Templates.
So lassen sich:
Anstelle vollständig eigenständiger Preview-Templates werden Content-Previews aus wiederverwendbaren Partials zusammengesetzt.

Mit der Extension lassen sich unter anderem:
Im Projektalltag hat das spürbare Auswirkungen:
Bewährte Defaults sofort verfügbar— mitgelieferte Partials, die sich in zahlreichen realen Projekten bewährt haben

Die Installation erfolgt wie gewohnt per Composer:
1
composer require b13/backendpreviews
Weitere Schritte im Extension Manager sind nicht erforderlich.

Statt pro CType einen festen Template-Pfad zu konfigurieren, setzt EXT:backendpreviews auf eine zentrale Konfiguration. Definiert werden Template-, Partial- und Layout-Pfade, inklusive der bekannten Fluid-Fallback-Mechanik über RootPaths — einmalig, egal wie viele CTypes betroffen sind.
Beim Rendern eines Content-Previews sucht die Extension automatisch nach einem Template, dessen Dateiname dem CType entspricht (z. B. my_custom_element.html). Wird ein solches Template gefunden, wird es inklusive Layouts und Partials gerendert.
Wird kein passendes Template gefunden, greift EXT:backendpreviews sauber auf andere Preview-Renderer bzw. auf den TYPO3-Default zurück.
Beispielkonfiguration:
1
2
3
4
5
6
7
8
9
10
plugin.tx_backendpreviews.view {
templateRootPaths.10 = EXT:backendpreviews/Resources/Private/Templates/
templateRootPaths.20 = EXT:sitepackage/Resources/Private/BackendPreviews/Templates/
partialRootPaths.10 = EXT:backendpreviews/Resources/Private/Partials/
partialRootPaths.20 = EXT:sitepackage/Resources/Private/BackendPreviews/Partials/
layoutRootPaths.10 = EXT:backendpreviews/Resources/Private/Layouts/
layoutRootPaths.20 = EXT:sitepackage/Resources/Private/BackendPreviews/Layouts/
}
EXT:backendpreviews bringt bereits eine Reihe sinnvoller Defaults mit:
Diese Defaults können direkt verwendet, überschrieben oder erweitert werden.
Dank des modularen Aufbaus lassen sich außerdem eigene Partials, Layouts und Templates als projekt- oder agenturweite Default-Basis etablieren. So entsteht ein konsistentes Backend-Erscheinungsbild — auch über mehrere Projekte hinweg.
Content-Previews im Backend sind kein Luxus, sondern ein zentraler Bestandteil einer guten TYPO3-Redakteurserfahrung.
Mit EXT:backendpreviews haben wir eine Lösung geschaffen, die:
Deshalb ist EXT:backendpreviews für uns heute ein fester Bestandteil jedes TYPO3-Projekts.
Code und Dokumentation auf GitHub: https://github.com/b13/backendpreviews
Gerade in größeren TYPO3-Installationen oder agenturweiten Setups zahlt sich ein strukturierter Ansatz für Content-Previews im Backend schnell aus.
Wenn ihr Unterstützung bei der Einführung von EXT:backendpreviews, bei der Definition eigener Defaults oder bei der Integration in bestehende TYPO3-Projekte benötigt, sprecht uns gerne an.