Deprecations and breaking changes to celebrate in TYPO3 v10

TYPO3 v10 implements many sweet new features and the whole CMS is getting better and better. But as with any big step forward, some things change or get left behind. This is necessary to keep future-oriented and not let old habits hold us back. So TYPO3 strives to keep improving by implementing well known and common standards. Deprecations and breaking changes are inconvenient but here are a few reasons why it’s definitely worth keeping up!

v10 stable from the beginning

TYPO3 v10 marks the first release that did not have any breaking changes between v10.0.0 and v10.4.0 (the LTS version), leaning towards a more semantic approach to versioning than before. And even 10.4.0 only had three breaking changes, which were accounted for by v10’s new Dashboard and an old utility class.

In general, breaking changes were allowed up to TYPO3 v10.0.0. Major changes related to Site Handling, and the removal of the legacy layer for handling URLs before Site Handling, and the exchange of the SwiftMailer API under the hood for the Symfony Mailer API. Other changes between v10.0.0 and v10.4 LTS concerned the implementation of new features while keeping existing functionality the same as before.

A great example of this is the extension felogin. To keep the old code running and add a possibility to rebuild the extension with Extbase, the developers used the feature flag mechanism. Providing a new module to migrate to the new solution, while having the old pi-based plugin still working.

Since TYPO3 v10 did not have breaking changes between v10.0.0 and v10.4.0, developers could start using TYPO3 v10 in late July 2019 safe in the knowledge that the APIs won’t change anymore. So they were able to implement new features on top of the TYPO3 API knowing they were completely compatible with TYPO3 v10.

3 breaking and 3 deprecation changes we love

Breaking: Extbase validators won’t be registered automatically anymore

Until TYPO3 v9, many extbase validators, such as domain models or types, were registered automatically. Now this has been removed and does not build an overhead of unnecessary and unused validators. If you need validators, now you have to set them in the phpDoc comments.

Breaking: #87957—Validators are not registered automatically in Extbase anymore
https://docs.typo3.org/c/typo3/cms-core/master/en-us/Changelog/10.0/Breaking-87957-DoNotMagicallyRegisterValidators.html

Breaking: Symfony Mime and Mailer instead of Swift Mailer

While implementing more and more well known and common standards into TYPO3, the Swift Mailer component was removed and replaced with the Symfony Mime and Mailer packages. Swift Mailer could be used in third party extensions or in your own code. To get your code running again, you have to switch to the new Symfony packages or use the core APIs for sending emails.

Breaking: #88643—Removed swiftmailer/swiftmailer dependency
https://docs.typo3.org/c/typo3/cms-core/master/en-us/Changelog/10.0/Breaking-88643-RemovedSwiftmailerswiftmailerDependency.html 

Breaking: Using string keys for log levels

This is a small change, but it shows how much dedication is put into our beloved CMS. For using the log API from TYPO3, the log levels are now represented by string keys and not as a number anymore. If you used the constants provided by the LogLevel class nothing has changed for you. If you used numbers, changing to the new strings solves the problem.

But why was this changed? With this breaking change, the code—or more specifically the config—for your log is more human-readable. This makes your work a little easier and TYPO3 is even more based on new standards.

Before

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

/**
 * Log levels according to RFC 3164
 */
class LogLevel
{
    /** Emergency: system is unusable ...*/
    const EMERGENCY = 0;

    /** Alert: action must be taken immediately ...*/
    const ALERT = 1;

    /** Critical: critical conditions ...*/
    const CRITICAL = 2;

    /** Error: error conditions ...*/
    const ERROR = 3;

    /** Warning: warning conditions ...*/
    const WARNING = 4;

    /** Notice: normal but significant condition ...*/
    const NOTICE = 5;

    /** Informational: informational messages ...*/
    const INFO = 6;

    /** Debug: debug-level messages ...*/
    const DEBUG = 7;
}

After

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

/**
 * Log levels according to RFC 3164
 */
