Feature: #92929 - Extendable configuration module

So, how does it work?

Each "provider", responsible for one configuration, is registered as a so-called "configuration module provider". This is done in the corresponding Services.yaml file of each extension. Each provider is tagged and will then automatically be registered. Therefore, the provider class must implement the ProviderInterface which requires some methods to be present in the provider class so they can be called from within the module.

The registration of such a provider looks like the following:

myextension.configuration.module.provider.myconfiguration:
  class: 'Vendor\Extension\ConfigurationModuleProvider\MyProvider'
  tags:
    - name: 'lowlevel.configuration.module.provider'
      identifier: 'myProvider'
      before: 'beUserTsConfig'
      after: 'pagesTypes'

A new service with a freely selectable name is defined by specifying the provider class to be used. Further, the new service must be tagged with the lowlevel.configuration.module.provider tag. Arbitrary attributes can be added to this tag. However, some are reserved and required for internal processing. For example, the identifier attribute is mandatory and must be unique. Using the before and after attributes, it is possible to specify the exact position on which the configuration will be displayed in the module menu.

The provider class has to implement some methods, required by the interface. A full implementation would look like this:

<?php

use TYPO3\CMS\Lowlevel\ConfigurationModuleProvider\ProviderInterface;

class MyProvider implements ProviderInterface
{
   protected string $identifier;

   public function __invoke(array $attributes): self
   {
      $this->identifier = $attributes['identifier'];
      return $this;
   }

   public function getIdentifier(): string
   {
      return $this->identifier;
   }

   public function getLabel(): string
   {
      return 'My custom configuration';
   }

   public function getConfiguration(): array
   {
      return $myCustomConfiguration;
   }
}

The __invoke() method is called from the provider registry and provides all attributes, defined in the Services.yaml. This can be used to set and initialize class properties like the $identifier which can then be returned by the required method getIdentifier(). The getLabel() method is called by the configuration module when creating the module menu. And finally, the getConfiguration() method has to return the configuration as an array to be displayed in the module.

There is also the abstract class \TYPO3\CMS\Lowlevel\ConfigurationModuleProvider\AbstractProvider in place which already implements the required methods except getConfiguration. Please note, when extending this class, the attribute label is expected in the __invoke() method and must therefore be defined in the Services.yaml. Either a static text or a locallang label can be used.

Since the registration uses the Symfony service container and provides all attributes using __invoke(), it is even possible to use DI with constructor arguments in the provider classes.

If you just want to display a custom configuration from the $GLOBALS array, you can also use the already existing \TYPO3\CMS\Lowlevel\ConfigurationModuleProvider\GlobalVariableProvider . Simply define the key to be exposed using the globalVariableKey attribute.

This could look like this:

myextension.configuration.module.provider.myconfiguration:
  class: 'TYPO3\CMS\Lowlevel\ConfigurationModuleProvider\GlobalVariableProvider'
  tags:
    - name: 'lowlevel.configuration.module.provider'
      identifier: 'myConfiguration'
      label: 'My global var'
      globalVariableKey: 'MY_GLOBAL_VAR'

To disable an already registered configuration simply add the disabled: true attribute. For example, if you intend to disable the TCA_DESCR key you can use:

lowlevel.configuration.module.provider.tcadescr:
  class: TYPO3\CMS\Lowlevel\ConfigurationModuleProvider\GlobalVariableProvider
  tags:
    - name: 'lowlevel.configuration.module.provider'
      disabled: true