Backend Previews With a System—Why We Built EXT:backendpreviews
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.
The Problem With Backend Previews in TYPO3
TYPO3 already provides a way to define custom backend previews for content elements:
1
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.
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
Installation
Installation works as usual via Composer:
1
composer require b13/backendpreviews
No further steps in the Extension Manager are required.
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:
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/
}
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.