---
title: "Feature: Extbase plugin rendering"
manual: "Frontend Theme for Extension Development"
version: "main"
source: "Changelog/2.0/Feature-ExtbasePluginRendering.rst"
modified: "2026-09-17T04:52:50+00:00"
---

# Feature: Extbase plugin rendering

## Description

A third-party Extbase plugin now renders on an installation using this
theme, whether it is registered as a dedicated **CType** (the way
`TYPO3CMSExtbaseUtilityExtensionUtility::configurePlugin()`
recommends, and the only registration TYPO3 v14 accepts) or, on TYPO3 v13.4
only, through the historical **General Plugin** / **list**
registration.

`configurePlugin()` generates `tt_content.<pluginSignature>
=< lib.contentElement` for every plugin, unconditionally, on both installed
core versions - even on v14, where nothing outside this theme defines
`lib.contentElement` at all, because `fluid_styled_content` is
not installed there. Before this change nothing rendered that object's
`templateName = Generic`, so every such plugin fell through to
TYPO3's own "no rendering definition" notice, indistinguishable to an editor
from a broken content element.

`Resources/Private/Templates/Generic.html` is the new template that
fixes that - shared by every plugin regardless of extension, because
`templateName = Generic` is a fixed string the core writes
itself, not something a plugin author controls. It reads back the
per-plugin `20` cObject the core places beside
`templateName` at a path built from the record being rendered
(`tt_content.{data.CType}.20`), rather than a fixed one, so the
one template serves every plugin without knowing which one it is. The plugin
is rendered with its content element, so the settings an editor chose in its
FlexForm reach it.

## **General Plugin** / `list`

TYPO3 v13.4 still offers the historical registration TCA
(`types.list` in `EXT:frontend`'s own
`Configuration/TCA/tt_content.php`), deprecated but present
(Deprecation [forge#105076](https://forge.typo3.org/issues/105076)). `fluid_styled_content` supplied the
`tt_content.list` object that rendered it, as a `CASE`
keyed on the plugin's **Type** (`list_type`) field, and removed it
outright in v14.0 together with the `list` **CType** itself
(Breaking [forge#105377](https://forge.typo3.org/issues/105377)). This theme now supplies that object too, in its
own house style, reusing the same `Generic.html` template - a
`list` record's own **CType** is `list`, so the same
`{data.CType}.20` path resolves to the `CASE` rather
than to a single plugin.

It is declared unconditionally rather than behind a version condition: on
v14 the `list_type` database column itself was dropped along with the
`CType`, so nothing can ever reach the branch - verified directly against
the installed v14.3.6 core, not only argued from the changelog. See
`docs/architecture/content-elements.md` in the developer documentation
for the full verification and the reasoning for leaving it unconditional.

## Both delivery paths

The rendering the core generates for a plugin is added to a site using site
sets unconditionally, but to a site configured through a `sys_template`
record only right after a static include that is registered as a content
rendering template - the role `fluid_styled_content` plays for the
installations that use it. The theme's static include is registered as one,
so a plugin renders there as well. Before, a site using the static include
rendered every other content element and showed the "no rendering
definition" notice for plugins alone.

## Impact

An Extbase plugin registered by a third-party extension - one this theme
does not control the TypoScript of - now renders instead of the core's "no
rendering definition" notice, on both TYPO3 v13.4 and v14.3, regardless of
whether it is registered as its own **CType** or, on v13.4, through
the historical **General Plugin** type.

`Tests/Functional/Fixtures/Extensions/plugin-fixture` is a fixture
extension that registers a plugin with **no** TypoScript rendering
definition of its own - unlike `Tests/Functional/Fixtures/Extensions/
example-fixture`, which deliberately overrides what `configurePlugin()`
generates - so the only thing that can make it render is this theme's own
`lib.contentElement` and `Generic.html`.