--- title: "Configure Extbase plugins and modules" manual: "TYPO3 Explained" version: "main" permalink: "https://docs.typo3.org/permalink/t3coreapi:extbase-configuration@main" source: "ExtensionArchitecture/Extbase/Configuration/Index.rst" rendered: "2026-09-24T12:36:55+00:00" --- # Configure Extbase plugins and modules {#extbase-configuration} 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 behavior 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 {#extbase-configuration-surfaces} - **[TypoScript](https://docs.typo3.org/permalink/t3coreapi:extbase-configuration-typoscript-scopes@main)** 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_` for plugins and `module.tx_` for [backend modules](https://docs.typo3.org/permalink/t3coreapi:extbase-registration-backend-module@main). This is where most configuration work happens — see the [configuration reference](https://docs.typo3.org/permalink/t3coreapi:extbase-configuration-reference@main). - **[FlexForm](https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/ApiOverview/FlexForms/Index.html#flexforms)** Content element configuration that an editor sets in the backend. A FlexForm field named `settings.` 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](https://docs.typo3.org/permalink/t3coreapi:extbase-configuration-typoscript-settings@main) for how it is merged into `$this->settings`. - **[Site settings](https://docs.typo3.org/permalink/t3coreapi:sitehandling-settings@main)** Installation- and site-wide values, defined by a [site set](https://docs.typo3.org/permalink/t3coreapi:site-sets@main) 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](https://docs.typo3.org/permalink/t3coreapi:sitehandling-settings-access-typoscript@main) and so feed into the same `plugin.tx_` tree. - **[Feature toggles](https://docs.typo3.org/permalink/t3coreapi:feature-toggles@main)** 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)](https://docs.typo3.org/permalink/t3coreapi:extbase-configuration-feature-toggles@main). - **`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 behavior, so it is covered by the domain model: see [Table and field mapping](https://docs.typo3.org/permalink/t3coreapi:extbase-domain-model-mapping@main). ## How the surfaces combine {#extbase-configuration-how-they-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_`), into which site settings feed through placeholders 1. Plugin-specific TypoScript (`plugin.tx__`) 1. 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](https://docs.typo3.org/permalink/t3coreapi:extbase-configuration-typoscript-scopes@main). Feature toggles sit outside this chain: they change framework behavior for the whole installation and are not part of the per-plugin merge. > [!TIP] > To inspect the *resolved* result, open the **Sites > TypoScript** > backend module and go to > the **Active TypoScript** submodule. Browse to > `plugin.tx_` to see the final, merged > configuration that your plugin actually receives — TypoScript and site-settings > placeholders included. FlexForm values, which are merged per content element > at request time, are not visible here. > [!NOTE] > **See also** > > - [Extbase configuration reference](https://docs.typo3.org/permalink/t3coreapi:extbase-configuration-reference@main) > — the reference guide for > all the configuration blocks that are used in Extbase extensions. > - [Site settings](https://docs.typo3.org/permalink/t3coreapi:sitehandling-settings@main) — > defining and reading site-wide configuration values. > - [Feature toggles](https://docs.typo3.org/permalink/t3coreapi:feature-toggles@main) > — how installation-wide behavior switches work. Now we have looked at configuration surfaces, continue to the [configuration reference](https://docs.typo3.org/permalink/t3coreapi:extbase-configuration-reference@main) to see how each block is used in practice. Then move on to [Persistence layer in Extbase](https://docs.typo3.org/permalink/t3coreapi:extbase-persistence-overview@main) and [View layer in Extbase](https://docs.typo3.org/permalink/t3coreapi:extbase-view-overview@main), where these settings are converted into queries and rendered output.