Site settings 

Site settings in Extbase Fluid plugins 

Site settings are not injected automatically into Extbase controllers or plugin settings. Pass them to the plugin through TypoScript or make the site object available in the controller.

To make the site settings available to all templates in your controller you can override method AbstractController::initializeView() and assign the site to the view:

<?php

declare(strict_types=1);

use Psr\Http\Message\ResponseInterface;
use TYPO3\CMS\Extbase\Mvc\Controller\ActionController;

class ExampleController extends ActionController
{
    public function initializeView(): void
    {
        $this->view->assignMultiple([
            'site' => $this->request->getAttribute('site'),
        ]);
    }

    public function indexAction(): ResponseInterface
    {
        // Variable '{site}' was assigned in initializeView().
        return $this->htmlResponse();
    }
}

You can then use the variable {site.settings} to access the site settings:

<f:debug>{site.settings.myExtension.categoryPid}</f:debug>

Pass a setting to TypoScript 

This example passes a page ID from a site setting to an Extbase plugin. The extension has already defined myExtension.categoryPid and the site has overridden it to 658 in Defining and overriding site settings.

After TYPO3 has resolved the setting, the identifier is available as the TypoScript constant {$myExtension.categoryPid} . It can be assigned to any scalar TypoScript property:

plugin.tx_myextension.settings.categoryPid = {$myExtension.categoryPid}

With the site override above, the parsed value of plugin.tx_myextension.settings.categoryPid is 658. If the site does not override it, the definition's default value 0 is used. A default in constants.typoscript with the same identifier does not win: every defined setting already supplies a value and overrides typoscript constants.

The same constant is available in page TSconfig. This makes one defined setting usable by both frontend rendering and backend form configuration:

// store tx_ext_data records on the given storage page by default (e.g. through IRRE)
TCAdefaults.tx_ext_data.pid = {$myExtension.categoryPid}

// load category selection for plugin from our dedicated storage page
TCEFORM.tt_content.pi_flexform.ext_pi1.sDEF.categories.PAGE_TSCONFIG_ID = {$myExtension.categoryPid}

Read a setting with the TypoScript data function 

In frontend TypoScript, a content object can read the setting directly from the current site instead of using constant substitution:

lib.categoryPid = TEXT
lib.categoryPid {
    data = siteSettings:myExtension.categoryPid
}

Use {$myExtension.categoryPid} when a value must be inserted into the TypoScript configuration while it is parsed, or when it is needed in page TSconfig. Use data = siteSettings:myExtension.categoryPid when a frontend content object supports the data function and should read from the current site at runtime. Both forms use the exact, case-sensitive setting identifier.

When a page is rendered with PAGEVIEW, the complete resolved TypoScript settings tree is available in Fluid as {settings} . Site settings therefore appear under their dotted path, for example {settings.myExtension.categoryPid} . This variable contains all TypoScript settings, however, not only Site Settings. A later value from the site's constants.typoscript or a sys_template record can differ from the value returned by $site->getSettings() .

Avoid common pitfalls 

Installed does not mean active

Installing the providing extension makes its set available, but the definition contributes to a site only when that site activates the set directly or through a dependency. If a constant is not substituted, first check the site's dependencies in config.yaml.

Constants are text substitutions

Site settings are validated and converted according to their definition, but a TypoScript constant is inserted as source text. The original PHP type does not survive constant substitution. In particular, a Boolean true becomes 1 and false becomes an empty value. Use the value in a context that applies the expected TypoScript type conversion.

Lists are not single constants

A setting of type stringlist is an array. TYPO3 exposes its scalar entries as flattened constants such as {$myExtension.allowedHosts.0} ; it does not create one usable {$myExtension.allowedHosts} value for the complete list. Read structured settings through the Site Settings API in PHP or Fluid instead of depending on numeric constant names.

Multiline values are not safe constant values

TYPO3 generates one constant assignment per scalar setting. A line break in a text value therefore becomes a line break in the generated TypoScript source. Read multiline content directly through the Site Settings API rather than substituting it as a constant.

Identifiers are exact

{$myextension.categoryPid} and {$myExtension.categoryPid} are different constants. Keep the vendor or extension prefix and casing consistent in the definition, all overrides and every consumer.

Dotted paths do not define their parents

A definition for myExtension.features.preview does not also define myExtension.features or myExtension. Each identifier that forms part of the public configuration API needs its own definition. Conversely, the map representation in settings.yaml allows separately defined foo.bar and foo.bar.baz to coexist.

Know which value wins 

Within a site TypoScript provider, TYPO3 loads set constants first, then adds the effective site settings as constants, followed by the site's own constants.typoscript. Constants from sys_template records are applied afterwards. A later value with the same identifier overrides an earlier one.