Registering an Extbase frontend plugin
A frontend plugin is an Extbase extension rendered as a content element on a
TYPO3 page. Registration requires two calls in two different files: one in
ext_localconf.php to configure the Extbase dispatcher, and one in
Configuration/TCA/Overrides/tt_content.php to make the plugin
selectable in the backend.
On this page
Configuring the plugin dispatcher
Extension registers which controller
actions are allowed and generates the TypoScript to route requests to the Extbase
dispatcher. Call it in ext_localconf.php:
use MyVendor\MyExtension\Controller\ConferenceController;
use TYPO3\CMS\Extbase\Utility\ExtensionUtility;
defined('TYPO3') or die();
ExtensionUtility::configurePlugin(
'MyExtension',
'ConferenceList',
[ConferenceController::class => 'list, show, create'],
[ConferenceController::class => 'create'],
);
The four arguments are:
- Extension name — the extension key in UpperCamelCase
(
my_extension→MyExtension). - Plugin name — a unique UpperCamelCase identifier for this plugin inside
the extension. Combined with the extension name, it forms the plugin
signature used in TypoScript and routing (
myextension_conferencelist). The combined length must not exceed 32 characters. snake_case is also accepted and normalised internally, but UpperCamelCase is the convention. - Allowed controller actions — an array mapping controller class names to a comma-separated list of action names. The first entry and its first action are the default. Only actions listed here are available via this plugin.
- Non-cacheable actions — a subset of the above defining output that must not be stored in the page cache. See Non-cacheable actions and developer responsibility for the implications.
Changed in version 14.0
The fifth parameter $pluginType was removed. All plugins are registered
as CType content elements. Omit this argument entirely.
Registering the plugin in the backend
Extension adds the plugin to the list of
available content element types in the backend. Call it in
Configuration/TCA/Overrides/tt_content.php:
use TYPO3\CMS\Extbase\Utility\ExtensionUtility;
defined('TYPO3') or die();
ExtensionUtility::registerPlugin(
'MyExtension',
'ConferenceList',
'my_extension.db:plugin.conferencelist.title',
'my-extension-conference-list',
'plugins',
'my_extension.db:plugin.conferencelist.description',
'EXT:my_extension/Configuration/FlexForms/ConferenceList.xml',
);
The arguments are:
- Extension name — same as in
configure.Plugin () - Plugin name — same as in
configure. The two values must match exactly.Plugin () - Plugin title — label shown in the backend content element wizard.
Use a translatable label reference. The example uses the
translation domain syntax
(
extension_key.file:label_key), which is shorter than the legacyLLL:EXT:path syntax. Both are equivalent and interchangeable. - Plugin icon — an icon identifier registered via the Icon
API, or a path prefixed with
EXT:. Optional. Defaults to the generic plugin icon. - Group — groups the plugin in the content element wizard. Common values
are
'plugins'(generic plugin group) or a custom group name matching your extension. - Description — optional longer text shown in the content element wizard.
- FlexForm — path to a FlexForm XML file that adds configurable fields to
the content element in the backend, for example
'EXT:my_extension/Configuration/FlexForms/ConferenceList.xml'. Optional. Omit if the plugin needs no backend configuration form.
Both calls must use the same extension name and plugin name. A mismatch means the dispatcher will not find the controller actions registered for that plugin.
How the plugin configuration is assembled
When an Extbase frontend plugin handles a request, the framework assembles a single configuration array from three layers, each able to override the previous:
plugin.— extension-wide defaults, applied to every plugin of this extension.tx_ myextension plugin.— plugin-specific values, override the extension-wide layer.tx_ myextension_ myplugin - FlexForm data — values the editor entered in the content element's plugin
tab. These have the highest priority and override both TypoScript layers.
Only
settings,persistence, andviewkeys are merged from the FlexForm.
The resulting array has three top-level keys that Extbase uses directly:
settings— arbitrary key/value pairs available as$this->settingsin the controller and as{settings}in Fluid templates (auto-assigned by the framework for frontend plugins).persistence— controls record loading; the most relevant sub-key isstorage, which limits which page(s) the repository queries.Pid view— overrides template file resolution viatemplate,Root Paths layout, andRoot Paths partial.Root Paths
TypoScript plugin object path
configure generates a TypoScript object for the plugin at:
plugin.tx_<extensionkey>_<pluginname>
Both parts are lowercase; underscores are removed from the extension key. For
the example above that is
plugin..
A full example covering all three configuration keys:
plugin.tx_myextension_conferencelist {
view {
templateRootPaths.10 = EXT:my_extension/Resources/Private/Templates/
}
persistence {
storagePid = {$plugin.tx_myextension_conferencelist.persistence.storagePid}
}
settings {
itemsPerPage = 10
}
}
To find the exact TypoScript path of a plugin, open the TYPO3 backend, navigate to a site or page containing the plugin, and inspect the computed TypoScript tree in Site Management > TypoScript.
See also
- Non-cacheable actions for the consequences of marking actions non-cacheable and developer responsibilities.
- View layer in Extbase for template path configuration via TypoScript.
- storagePid — when findAll() returns nothing for how the persistence storagePid setting limits which records are returned.