Backend Previews With a System—Why We Built EXT:backendpreviews

David Steeb

09 February 2026

Anyone who regularly works with larger TYPO3 installations knows the situation: the website becomes more and more sophisticated, the number of custom content elements keeps growing—but in the backend—the editor interface—very little of that quality is actually visible.

Custom Content Types (CTypes) in particular often end up with very rudimentary or even practically empty previews in the page module. Apart from the headline, all that remains is a soup of gray boxes—from an editor’s perspective, this is the worst case.

Of course, there are also installations where custom preview templates already exist for individual content elements. That is generally an improvement. Without an overarching concept, however, this quickly leads to new problems: isolated templates, different rendering approaches, and over time an increasingly confusing mix of styles. Editorial work becomes harder, maintenance effort increases, and frustration grows as projects scale.

This is exactly where our extension backendpreviews comes into play. We now use it in all of our projects—and in this post, we want to explain why we built it, which problem it solves, and how it can be used.

Default backend preview showing just the element type title — The default page module preview for a custom content element can look like this, not presenting any helpful information for editors.

The Problem With Backend Previews in TYPO3

TYPO3 already provides a way to define custom backend previews for content elements:

mod.web_layout.tt_content.preview.my_custom_ctype = my_custom_element.html

With a single line of PageTSConfig, a custom Fluid template can be assigned to a content element. This is fundamentally useful—but it comes with a decisive limitation:

It works only per CType—one line of configuration for each custom CType
Each element comes with its own isolated template
Shared building blocks must be implemented repeatedly

In small projects, this is often still manageable. In larger installations with many custom CTypes—and developer teams changing over the course of several years—this approach simply does not scale.

What we regularly see in practice is gradual wild growth in the backend. Every new content element introduces its own preview logic. Without a shared foundation, many slightly different solutions emerge for essentially the same problems.

Typical symptoms include:

Many very similar Fluid templates
Repeated logic for images, links, link lists, or CTAs
Visual styles evolving inconsistently over time

Some concrete examples we encounter again and again:

Links rendered inconsistently: sometimes just as Link: <url>, sometimes including labels or descriptions
Preview images shown in different sizes or aspect ratios depending on the element or developer (e.g. 60 px height vs. 60 px width)
Crop variants respected in some previews but completely ignored in others

The result is an inconsistent backend preview experience that is neither easy to maintain nor particularly editor-friendly. The concepts of content blocks, where there is an isolated component for each new “CType” does not address this either.

Our Solution: Backend Previews

With EXT:backendpreviews, our goal was to solve exactly this structural problem.

The core idea is simple:

Instead of defining a single, self-contained template per CType, use the full Fluid toolset—with layouts, partials, and templates.

This allows to:

Define recurring building blocks centrally
Keep backend previews consistent across all content elements
Equip new content elements with meaningful previews very quickly

Rather than building a fully independent preview template for each element, previews are composed by including reusable partials.

Backend element preview with link/cta — Our extension helps unify the display of repeating element parts across multiple content element types, by using Fluid Partials for things like CTAs and links.

What EXT:backendpreviews Actually Solves

Using the extension, you can:

Render images in a consistent way (size, aspect ratio, crop variants)
Output links and link lists uniformly
Define recurring structures such as CTAs centrally
Visualize complex content elements clearly in the backend

In day-to-day project work, this has a noticeable impact:

Faster development—previews often consist of just a few partials
Consistent appearance—images, links, and lists follow the same rules
Better editor experience—content is immediately recognizable in the page module

Proven defaults out of the box—shipped partials that have proven themselves across many real-world projects

Screenshot of a backend element preview for a content type with multiple crop variants shown. — Making different crop variants used depending on the breakpoint visible for editors is extremely helpful, to make sure there's not that odd breakpoint where people's heads are chopped off...

Installation

Installation works as usual via Composer:

composer require b13/backendpreviews

No further steps in the Extension Manager are required.

Backend element preview showing headline with structure information — We often use a custom partial for headlines to show the headline hierarchy and the display size to the editors in the backend page module.

Configuration: Defining Backend Previews

Instead of configuring a fixed template path per CType, EXT:backendpreviews relies on a central view configuration. You define template, partial, and layout paths, including the standard Fluid fallback mechanism via root paths—once, regardless of the amount of used CTypes.

When rendering a preview, the extension automatically looks for a template whose file name matches the CType (for example my_custom_element.html) within the configured paths. If such a template is found, it is rendered—including layouts and partials.

If no matching template exists, EXT:backendpreviews gracefully falls back to other preview renderers or, ultimately, TYPO3’s default behavior.

Example configuration:

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/
}

Shipped defaults

EXT:backendpreviews ships with a set of sensible defaults:

Partials for images
Partials for links and link lists
Clean, compact backend renderings

These defaults can be used out of the box, overridden, or extended as needed.

Thanks to the modular structure, teams can easily establish their own default baseline—even across multiple projects or clients. This makes EXT:backendpreviews particularly useful for agencies and long-running TYPO3 installations.

Conclusion

Backend content previews are not a luxury—they are a core part of a good TYPO3 editor experience.

With EXT:backendpreviews, we built a solution that:

Extends TYPO3’s built-in capabilities in a sensible way
Improves maintainability and consistency
Requires minimal configuration while respecting existing setups
Integrates seamlessly into existing systems through well-defined fallbacks
Saves significant time in large projects

That’s why EXT:backendpreviews has become a fixed part of every project we build.

Documentation and source code are available on GitHub: https://github.com/b13/backendpreviews

Curious to learn more?

Especially in larger TYPO3 installations or agency-wide setups, a structured approach to backend previews pays off quickly.

If you need support introducing EXT:backendpreviews, defining your own defaults, or integrating it into an existing TYPO3 project, feel free to get in touch with us.

Get in touch

Written by:

b13 Founder and CEO, David, is someone you’ll meet if you’re thinking about working with our agency. He is constantly learning new skills and is an influential part of our cutting-edge frontend practice.

David Steeb CEO