module
The backend module of an extension can be configured via TypoScript.
The configuration is done in
module..
_<lowercasepluginname> can be omitted then the setting is used
for all backend modules of that extension.
Even though we are in the backend context here we use TypoScript setup. The settings should be done globally and not changed on a per-page basis. Therefore they are usually done in the file EXT:my_extension/ext_typoscript_setup.typoscript.
Note
All Core extensions, and in general all extensions that switched to the simplified backend templating no longer use the frontend TypoScript based override approach. This has been superseded by a general override strategy based on TSconfig: templates.
Options for simple backend modules
Warning
It is strongly recommended not to use TypoScript in custom backend modules, for example
module.. Use custom
Page TSconfig in namespace tx_*
instead.
The configuring backend modules via frontend TypoScript is flawed by design: It on one hand forces backend modules to parse the full frontend TypoScript, which is a general performance penalty in the backend - the backend then scales with the amount of frontend TypoScript. Also, the implementation is based on the Extbase ConfigurationManager, which leads to the situation that casual non-Extbase backend modules have an indirect dependency to lots of Extbase code.
In simple backend modules extension authors can decide how to use this
namespace. By convention settings should go in the subsection
settings.
module.tx_myextension_somemodule {
settings {
enablesomething = 1
}
}Options for Extbase backend modules
Most configuration options that can be done for Extbase frontend plugins can also be done for Extbase backend modules:
view.templateRootPaths
view.templateRootPaths.[array]
-
- Type
- file path with stdWrap
Note
All Core extensions, and in general all extensions that switch to the simplified backend templating no longer use the frontend TypoScript based override approach. This has been superseded by a general override strategy based on TSconfig: templates.
Used to define several paths for templates, which are executed in reverse order (the paths are searched from bottom to top). The first folder where the desired layout is found is immediately used. If the array keys are numeric, they are first sorted and then executed in reverse order.
Example: Set the template root paths
module.tx_somebackend_module {
view {
templateRootPaths {
100 = EXT:my_extension/Resources/Private/Templates/Backend
}
}
}view.partialRootPaths
view.partialRootPaths.[array]
-
- Type
- file path with stdWrap
Note
All Core extensions, and in general all extensions that switch to the simplified backend templating no longer use the frontend TypoScript based override approach. This has been superseded by a general override strategy based on TSconfig: templates.
Used to define several paths for partials, which will be executed in reverse order. The first folder where the desired partial is found, is used. The keys of the array define the order.
Example: Set the partial root paths
module.tx_somebackend_module {
view {
partialRootPaths {
100 = EXT:my_extension/Resources/Private/Partials/Backend
}
}
}settings
settings
-
- Type
- array<string, mixed>
Here resides all of the settings. These settings are
available in the controller of the backend module as the array variable
$this->settings.
Example: Limit pagination in the backend
Show 25 news records in the backend module of the news extension:
module.tx_news {
settings.list.paginate.itemsPerPage = 25
}Example: Register YAML file
Register your TYPO3 Form configuration for the backend via TypoScript.
module.tx_form {
settings {
yamlConfigurations {
# Use the current timestamp as key to avoid accidental overwriting
1712163960 = EXT:my_extension/Configuration/Form/CustomFormSetup.yaml
}
}
}