class LogLevel extends \Psr\Log\Loglevel
{
    /** Reverse look up of log level to level name. ...*/
    protected static $levels = [
        self::EMERGENCY,
        self::ALERT,
        self::CRITICAL,
        self::ERROR,
        self::WARNING,
        self::NOTICE,
        self::INFO,
        self::DEBUG,
    ];
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

namespace Psr\Log;

/**
 * Describes log levels.
 */
class LogLevel
{
    const EMERGENCY = 'emergency';
    const ALERT = 'alert';
    const CRITICAL = 'critical';
    const ERROR = 'error';
    const WARNING = 'warning';
    const NOTICE = 'notice';
    const INFO = 'info';
    const DEBUG = 'debug';
}

Breaking: #88799—Introduced PSR-3 compatible Logging API
https://docs.typo3.org/c/typo3/cms-core/master/en-us/Changelog/10.0/Breaking-88799-IntroducedPSR-3CompatibleLoggingAPI.html

Deprecation: Long awaited multiple recipients for forms

Now you are able to send your form to a lot of people at the same time. Almost a million times we wished this feature would come. But with it, the old definition of recipients has been deprecated. To ensure your forms will work in the next major version, just change to the new definition with a “name-email address” pattern in the new recipient option. 

Deprecation: #80420—EmailFinisher single address options
https://docs.typo3.org/c/typo3/cms-core/master/en-us/Changelog/10.0/Deprecation-80420-EmailFinisherSingleAddressOptions.html

Deprecation: Register plugins and modules with fully qualified controller class names

With this deprecation, registering a plugin or a module has become more understandable and intuitive. To register a module, you previously had to prepend your extension name with the vendor. Instead of slashes there were dots, and the controller names were used without the proper class name. This can be very confusing especially for beginners.

So now there will be only your extension name and the fully qualified class name. Your IDE will like the fully qualified class names.

Before

Until now Extbase extensions registered a plugin like this:

1
2
3
4
5
6
7
8
9

\TYPO3\CMS\Extbase\Utility\ExtensionUtility::configurePlugin(
    'B13.Simplenews',
    'List',
    [
        'Main' => 'list,detail', // A list of all controllers and actions
    ],
    // No uncacheable plugin actions
    []
);

After

Extbase relied on “magic” to detect what the “Main” controller is, and what it was named. With version 10, the new syntax looks like this:

1
2
3
4
5
6
7
8
9

\TYPO3\CMS\Extbase\Utility\ExtensionUtility::configurePlugin(
    'Simplenews',
    'List',
    [
        \B13\Simplenews\Controller\MainController::class => 'list,detail', // A list of all controllers and actions
    ],
    // No uncacheable plugin actions
    []
);

This makes it more PHP-like (using the ::class syntax) and avoids errors in naming variables. Both variants are possible in TYPO3 v10.

Deprecation: #87550—Use controller classes when registering plugins/modules
https://docs.typo3.org/c/typo3/cms-core/master/en-us/Changelog/10.0/Deprecation-87550-UseControllerClassesWhenRegisteringPluginsmodules.html

Getting in touch with the new Services.yaml

To register new commands for your TYPO3 instance, the new Services.yaml file is now the place where everything happens. You can configure dependency injection and register your command in a single location. Isn’t that awesome? With both variants in use for supporting two major versions, no deprecation will be thrown, and both version 9 and v10 could be implemented. Bear in mind that, from version 11, the old method will be removed entirely so it’s worth updating your code now to make a later upgrade smoother, and avoid duplication down the road.

1
2
3
4
5
6
7
8
9
10
11

services:
  _defaults:
    autowire: true
    autoconfigure: true
    public: false

  B13\ExampleExt\Commands\AwesomeCommand
    tags:
    - name: 'console.command'
      command: 'b13:awesome-things-to-do'
      schedulable: false

Deprecation: #89139—Console Commands configuration format Commands.php
https://docs.typo3.org/c/typo3/cms-core/master/en-us/Changelog/10.3/Deprecation-89139-ConsoleCommandsConfigurationFormatCommandsPhp.html

Find out everything that’s changed

As you might expect, there’s a whole host of changes in TYPO3 v10. You can see the full list on the official website. But don’t get overwhelmed! You can scan your existing code for breaks and deprecations with the extension scanner in the TYPO3 backend Maintenance Area, or with the t3scanner CLI tool.