Die besten Deprecations und Breaking Changes in TYPO3 v10

TYPO3 v10 implementiert viele tolle neue Funktionen und das ganze CMS wird immer besser und besser. Aber wie bei jedem großen Schritt vorwärts, ändern sich manche Dinge oder man trennt sich sogar ganz von ihnen. Das ist notwendig, um zukunftsorientiert zu bleiben und sich nicht von alten Gewohnheiten aufhalten zu lassen. Deshalb ist TYPO3 viel daran gelegen, sich durch die Implementierung bekannter und verbreiteter Standards ständig zu verbessern. Deprecations und Breaking Changes sind oft unangenehm, aber hier sind ein paar Gründe, warum es sich auf jeden Fall lohnt, dranzubleiben!

TYPO3 v10 — von Anfang an stabil

TYPO3 v10 ist die erste Version, die keine Breaking Changes zwischen v10.0.0 und v10.4.0 (der LTS-Version) enthielt, und sich damit mehr an einem semantischeren Ansatz bei der Versionierung hält als bisher. Und selbst 10.4.0 hatte nur drei Breaking Changes, die auf das neue Dashboard von v10 und eine alte Utility-Klasse zurückzuführen waren.

Im Allgemeinen waren Breaking Changes bis TYPO3 v10.0.0 erlaubt. Größere Änderungen betrafen das Site-Handling und die Entfernung des Legacy-Layers für die Behandlung von URLs vor dem Site-Handling sowie den Austausch der SwiftMailer-API unter der Haube gegen die Symfony Mailer-API. Weitere Änderungen zwischen v10.0.0 und v10.4 LTS betrafen die Implementierung neuer Funktionen, während die bestehende Funktionalität unverändert blieb.

Ein großartiges Beispiel dafür ist die Extension felogin. Um den alten Code am Laufen zu halten und eine Möglichkeit hinzuzufügen, die Erweiterung mit Extbase neu zu erstellen, benutzten die Entwickler den Feature-Flag-Mechanismus. Sie stellten ein neues Modul zur Verfügung, um auf die neue Lösung zu migrieren, während das alte pi-basierte Plugin weiterhin funktioniert.

Da es in TYPO3 v10 keine Breaking Changes zwischen v10.0.0 und v10.4.0 gab, konnten die Entwickler Ende Juli 2019 mit dem Einsatz von TYPO3 v10 beginnen, in der Gewissheit, dass sich die APIs nicht mehr ändern werden. So konnten neue Funktionen zusätzlich zur TYPO3 API implementiert werden, in dem Wissen, dass sie vollständig kompatibel mit TYPO3 v10 sein werden.

3 Breaking und 3 Deprecation Changes die wir lieben

Breaking: Extbase-Validatoren werden nicht mehr automatisch registriert

Bis TYPO3 v9 wurden viele Extbase-Validatoren, wie z.B. Domain-Model oder Types, automatisch registriert. Jetzt wurde dies entfernt, was einen Overhead von unnötigen und unbenutzten Validatoren vermeidet. Wenn Du Validatoren benötigst, müssen diese jetzt in den phpDoc-Kommentaren gesetzt werden.

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 und Mailer anstelle von Swift Mailer

Im Zuge der Implementierung von immer mehr allgemein bekannten und gebräuchlichen Standards in TYPO3 wurde die Komponente Swift Mailer entfernt und durch die Symfony Mime und Mailer Packages ersetzt. Swift Mailer konnte in Extensions von Drittanbietern oder in Deinem eigenen Code verwendet werden. Um Deinen Code wieder zum Laufen zu bringen, musst Du auf die neuen Symfony Packages umsteigen oder die Core-APIs zum Versenden von E-Mails verwenden.

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: Verwendung von String Keys für Log Levels

Das ist eine relativ kleine Änderung, aber sie zeigt, wie viel Herzblut in unser geliebtes CMS gesteckt wird. Bei der Verwendung der Log-API von TYPO3 werden die Log-Level jetzt durch Text Keys und nicht mehr als Zahlen dargestellt. Wenn Du die von der LogLevel-Klasse bereitgestellten Konstanten verwendet hast, hat sich für Dich nichts geändert. Wenn Du Zahlen verwendet hast, löst die Umstellung auf die neuen Strings das Problem.

Aber warum wurde dies geändert? Durch diesen Breaking Change ist der Code — oder genauer gesagt die Konfiguration — für Dein Log besser lesbar. Das macht die Arbeit ein wenig einfacher und dadurch lehnt sich TYPO3 noch mehr an neue Standards an.

Vorher

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;
}

Nachher

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: Lang ersehnte Mehrfach-Empfänger für Formulare

Jetzt bist Du in der Lage, Dein Formular an mehrere Personen gleichzeitig zu versenden. Ungefähr eine Million Mal haben wir uns gewünscht, dass dieses Feature kommen würde. Damit ist nun allerdings die alte Definition für Empfänger überholt. Um sicherzustellen, dass Deine Formulare in der nächsten Hauptversion funktionieren, wechsle einfach zu der neuen Definition mit einem „name-email address“-Pattern in der neuen Empfängeroption.

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: Registriere Plugins und Module mit vollständig qualifizierten Controller-Klassennamen

Mit dieser Deprecation ist das Registrieren eines Plugins oder eines Moduls verständlicher und intuitiver geworden. Um ein Modul zu registrieren, musste man früher dem Vendor seinen Extensionnamen voranstellen. Anstelle von Schrägstrichen gab es Punkte, und die Controller-Namen wurden ohne den richtigen Klassennamen verwendet. Dies kann besonders für Anfänger sehr verwirrend sein.

Jetzt gibt es also nur noch den Extensionnamen und den voll qualifizierten Klassennamen. Eure IDE wird sich über die voll qualifizierten Klassennamen freuen.

Vorher

Bis jetzt haben Extbase-Extensions ein Plugin so registriert:

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
    []
);

Nachher

Extbase hat bisher eher mit „Magie“ versucht herauszufinden, was der „Main“-Controller ist und wie er genannt wurde. Mit Version 10 sieht die neue Syntax so aus:

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
    []
);

Das macht es PHP-ähnlicher (Verwendung der ::class-Syntax) und vermeidet Fehler bei der Benennung von Variablen. Beide Varianten sind in TYPO3 v10 möglich.

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

Mach dich mit der neuen Services.yaml vertraut

Um neue Befehle für Ihre TYPO3-Instanz zu registrieren, ist die neue Services.yaml jetzt der Ort, an dem alles passiert. Du kannst Dependency Injection konfigurieren und deinen Command an einem einzigen Ort registrieren. Ist das nicht fantastisch? Da beide Varianten zur Unterstützung von zwei Hauptversionen verwendet werden, gibt es keine Deprecation, und sowohl Version 9 als auch v10 könnten implementiert werden. Beachte, dass ab Version 11 die alte Methode vollständig entfernt wird — es lohnt sich also, deinen Code jetzt zu aktualisieren, damit ein späteres Upgrade reibungsloser von statten geht und späterer Extraaufwand vermieden wird.

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

Finde heraus, was sich alles geändert hat

Wie Du vielleicht bereits vermutest, gibt es eine ganze Reihe von Änderungen in TYPO3 v10. Die vollständige Liste findest Du auf der offiziellen Website. Aber lass Dich nicht überwältigen! Du kannst deinen bestehenden Code mit dem Extension-Scanner im TYPO3-Backend-Maintenance-Modul oder mit dem t3scanner CLI-Tool nach Breaking und Deprecation Changes durchsuchen.