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

|David Steeb
Zwei stilisierte Webseiten-Designs mit einem Benutzerprofil, Platzhaltern für Bilder und Textabschnitten, vor einem hellblauen Hintergrund.

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.

Vorschau des Standard-Backends, die nur den Titel des Elementtyps anzeigt.
Die Default Page Modulvorschau für ein benutzerdefiniertes Inhaltselement kann so aussehen und bietet keine hilfreichen Infos für Redakteure.
Vorschau des Standard-Backends, die nur den Titel des Elementtyps anzeigt.
Die Default Page Modulvorschau für ein benutzerdefiniertes Inhaltselement kann so aussehen und bietet keine hilfreichen Infos für Redakteure.

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.

Backend-Vorschau für ein Element mit Link/CTA
Unsere Erweiterung hilft dabei, die Anzeige sich wiederholender Elementteile über mehrere Inhaltselementtypen hinweg zu vereinheitlichen, indem Fluid Partials für Dinge wie CTAs und Links verwendet werden.
Backend-Vorschau für ein Element mit Link/CTA
Unsere Erweiterung hilft dabei, die Anzeige sich wiederholender Elementteile über mehrere Inhaltselementtypen hinweg zu vereinheitlichen, indem Fluid Partials für Dinge wie CTAs und Links verwendet werden.

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

Screenshot einer Vorschau des Backend-Elements für einen Inhaltstyp mit mehreren Zuschneidevarianten.
Es ist äußerst hilfreich, verschiedene Bildausschnittvarianten, die je nach Breakpoint verwendet werden, für Redakteure sichtbar zu machen, um sicherzustellen, dass es keine ungünstigen Breakpoints gibt, bei denen den Personen die Köpfe abgeschnitten werden...
Screenshot einer Vorschau des Backend-Elements für einen Inhaltstyp mit mehreren Zuschneidevarianten.
Es ist äußerst hilfreich, verschiedene Bildausschnittvarianten, die je nach Breakpoint verwendet werden, für Redakteure sichtbar zu machen, um sicherzustellen, dass es keine ungünstigen Breakpoints gibt, bei denen den Personen die Köpfe abgeschnitten werden...

Installation

Die Installation erfolgt wie gewohnt per Composer:

1
composer require b13/backendpreviews

Weitere Schritte im Extension Manager sind nicht erforderlich.

Vorschau des Backend-Elements, das die Überschrift mit Strukturinformationen anzeigt.
Wir nehmen oft ein benutzerdefiniertes „Partial“ für Überschriften, um den Redakteuren die Hierarchie und die Anzeigegröße der Überschriften im Backend-Seitenmodul zu zeigen.
Vorschau des Backend-Elements, das die Überschrift mit Strukturinformationen anzeigt.
Wir nehmen oft ein benutzerdefiniertes „Partial“ für Überschriften, um den Redakteuren die Hierarchie und die Anzeigegröße der Überschriften im Backend-Seitenmodul zu zeigen.

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.