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.

Configuring the plugin dispatcher 

ExtensionUtility::configurePlugin() registers which controller actions are allowed and generates the TypoScript to route requests to the Extbase dispatcher. Call it in ext_localconf.php:

EXT:my_extension/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'],
);
Copied!

The four arguments are:

  1. Extension name — the extension key in UpperCamelCase (my_extensionMyExtension).
  2. 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.
  3. 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.
  4. 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 

ExtensionUtility::registerPlugin() adds the plugin to the list of available content element types in the backend. Call it in Configuration/TCA/Overrides/tt_content.php:

EXT:my_extension/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',
);
Copied!

The arguments are:

  1. Extension name — same as in configurePlugin().
  2. Plugin name — same as in configurePlugin(). The two values must match exactly.
  3. 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 legacy LLL:EXT: path syntax. Both are equivalent and interchangeable.
  4. Plugin icon — an icon identifier registered via the Icon API, or a path prefixed with EXT:. Optional. Defaults to the generic plugin icon.
  5. Group — groups the plugin in the content element wizard. Common values are 'plugins' (generic plugin group) or a custom group name matching your extension.
  6. Description — optional longer text shown in the content element wizard.
  7. 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:

  1. plugin.tx_myextension — extension-wide defaults, applied to every plugin of this extension.
  2. plugin.tx_myextension_myplugin — plugin-specific values, override the extension-wide layer.
  3. 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, and view keys 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->settings in 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 is storagePid, which limits which page(s) the repository queries.
  • view — overrides template file resolution via templateRootPaths, layoutRootPaths, and partialRootPaths.

TypoScript plugin object path 

configurePlugin() generates a TypoScript object for the plugin at:

plugin.tx_<extensionkey>_<pluginname>
Copied!

Both parts are lowercase; underscores are removed from the extension key. For the example above that is plugin.tx_myextension_conferencelist. A full example covering all three configuration keys:

EXT:my_extension/Configuration/Sets/MyExtension/setup.typoscript
plugin.tx_myextension_conferencelist {
    view {
        templateRootPaths.10 = EXT:my_extension/Resources/Private/Templates/
    }
    persistence {
        storagePid = {$plugin.tx_myextension_conferencelist.persistence.storagePid}
    }
    settings {
        itemsPerPage = 10
    }
}
Copied!

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.