Backend-Content-Previews mit System – warum wir EXT:backendpreviews entwickelt haben

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.


Das Problem mit Content-Previews im TYPO3-Backend
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:
- Die Konfiguration greift nur pro CType
- Jedes Element besitzt ein eigenständiges, isoliertes Template
- Wiederkehrende Bausteine müssen immer wieder neu umgesetzt werden
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:
- Viele sehr ähnliche Fluid-Templates
- Wiederholte Logik für Bilder, Links, Linklisten oder CTAs
- Inkonsistente Darstellungsstile über die Zeit hinweg
Einige konkrete Beispiele aus der Praxis:
- Links werden unterschiedlich dargestellt: mal nur als
Link: <url>, mal inklusive Linktitel oder Beschreibung - Vorschaubilder erscheinen je nach Element oder Entwickler in unterschiedlichen Größen oder Seitenverhältnissen
- CropVariants werden in manchen Previews berücksichtigt, in anderen vollständig ignoriert
Das 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.
Unsere Lösung: Backend Previews
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:
- Wiederkehrende Bausteine zentral definieren
- Content-Previews im Backend einheitlich darstellen
- Neue Inhaltselemente schnell und konsistent mit Previews ausstatten
Anstelle vollständig eigenständiger Preview-Templates werden Content-Previews aus wiederverwendbaren Partials zusammengesetzt.


Was EXT:backendpreviews konkret löst
Mit der Extension lassen sich unter anderem:
- Bilder einheitlich darstellen (Größe, Seitenverhältnis, CropVariants)
- Links und Linklisten konsistent ausgeben
- Wiederkehrende Strukturen wie CTAs zentral definieren
- Komplexe Inhaltselemente übersichtlich im Backend visualisieren
Im Projektalltag hat das spürbare Auswirkungen:
- Schnellere Entwicklung — neue Previews bestehen oft nur noch aus wenigen Partials
- Einheitliches Erscheinungsbild — Bilder, Links und Listen folgen denselben Regeln
- Bessere Handhabung für Redakteure — Inhalte sind im Seitenmodul sofort erkennbar
Bewährte Defaults sofort verfügbar— mitgelieferte Partials, die sich in zahlreichen realen Projekten bewährt haben


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


Konfiguration: Content-Previews definieren
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/
}
Mitgelieferte Defaults
EXT:backendpreviews bringt bereits eine Reihe sinnvoller Defaults mit:
- Partials für Bilder
- Partials für Links und Linklisten
- Kompakte, gut lesbare Standarddarstellungen für das Backend
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.
Fazit
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:
- TYPO3-Bordmittel sinnvoll erweitert
- Wartbarkeit und Konsistenz verbessert
- Mit minimaler Konfiguration auskommt und bestehende Anpassungen respektiert
- Sich nahtlos in bestehende Systeme integriert
- In großen Projekten nachhaltig Zeit spart
Deshalb ist EXT:backendpreviews für uns heute ein fester Bestandteil jedes TYPO3-Projekts.
Code und Dokumentation auf GitHub: https://github.com/b13/backendpreviews
Neugierig geworden?
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.