Backend module API (Extbase)

Adding new modules

Modules added by extensions are registered in the file ext_tables.php using the following API:

// Module System > Backend Users
\TYPO3\CMS\Extbase\Utility\ExtensionUtility::registerModule(
    'Beuser',
    'system',
    'tx_Beuser',
    'top',
    [
        \TYPO3\CMS\Beuser\Controller\BackendUserController::class => 'index, show, addToCompareList, removeFromCompareList, removeAllFromCompareList, compare, online, terminateBackendUserSession, initiatePasswordReset',
        \TYPO3\CMS\Beuser\Controller\BackendUserGroupController::class => 'index, addToCompareList, removeFromCompareList, removeAllFromCompareList, compare'
    ],
    [
        'access' => 'admin',
        'iconIdentifier' => 'module-beuser',
        'labels' => 'LLL:EXT:beuser/Resources/Private/Language/locallang_mod.xlf',
        'navigationComponentId' => 'TYPO3/CMS/Backend/PageTree/PageTreeElement',
        'inheritNavigationComponentFromMainModule' => false,
    ]
);

Here the module tx_Beuser is declared as a submodule of the already existing main module system.

Parameters:

1. The first argument contains the extension name (in UpperCamelCase) or the extension key (in lower_underscore). Since TYPO3 v10.0, you should no longer prepend the vendor name here, see Deprecation: #87550 - Use controller classes when registering plugins/modules.
2. Main module name, in which the new module will be placed, for example 'web' or 'system'.
3. Submodule key: This is an identifier for your new module.

4. Position of the module: Here, the module should be placed at the top of the main module, if possible. If several modules are declared at the same position, the last one wins. The following positions are possible:

   • top: the module is prepended to the top of the submodule list
   • bottom or empty string: the module is appended to the end of the submodule list
   • before:<submodulekey>: the module is inserted before the submodule identified by <submodulekey>
   • after:<submodulekey>: the module is inserted after the submodule identified by <submodulekey>
5. Allowed controller => action combinations. Since TYPO3 v10.0 you should use fully qualified class names here, see Deprecation: #87550 - Use controller classes when registering plugins/modules.

6. Module configuration: The following options are available:

   • access: can contain several, separated by comma

     • systemMaintainer: the module is accessible to system maintainers only.
     • admin: the module is accessible to admins only
     • user: the module can be made accessible per user
     • group: the module can be made accessible per usergroup
   • Module iconIdentifier
   • A language file containing labels like the module title and description, for building the module menu and for the display of information in the Help > About Modules module (found in the main help menu in the top bar). The LLL: prefix is mandatory here and is there for historical reasons.
   • Navigation component navigationComponentId - you can specify which navigation component you want to use, for example TYPO3/CMS/Backend/PageTree/PageTreeElement for a page tree or TYPO3/CMS/Backend/Tree/FileStorageTreeContainer for a folder tree. If you don't want to show a navigation component at all you can either set this to an empty string or not declare it at all. In case the main module (e.g. "web") has a navigationComponent defined by default you'll have to also set 'inheritNavigationComponentFromMainModule' => false.

Configuration with TypoScript

Backend modules can, like frontend plugins, be configured via TypoScript. While the frontend plugins are configured with plugin.tx_[pluginkey], for the configuration of the backend module.tx_[pluginkey] is used.

Example for configuring the paths of Fluid files:

module.tx_example {
    view {
        templateRootPaths {
            10 = EXT:example/Resources/Private/Backend/Templates/
        }
        layoutRootPaths {
           10 = EXT:example/Resources/Private/Backend/Layouts/
        }
    }
}