Example 

Search for content elements of type "Header":

Configuration module provider: Basic implementation 

To extend the configuration module, a custom configuration provider needs to be registered. Each "provider" is responsible for one configuration. The provider is registered as a so-called "configuration module provider" by tagging it in the Services.yaml file. The provider class must implement the EXT:lowlevel/Classes/ConfigurationModuleProvider/ProviderInterface.php (GitHub).

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 the methods as required by the interface. A full implementation would look like this:

<?php

declare(strict_types=1);

namespace MyVendor\MyExtension\Configuration\Processor\ConfigurationModule;

use TYPO3\CMS\Lowlevel\ConfigurationModuleProvider\ProviderInterface;

final class MyProvider implements ProviderInterface
{
    private 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
    {
        $myCustomConfiguration = [
            // the custom configuration
        ];

        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 :php$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 EXT:lowlevel/Classes/ConfigurationModuleProvider/AbstractProvider.php (GitHub) 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 localized label can be used.

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

Displaying custom values from $GLOBALS 

If you want to display a custom configuration from the $GLOBALS array, you can also use the already existing \TYPO3\CMS\Lowlevel\ConfigurationModuleProvider\GlobalVariableProvider . 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'

Disabling an entry 

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

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

Suggested order of clean up 

The suggested order below assumes that you are interested in running all these tests. Maybe you are not! So you should check the description of each one and if there is any of the tests you wish not to run, just leave it out.

It kind of gets simpler that way since the complexity mostly is when you wish to run all tests successively in which case there is an optimal order that ensures you don't have to run the tests all over again.

• [base command] cleanup:orphanrecords

  • As a beginning, get all orphaned records out of the system since you probably want to. Since orphan records may keep some missing relations from being detected it's a good idea to get them out immediately.

• [base command] cleanup:deletedrecords

  • Flush deleted records. As a rule of thumb, tools that create deleted records should be run before this one so the deleted records they create are also flushed (if you like to of course).

• [base command] cleanup:missingrelations

  • Remove missing relations at this point.
  • If you get an error like this: "TYPO3CMSCoreDatabaseReferenceIndex::setReferenceValue(): ERROR: No reference record with hash="132ddb399c0b15593f0d95a58159439f" was found!" just run the test again until no errors occur. The reason is that another fixed reference in the same record and field changed the reference index hash. Running the test again will find the new hash string which will then work for you.

• [base command] cleanup:flexforms

  • After the "deleted" tool since we cannot clean-up deleted records and to make sure nothing important is cleaned up.

Nightly reports of problems in the system 

If you wish to scan your TYPO3 installations for problems with a cronjob or so, a shell script that outputs a report could look like this:

#!/bin/sh
[typo3_site_directory]/typo3/sysext/core/bin/typo3 cleanup:orphanrecords -vv --dry-run
[typo3_site_directory]/typo3/sysext/core/bin/typo3 cleanup:deletedrecords -v --dry-run
[typo3_site_directory]/typo3/sysext/core/bin/typo3 cleanup:missingrelations --update-refindex -vv --dry-run
[typo3_site_directory]/typo3/sysext/core/bin/typo3 cleanup:flexforms -vv --dry-run

You may wish to change the verbosity level from -vv to -v as in the case above, depending on how important you consider the warnings.

The output can then be put into a logfile so the logging system can report errors.

You might also wish to disable tests like "deleted" which would report deleted records - something that might not warrant a warning, frankly speaking ...

Example script for checking your installation 

#!/bin/sh
./typo3/sysext/core/bin/typo3 cleanup:orphanrecords -vv --dry-run
./typo3/sysext/core/bin/typo3 cleanup:deletedrecords -v --dry-run
./typo3/sysext/core/bin/typo3 cleanup:missingrelations -vv --dry-run
./typo3/sysext/core/bin/typo3 cleanup:flexforms -vv --dry-run

Example script for cleaning your installation 

#!/bin/sh
./typo3/sysext/core/bin/typo3 cleanup:orphanrecords -vv
./typo3/sysext/core/bin/typo3 cleanup:deletedrecords -v
./typo3/sysext/core/bin/typo3 cleanup:missingrelations -vv --update-refindex
./typo3/sysext/core/bin/typo3 cleanup:flexforms -vv