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: 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: 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.
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: 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.
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.
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.
Für einen umfassenden Überblick darüber, welche Arbeiten zur Aktualisierung Deiner Website erforderlich sind, wende Dich gerne für ein Upgrade-Angebot oder eine zweite Meinung an uns. Wir freuen uns darauf, deine Instanz auf die aktuellste TYPO3-Version zu bringen und Dir dabei zu helfen, alle Vorteile eines modernen CMS zu nutzen.
Michael ist unser netter Typ von Nebenan und unsere Geheimwaffe, die nahezu alle unsere Kundenprojekte kennt. Er hat ein beeindruckendes Skill Set, wie ein Schweizer Taschenmesser, seine wichtigste Fähigkeit ist es allerdings, sich immer wieder neue Fähigkeiten anzueigenen. Michi kann nicht ohne: Spotify.
Takeaways vom CMS Camp 2026 auf Mallorca: visuelle Erlebnisse, SEO und GEO, Arbeiten mit KI und inklusives Design. Dazu ein Blick darauf, was Redakteure von einem CMS brauchen und…
KI-Inhalte in TYPO3: Transparenz braucht Verantwortung
|Benni Mack
Der EU AI Act rückt die Herkunft KI-generierter Inhalte in den Fokus. AI Label kennzeichnet KI-generierte und KI-bearbeitete Inhalte in TYPO3 und dokumentiert, wer den…
Ein echter Geheimtipp in TYPO3: Die Backend User Section (Doktype 6)
|David Steeb
Entdecke den oft unterschätzten Doktype 6 (Backend User Section) in TYPO3 für sichere interne Vorschauen, Redaktionstrainings und Prototyping. Erfahre praxisnahe Anwendungsfälle,…