Feature: #92929 - Extendable configuration module

See Issue #92929

Description

Since a long time, the configuration module in EXT:lowlevel was the first stop for integrators when it came to validation of the global configuration. The module displays all relevant global variables such as TYPO3_CONF_VARS, TCA and many more, in a tree format which is easy to browse through. Over time this module got extended to also display the configuration of newly introduced features like the middleware stack or the event listeners.

To make this module even more powerful, a dedicated API was introduced which allows extension authors to extend the module so they can expose their own configurations.

By the nature of the new API it is even possible to not just add new configuration but to also disable existing, if not needed in the specific installation.

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

Impact

It is now possible to extend the configuration module for custom configurations and to manage the available options for the module by disabling any provider shipped by core or another third-party extension.