Configure Extbase plugins and modules 

To configure Extbase plugins and backend modules there are several things that need to be taken into account. Several distinct "surfaces" exist, each owned by a different role and each suited to a different kind of value. These include: the framework settings that tell Extbase where to find templates and records, the application settings you read in your own controllers and templates, the values an editor sets for each content element, and a few installation-wide behaviour switches.

This chapter explains each surface, what belongs in it, and how the surfaces are combined into the final configuration that your code sees.

The configuration "surfaces" of an Extbase extension 

TypoScript
The primary surface. Both the framework settings Extbase reads (template paths, storage pages, error handling) and your own application-specific settings are contained in plugin.tx_<extensionkey> for plugins and module.tx_<extensionkey> for backend modules. This is where most configuration work happens — see the configuration reference.
FlexForm
Content element configuration that an editor sets in the backend. A FlexForm field named settings.<name> is merged straight into $this->settings, meaning editors can override individual TypoScript settings in a single content element without having to touch any code. See Custom settings: the settings block for how it is merged into $this->settings.
Site settings
Installation- and site-wide values, defined by a site set and editable for each site in the backend. Site settings are the recommended way to ship configuration that can easily be modified by integrators without having to edit TypoScript; they are referenced from TypoScript through settings placeholders and so feed into the same plugin.tx_<extensionkey> tree.
Feature toggles
Some Extbase functionality can be switched on installation-wide rather than per plugin — for example consistent \DateTime handling and record-history tracking. This is not done by TypoScript; it is set in $GLOBALS['TYPO3_CONF_VARS']['SYS']['features'] . See Extbase feature toggles (not TypoScript).
Configuration/Extbase/Persistence/Classes.php
The class-mapping surface. A domain model maps to a table or columns that do not follow Extbase's naming conventions — for example reusing an existing table such as fe_users — this PHP file maps the class and its properties to the real names. It configures persistence rather than runtime behaviour, so it is covered by the domain model: see Table and field mapping.

How the surfaces combine 

The first three surfaces are merged in a fixed order before your controller runs, so the same setting can be declared in more than one place and the most specific value will take precedence. The lowest to the highest precedence is as follows:

  1. Extension-wide TypoScript ( plugin.tx_<extensionkey>), into which site settings feed through placeholders
  2. Plugin-specific TypoScript ( plugin.tx_<extensionkey>_<pluginname>)
  3. FlexForm values set by the editor in a content element

The full rules — including how to stop an empty FlexForm field from overriding a TypoScript default — are explained in Where Extbase TypoScript lives.

Feature toggles sit outside this chain: they change framework behaviour for the whole installation and are not part of the per-plugin merge.

Now we have looked at configuration surfaces, continue to the configuration reference to see how each block is used in practice. Then move on to Persistence layer in Extbase and View layer in Extbase, where these settings are converted into queries and rendered output.