TYPO3 v13 meistern: Der Leitfaden für Upgrades und Migrationen

Published on :  
Wolfgang Weber
Development

TYPO3 v13 meistern: Der Leitfaden für Upgrades und Migrationen

TYPO3 v13 ist ein großer Schritt nach vorn. Es entfernt veraltete APIs, verschärft die Core-Architektur und führt strengere Standards ein, die sich direkt auf benutzerdefinierten Code und Extensions auswirken.

Dieser Leitfaden konzentriert sich auf das Wesentliche während eines Upgrades: Bruchveränderungen, die behoben werden müssen, wichtige Änderungen, die das Verhalten verändern können, und Veraltungen, die vor TYPO3 v14 beachtet werden müssen. Nutze ihn als praktische Referenz, um deine TYPO3 v13 Migration mit weniger Überraschungen zu planen, umzusetzen und zu stabilisieren.

TYPO3 v13: Der unverzichtbare Upgrade-Leitfaden

Für wen dieser Leitfaden geeignet ist und für wen nicht

Dieser Leitfaden richtet sich an Teams, die ein ernsthaftes Upgrade auf TYPO3 v13 planen. Der Fokus liegt auf echter Migrationsarbeit und langfristiger Wartung, nicht auf Feature-Marketing.

Dieser Leitfaden ist für

  • TYPO3-Agenturen, die mehrere Kundenprojekte und LTS-Upgrades betreuen
  • Freiberufliche TYPO3 Entwickler, die individuelle Extensions und Site-Packages pflegen
  • Inhouse TYPO3-Teams, die langlebige, geschäftskritische Websites betreiben
  • Technische Leiter und CTOs, die Upgrade-Umfang, Risiken und Zeitpläne planen

Dieser Leitfaden ist nicht für

  • Einsteiger, die neu bei TYPO3 sind
  • Marketing oder reine Content-Rollen
  • Projekte, die nahe am TYPO3 Core laufen und keinen eigenen Code oder Extensions enthalten

Was Sie gewinnen werden

  • Klarheit darüber, welche Breaking Changes sofortiges Handeln erfordern
  • Orientierung dazu, was ohne Upgrade-Risiko verschoben werden kann
  • Eine praxisnahe Einschätzung zur Vorbereitung von TYPO3 v13-Projekten auf v14

Upgrade-Realität in TYPO3 v13

TYPO3 Upgrades sind nicht nur technische Aufgaben. Sie sind Planungsprozesse, die von langen Lebenszyklen, Extension-Abhängigkeiten und begrenzten Upgrade-Zeitfenstern geprägt sind.

Lange LTS-Zyklen prägen jede Entscheidung

TYPO3-Projekte laufen häufig 3–6 Jahre auf einer LTS-Version.

Das bedeutet:

  • Alte Entscheidungen bleiben länger produktiv im Einsatz
  • Technische Schulden wachsen unbemerkt
  • Upgrade-Fehler sind kostspielig rückgängig zu machen

v13-Upgrades sollten als strukturelle Neustarts behandelt werden, nicht als schnelle Versionssprünge.

Extension-zentrierte Abhängigkeitsrealität

Die meisten TYPO3 Installationen hängen stärker von Extensions als vom Core ab.

In der Praxis:

  • Core-Upgrades hängen von der Bereitschaft der Extensions ab
  • Individuelle Extensions stellen das größte Risiko dar
  • TER-Extensions unterscheiden sich stark in ihrer Wartungsqualität

Extensions sollten immer geprüft werden, bevor individueller Code angepasst wird.

Was zuerst behoben werden sollte (Blockierende Probleme)

Diese Punkte müssen vor oder während des Upgrades behoben werden:

  • Wichtige Änderungen, die PHP-Fehler oder fatale Exceptions verursachen
  • Entfernte Hooks, die durch PSR-14-Events ersetzt wurden
  • Inkompatibilitäten mit QueryBuilder, Doctrine und Symfony
  • Veraltete APIs, deren Entfernung in v14 geplant ist

Diese Punkte führen zu einem Ausfall der Website, nicht nur zu Warnmeldungen im Log.

Was warten kann (Aufräumen nach dem Upgrade)

Diese Aufgaben können nach der Stabilisierung eingeplant werden:

  • Veraltete, aber noch funktionsfähige APIs
  • Internes Refactoring für eine sauberere Architektur
  • Performance-Optimierungen ohne direkten Bezug zu v13-Änderungen

Das Verschieben dieser Aufgaben ist akzeptabel, sollte jedoch dokumentiert und nachverfolgt werden.

Diese Denkweise sorgt dafür, dass TYPO3 v13 Upgrades planbar und kontrolliert bleiben und sich an langfristiger Wartung orientieren – nicht nur an der Einhaltung einer Versionsanforderung.

Praktische Upgrade-Anleitung für TYPO3 v13 Projekte

Dieser Abschnitt konzentriert sich auf Aktion, die in realen TYPO3-Projekten tatsächlich Upgrade-Zeit und Risiko reduzieren. Er spiegelt Muster wider, die sich in Agenturprojekten, langlaufenden Websites und bei der Wartung von Extensions zeigen.

Empfohlener Upgrade-Pfad

  • Zuerst auf die neueste TYPO3 v12 LTS-Version aktualisieren.
  • Alle Deprecations und Extension-Warnungen in v12 beheben.
  • Erst danach auf v13 wechseln und die Core-Upgrade-Wizards verwenden.
  • Das Überspringen von Major-Versionen bei aktiven Projekten sollte vermieden werden.

Dieser zweistufige Weg fängt die meisten Breaking Changes frühzeitig ab und hält ein Rollback einfach.

Pre-Upgrade-Checks (Zuerst durchführen)

  • Prüfen, ob alle Extensions v13-kompatibel sind oder aktiv gewartet werden
  • Nicht verwendete oder aufgegebene TER-Extensions entfernen
  • TYPO3 Deprecation-Logs ausführen und Warnungen in v12 beheben
  • Individuellen Code prüfen auf:
    • Hook-Nutzung (stdWrap, TSFE, IconFactory)
    • Nutzung von QueryBuilder und Doctrine

    • Backend-JavaScript-Modulimporte

Das Überspringen dieser Prüfungen ist die häufigste Ursache für fehlgeschlagene Upgrades.

Upgrade-Sequenz, die tatsächlich funktioniert

  1. PHP und Systemanforderungen aktualisieren
  2. TYPO3-Core über Composer aktualisieren
  3. Alle Installations-Tool-Assistenten ausführen
  4. Caches leeren und Backend-Zugriff erneut prüfen
  5. Fatale Fehler beheben, bevor das Frontend angepasst wird

Frontend-Probleme sollten erst analysiert werden, wenn das Backend stabil läuft.

Validierung nach dem Upgrade

  • Backend-Formulare, RTE und individuelle Module testen
  • Login, Berechtigungen und Workspaces überprüfen
  • CLI-Befehle und Scheduler-Tasks prüfen
  • Logs auf verbleibende Deprecations oder Notices kontrollieren

Die meisten versteckten Probleme treten in Backend-Workflows auf, nicht auf Seiten im Frontend.

Häufige Fehler von TYPO3-Teams

  • Deprecations als optionales Aufräumen behandeln
  • Legacy-Hooks beibehalten, statt auf PSR-14 umzusteigen
  • Laufzeit-Fixes mit Composer-Updates vermischen
  • Strict-Typing-Probleme erst in der Produktion sichtbar werden lassen

Diese Punkte erhöhen die langfristigen Wartungskosten, nicht nur den Upgrade-Aufwand.

Perspektive von Extension-Autoren (Was jetzt wichtig ist)

TYPO3 v13 setzt eine klarere Architektur durch:

  • PSR-14-Veranstaltungen ersetzen die meisten Legacy-Hooks
  • Strenge Typisierung ist in Extbase nicht mehr optional
  • Composer-Disziplin ist entscheidend für stabile Abhängigkeiten

Extensions, die diese Regeln einhalten, lassen sich sauber upgraden. Andere werden schnell zu technischer Schuld.

TYPO3 v13 vs TYPO3 v14 - Übersicht zur Upgrade-Bereitschaft

Diese Tabelle hilft Teams zu verstehen, welche Änderungen jetzt verpflichtend sind und welche künftig zu Blockern werden. Sie eignet sich ideal für KI-Snippets und Featured Answers.

BereichTYPO3 v13 StatusTYPO3 v14 AuswirkungWas Teams tun sollten
Legacy HooksEntferntNicht verfügbarVollständig auf PSR-14-Events migrieren
QueryBuilder APIsGeändertStabilJetzt aktualisieren; v14 unterstützt keine Legacy-Aufrufe mehr
Extbase TypingErzwungenStrengerType Hints und Methodensignaturen korrigieren
$GLOBALS['TSFE']VeraltetEntferntContext API oder Request-Attribute verwenden
Fluid renderStatic()VeraltetEntferntViewHelpers refaktorisieren
Plugin via list_typeVeraltetEntferntEigenen CType pro Plugin verwenden
CKEditor-Konfigurations-FallbacksEntferntStabilExplizite YAML-Arrays verwenden
Backend-JS-Legacy-ModuleVeraltetEntferntAuf moderne ES-Module umstellen
PageTS via APIVeraltetEntferntIn Konfigurationsdateien auslagern
Datetime-INT-FelderGeändertStabilVerwendung von BIGINT sicherstellen

Kernaussage:
Ein TYPO3 v13-Upgrade, das Deprecations ignoriert, ist nur zur Hälfte abgeschlossen. Wer sie jetzt behebt, reduziert den Aufwand für v14 deutlich.

TYPO3 v13 Upgrade-Änderungen, risikobasierte Übersicht

TYPO3 v13 bringt erhebliche interne Änderungen mit sich. Nicht alle erfordern die gleiche Dringlichkeit. Um eine realistische Upgrade-Planung zu unterstützen, sind die folgenden Änderungen nach tatsächlichem Projektrisiko gruppiert, nicht nach Changelog-Kategorie.

Dies hilft Teams zu entscheiden:

  • Was vor dem Upgrade behoben werden muss
  • Was nach dem Upgrade getestet werden sollte
  • Was später als Aufräumarbeit für v14 erledigt werden kann

Änderungen mit hohem Risiko (Müssen vor oder während des Upgrades behoben werden)

Diese Änderungen führen zu Funktionsausfällen oder fatalen Fehlern, wenn sie nicht berücksichtigt werden.

QueryBuilder- und Database-API-Änderungen

ExpressionBuilder-Änderungen

Die Methodensignaturen wurden geändert:

  • ExpressionBuilder::literal() erfordert nun zwingend einen String
  • ExpressionBuilder::trim() benötigt jetzt das TrimMode-Enum

Vor v13

$queryBuilder->expr()->comparison(
    $queryBuilder->expr()->trim($fieldName, 1),
    ExpressionBuilder::EQ,
    $queryBuilder->createNamedParameter('', Connection::PARAM_STR)
);

Nach v13

use Doctrine\DBAL\Platforms\TrimMode;

$queryBuilder->expr()->comparison(
    $queryBuilder->expr()->trim($fieldName, TrimMode::LEADING),
    ExpressionBuilder::EQ,
    $queryBuilder->createNamedParameter('', Connection::PARAM_STR)
);
Änderungen an der QueryBuilder-API

Entfernte Methoden umfassen:

add()
getQueryPart(), getQueryParts()
resetQueryPart(), resetQueryParts()
execute()
setMaxResults(0)

Erforderliche Änderungen

  • Verwenden Sie executeQuery() für SELECT.
  • Verwenden Sie executeStatement() für INSERT / UPDATE / DELETE.
  • Verwenden Sie null anstelle von 0 für unbegrenzte Ergebnisse.

Vor v13

$queryBuilder->add('select', ['uid', 'title']);
$result = $queryBuilder->execute();
$queryBuilder->setMaxResults(0);

Nach v13

$queryBuilder->select('uid', 'title');
$result = $queryBuilder->executeQuery();
$queryBuilder->setMaxResults(null);

Authentifizierung und Kontextzugriff

LoginType in native Enumeration umgewandelt

\TYPO3\CMS\Core\Authentication\LoginType ist jetzt eine PHP-Enumeration.
Alte Konstanten wurden entfernt.

Vor v13

if ($loginType === \TYPO3\CMS\Core\Authentication\LoginType::LOGIN) {
    // ...
}

Nach v13

use TYPO3\CMS\Core\Authentication\LoginType;

if (LoginType::tryFrom($value ?? '') === LoginType::LOGIN) {
    // login
}

$TSFE->fe_user entfernt

Der direkte Zugriff auf Frontend-Benutzerdaten über $TSFE ist nicht mehr möglich.

Vor v13

$username = $GLOBALS['TSFE']->fe_user->user['username'];

Nach v13 (Kontext-API)

// After v13
This method is gone.
Use getFirstPageNumber(), getLastPageNumber(), or create your own iteration logic.

Nach v13 (Anforderungsattribut)

$frontendUser = $this->request->getAttribute('frontend.user');
$username = $frontendUser->user['username'] ?? '';

Entfernte Hooks (PSR-14 erforderlich)

Die folgenden Hooks wurden vollständig entfernt und führen zu Fehlern, wenn sie weiterhin referenziert werden:

  • stdWrap Hook
  • getData Hook
  • postInit Hook
  • Icon Overlay Override Hook

Erforderliche Aktion

  • Entfernen Sie die Hook-Registrierungen
  • Ersetzen Sie diese durch die entsprechenden PSR-14-Events

Änderung des Backend-Layout-Providers

PageTsBackendLayoutDataProvider als endgültig markiert

\TYPO3\CMS\Backend\View\BackendLayout\PageTsBackendLayoutDataProvider kann nicht mehr erweitert werden.

Vor v13

class MyProvider extends PageTsBackendLayoutDataProvider {
}

Nach v13

class MyProvider implements BackendLayoutDataProviderInterface {
}

Änderungen mit mittlerem Risiko (Verhaltensänderungen nach dem Upgrade)

Diese Änderungen führen möglicherweise nicht zum Absturz des Systems, verändern jedoch das Verhalten, die Ausgabe oder die Editor-Erfahrung.

Änderung der CKEditor-Konfiguration

removePlugins Fallback entfernt

Die stringbasierte Konfiguration wird nicht mehr unterstützt.

Vor v13

editor:
  config:
    removePlugins: image

Nach v13

editor:
  config:
    removePlugins:
      - image

Änderungen bei der Indexed Search

Indexed Search als Content-Element deklariert

EXT:indexed_search ist jetzt ein CType statt eines Plugins.

Maßnahme

  • Führen Sie den Upgrade-Wizard aus:
    „Migrate Indexed Search plugins to content elements“

Änderungen bei der Pagination

getAllPageNumbers() entfernt

Diese Methode existiert nicht mehr.

Maßnahme

  • Verwenden Sie getFirstPageNumber()
  • Verwenden Sie getLastPageNumber()
  • Oder implementieren Sie benutzerdefinierte Iterationslogik

Änderungen im Verhalten der Utility-Funktionen

Kontinuierliche Array-Schlüssel in intExplode()

Wenn removeEmptyEntries = true, sind die Schlüssel jetzt fortlaufend.

Vorher

[0 => 1, 2 => 3]

Nach

[0 => 1, 1 => 3]

Editor und Assistentenverhalten

Neuer Inhaltselement-Assistent, abgeleitet von TCA

show := removeFromList() funktioniert nicht mehr.

Erforderliche Änderung

removeItems := addToList(html)

SEO & Link-Validierung

Validierung externer Links standardmäßig deaktiviert

EXT:linkvalidator überprüft externe Links nur noch, wenn diese Funktion aktiviert ist.

Aktion

mod.linkvalidator.linktypes = db,file,external

Standardmäßige Twitter Card geändert

Der Standardwert wurde von summary auf summary_large_image geändert.

Änderungen mit geringem Risiko (Aufräumarbeiten und v14-Vorbereitung)

Diese Änderungen blockieren TYPO3 v13 nicht, sollten jedoch behoben werden, um den zukünftigen Upgrade-Aufwand zu reduzieren.

Datenbank & Schema

BIGINT für Datetime-Felder

Datetime TCA-Felder verwenden jetzt BIGINT, um das Jahr-2038-Problem zu vermeiden.

Vorher

crdate INT(11) DEFAULT '0'

Nach

crdate BIGINT(20) DEFAULT '0'

Abhängigkeits-Updates

  • Symfony auf Version 7 aktualisiert
  • Doctrine DBAL auf Version 4 aktualisiert

Diese Änderungen sind größtenteils durch die oben genannten QueryBuilder-Fixes abgedeckt.

Entfernte Legacy-Strukturen

  • Unbenutzte tt_content-Felder entfernt
  • cache_treelist-Tabelle entfernt

Dies betrifft nur Projekte, die noch auf diese Strukturen zugreifen.

Anpassung der Indexed Search

Die Manipulation von endgültigen Suchabfragen in EXT:indexed_search hat sich geändert. Dies ist nur relevant, wenn benutzerdefinierte Logik existiert.

Anwendung in der Praxis

  • Beheben Sie Änderungen mit hohem Risiko vor dem Upgrade
  • Testen Sie Änderungen mit mittlerem Risiko während der QA
  • Planen Sie Änderungen mit geringem Risiko als Aufräumarbeiten

Dies vermeidet unnötige Arbeiten und hält TYPO3 Upgrades planbar und kontrolliert.

Deprecations (Vorbereitung auf TYPO3 v14)

Die folgenden APIs und Muster sind in TYPO3 v13 noch verfügbar, werden jedoch in TYPO3 v14 entfernt. Sie blockieren ein sofortiges Upgrade, aber das unbehandelte Verlassen dieser Änderungen wird den zukünftigen Upgrade-Aufwand erhöhen.

Empfehlung:

Beheben Sie diese während der v13-Upgrade-Arbeiten, wo immer möglich, insbesondere in Extensions, die Sie aktiv warten.

1. ExtensionManagementUtility::addPageTSConfig()

Diese Methode ist veraltet und wird in v14 entfernt.

Was zu tun ist:
Verschieben Sie die Page TS-Konfiguration in eine dedizierte Konfiguration/page.tsconfig-Datei.

2. DuplicationBehavior-Klasse

Die Legacy-Klasse ist veraltet.

Vorher:

$behavior = \TYPO3\CMS\Core\Resource\DuplicationBehavior::RENAME;

Nach:

$behavior = \TYPO3\CMS\Core\Resource\Enum\DuplicationBehavior::RENAME;

3. AbstractFile::FILETYPE_* Konstanten

Alle AbstractFile::FILETYPE_* Konstanten sind veraltet.

Vorher:

\TYPO3\CMS\Core\Resource\AbstractFile::FILETYPE_UNKNOWN
\TYPO3\CMS\Core\Resource\AbstractFile::FILETYPE_TEXT
\TYPO3\CMS\Core\Resource\AbstractFile::FILETYPE_IMAGE
\TYPO3\CMS\Core\Resource\AbstractFile::FILETYPE_AUDIO
\TYPO3\CMS\Core\Resource\AbstractFile::FILETYPE_VIDEO
\TYPO3\CMS\Core\Resource\AbstractFile::FILETYPE_APPLICATION

Nach:

\TYPO3\CMS\Core\Resource\AbstractFile::FILETYPE_UNKNOWN -> \TYPO3\CMS\Core\Resource\FileType::UNKNOWN->value

\TYPO3\CMS\Core\Resource\AbstractFile::FILETYPE_TEXT -> \TYPO3\CMS\Core\Resource\FileType::TEXT->value

\TYPO3\CMS\Core\Resource\AbstractFile::FILETYPE_IMAGE -> \TYPO3\CMS\Core\Resource\FileType::IMAGE->value

\TYPO3\CMS\Core\Resource\AbstractFile::FILETYPE_AUDIO -> \TYPO3\CMS\Core\Resource\FileType::AUDIO->value

\TYPO3\CMS\Core\Resource\AbstractFile::FILETYPE_VIDEO -> \TYPO3\CMS\Core\Resource\FileType::VIDEO->value

\TYPO3\CMS\Core\Resource\AbstractFile::FILETYPE_APPLICATION -> \TYPO3\CMS\Core\Resource\FileType::APPLICATION->value

Ändern Sie dasselbe für TEXT, AUDIO, VIDEO, APPLICATION und UNKNOWN.

4. DataProviderContext Getter und Setter

Seit TYPO3 v13.4 verwendet Datenanbieterkontext die Konstruktor-Property-Promotion und wird in v14 zu einer readonly, finalen Klasse.

Vorher (setter-basiert):

$dataProviderContext = GeneralUtility::makeInstance(DataProviderContext::class);
$dataProviderContext
    ->setPageId($pageId)
    ->setData($parameters['row'])
    ->setTableName($parameters['table'])
    ->setFieldName($parameters['field'])
    ->setPageTsConfig($pageTsConfig);

Nach (konstruktorbasiert):

$dataProviderContext = new DataProviderContext(
    pageId: $pageId,
    tableName: $table,
    fieldName: $field,
    data: $row,
    pageTsConfig: $pageTsConfig
);

Greifen Sie direkt auf Eigenschaften zu, anstatt auf Getter.

Vorher

$pageId = $dataProviderContext->getPageId()

Nach

$pageId = $dataProviderContext->pageId

5. TypoScriptFrontendController und $GLOBALS['TSFE']

TypoScriptFrontendController und $GLOBALS['TSFE'] sind veraltet und werden in v14 entfernt.

Was zu tun ist:
Verwenden Sie Request-Attribute oder die Context API.

Vor v13:

$feUser = $GLOBALS['TSFE']->fe_user->user;

Nach v13

use TYPO3\CMS\Core\Context\Context;

$feUser = GeneralUtility::makeInstance(Context::class)
	->getPropertyFromAspect('frontend.user', 'user');

6. Fluid-Eigenständige Methoden

Mehrere eigenständige Fluid-Methoden wie TYPO3Fluid\Fluid\Core\ViewHelper\AbstractTagBasedViewHelper->registerUniversalTagAttributes() und AbstractTagBasedViewHelper->registerTagAttribute() sind veraltet.

Auswirkung:

Benutzerdefinierte ViewHelpers können Warnmeldungen auslösen.

Maßnahme:

Überprüfen Sie Fluid-Extensions und folgen Sie der aktuellen Fluid-API-Dokumentation.

7. Table-abhängige columnsOnly-Definition

Der columnsOnly-Parameter muss jetzt pro Tabelle definiert werden.

Vorher:

$urlParameters = [
    'edit' => [
        'pages' => [
            1 => 'edit',
        ],
    ],
    'columnsOnly' => 'title,slug'
    'returnUrl' => $request->getAttribute('normalizedParams')->getRequestUri(),
];

GeneralUtility::makeInstance(UriBuilder::class)->buildUriFromRoute('record_edit', $urlParameters);

Nach:

$urlParameters = [
    'edit' => [
        'pages' => [
            1 => 'edit',
        ],
    ],
    'columnsOnly' => [
        'pages' => [
            'title',
            'slug'
        ]
    ],
    'returnUrl' => $request->getAttribute('normalizedParams')->getRequestUri(),
];

GeneralUtility::makeInstance(UriBuilder::class)->buildUriFromRoute('record_edit', $urlParameters);

8. Namespace-Kurzform-Validatoren in Extbase

Die Notation für Namespaced Shorthand Validators ist veraltet.

Vorher:

/**
 * @Extbase\Validate("TYPO3.CMS.Extbase:NotEmpty")
 */
protected $myProperty1;

/**
 * @Extbase\Validate("Vendor.Extension:Custom")
 */
protected $myProperty2;

Nach:

/**
 * @Extbase\Validate("NotEmpty")
 */
protected $myProperty1;

/**
 * @Extbase\Validate("Vendor\Extension\Validation\Validator\CustomValidator")
 */
protected $myProperty2;

Oder

#[Extbase\Validate(['validator' => \TYPO3\CMS\Extbase\Validation\Validator\NotEmptyValidator::class])]
protected $myProperty1;

#[Extbase\Validate(['validator' => \Vendor\Extension\Validation\Validator\CustomValidator::class])]
protected $myProperty2;

Benutzerdefinierte Validatoren müssen vollständige Klassennamen verwenden.

9. Benutzerdefinierte Fluid-Views in Extbase

StandaloneView, TemplateView und verwandte Klassen sind veraltet.

Ersatz:

Verwenden Sie ViewFactoryInterface.

Dies betrifft benutzerdefinierte Extbase-Rendering-Logik.

10. renderStatic() in Fluid ViewHelpers

renderStatic() und verwandte Traits sind veraltet.

Vorher:

class MyViewHelper extends AbstractViewHelper
{
	use CompileWithRenderStatic;

	public static function renderStatic(array $arguments, \Closure $renderChildrenClosure, RenderingContextInterface $renderingContext): string
	{
	    	return $renderChildrenClosure();
	}
}

Nach:

class MyViewHelper extends AbstractViewHelper
{
	public function render(): string
	{
    	return $this->renderChildren();
	}
}

ViewHelpers entsprechend umgestalten.

11. IconRegistry-Instanziierung in ext_localconf.php

Die manuelle Icon-Registrierung in ext_localconf.php ist veraltet.

Vor v13:

EXT:example/ext_localconf.php
<?php
$iconRegistry = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance(\TYPO3\CMS\Core\Imaging\IconRegistry::class,);
$iconRegistry->registerIcon(
	'example',
	\TYPO3\CMS\Core\Imaging\IconProvider\SvgIconProvider::class,
	[
    	'source' => 'EXT:example/Resources/Public/Icons/example.svg'
	],
);

Nach v13

EXT:example/Configuration/Icons.php
<?php
return [
	'example' => [
    		'provider' => \TYPO3\CMS\Core\Imaging\IconProvider\SvgIconProvider::class,
	    	'source' => 'EXT:example/Resources/Public/Icons/example.svg',
	],
];

12. INCLUDE_TYPOSCRIPT-Syntax

Die <INCLUDE_TYPOSCRIPT:> Syntax ist veraltet.

Vor v13:

<INCLUDE_TYPOSCRIPT: source="FILE:EXT:my_extension/Configuration/TypoScript/myMenu.typoscript">

Nach v13

@import 'EXT:my_extension/Configuration/TypoScript/myMenu.typoscript'

13. Plugin-Content-Elemente und SubTypes

Die Registrierung von Plugins über list_type ist veraltet.

TYPO3 v14-Ansatz:
Jedes Plugin muss seinen eigenen CType haben.

14. @typo3/backend/wizard.js

Das Legacy-Wizard-Modul ist veraltet.

Ersatz:

@typo3/backend/multi-step-wizard.js

Erforderlich für Backend-Assistenten-Erweiterungen.

Vor v13

import Wizard from '@typo3/backend/wizard.js';
Wizard.addSlide(
 	'My-slide-identifier',
 	'Slide title',
 	'Content of my slide',
 	SeverityEnum.notice,
 	function () {
	     	// callback executed after displaying the slide
 	}
);

Nach

import MultiStepWizard from '@typo3/backend/multi-step-wizard.js';
MultiStepWizard.addSlide(
 	'my-slide-identifier',
 	'Slide title',
 	'Content of my slide',
 	SeverityEnum.notice,
	'My step',
 	function () {
	     	// callback executed after displaying the slide
 	}
);

15. ID der Seitenbaum-Navigationskomponente

Die ID der Seitenbaum-Komponente wurde umbenannt.

Alt:

@typo3/backend/page-tree/page-tree-element

Neu:

@typo3/backend/tree/page-tree-element

Aktualisieren Sie benutzerdefinierte Backend-Module entsprechend.

16. GeneralUtility::hmac()

GeneralUtility::hmac() ist veraltet.

Ersatz:

HashService::hmac()

Verwenden Sie Dependency Injection oder GeneralUtility::makeInstance().

Vor v13

$hmac = GeneralUtility::hmac('some-input', 'some-secret');

Nach v13

Verwendung TYPO3\CMS\Core\Crypto\HashService;

$hashService = GeneralUtility::makeInstance(HashService::class);$hmac = $hashService->hmac('some-input', 'some-secret');

17. Fluid Variables: true, false, null

Fluid erlaubt keine Variablen mehr mit den Namen true, false oder null.

Maßnahme:

Benennen Sie konfliktreiche Variablen um, um Laufzeitausnahmen zu vermeiden.

Vor v13

<f:variable name="true" value="someValue" />

Nach v13

<f:variable name="myTrue" value="someValue" />

Umgang mit Deprecations in der Praxis

  • Blockiere dein v13-Upgrade nicht nur wegen Deprecations.
  • Behebe Deprecations in aktiv gewarteten Extensions.
  • Entferne veraltete APIs in eigenem Code, den du kontrollierst.
  • Lasse Drittanbieter-Extensions für Vendor-Updates, falls notwendig.

Das frühzeitige Angehen dieser Punkte reduziert den Aufwand erheblich, wenn du auf TYPO3 v14 umsteigst.

Praktische Upgrade-Checkliste für Dein Projekt

Upgradetips: praktische checklist

Verwende diese Liste als letzte Überprüfung vor und nach deinem v13-Upgrade.

Vor dem Upgrade

  • Überprüfe und behebe Wichtige Änderungen im eigenen Code
  • Ersetze entfernte Hooks durch PSR-14-Events
  • Prüfe Extensions auf v13-Kompatibilität
  • Behebe alle in v12 gemeldeten Deprecations

Während des Upgrades

  • Führe alle Upgrade-Wizards im Install-Tool aus
  • Validere Datenbankschema- und TCA-Änderungen
  • Leere Caches und bestätige Backend-Zugriff

Nach dem Upgrade

  • Teste Backend-Workflows, RTE und benutzerdefinierte Module
  • Überprüfe das Frontend-Rendering und kritische Benutzerflüsse
  • Durchsuche den Code nach veralteten APIs und Konstanten
  • Überwache Logs auf verbleibende Warnungen oder Notices

Projekte, die diese Schritte als obligatorisch und nicht optional behandeln, vermeiden die meisten Upgrade-Regressionsfehler und reduzieren langfristige Wartungsrisiken.

Fazit

TYPO3 v13 zieht die Plattform an den richtigen Stellen an. Legacy-Hooks sind verschwunden, APIs sind klarer, und Abhängigkeiten sind modernisiert. Das Upgrade ist handhabbar, wenn es methodisch angegangen wird.

Projekte, die Breaking Changes frühzeitig beheben und Deprecations jetzt aufräumen, werden mit deutlich weniger Aufwand in TYPO3 v14 übergehen.

FAQs

Ja. TYPO3 v14 entfernt APIs und Muster, die in v13 nur veraltet sind. Das Überspringen von v13 bedeutet, dass man gleichzeitig mit Breaking Changes und Deprecations umgehen muss, was das Upgrade-Risiko erheblich erhöht. Ein sauberes v13-Upgrade reduziert den Aufwand und macht den Übergang zu v14 planbar.

Benutzerdefinierte Extensions sind der häufigste Fehlerpunkt. Entfernte Hooks, Änderungen an der QueryBuilder-API, striktere Typisierung in Extbase und der veraltete Zugriff auf $GLOBALS['TSFE'] führen oft zu fatalen Fehlern. Core-only-Projekte mit minimaler Anpassung können normalerweise mit weniger Problemen upgraden.

Ja, aber es wird nicht empfohlen. Deprecations blockieren TYPO3 v13 nicht, aber sie ungelöst zu lassen, erhöht die technische Schuld und macht das Upgrade auf v14 schwieriger. Deprecations in aktiv gewarteten Extensions sollten während des v13-Upgrade-Zyklus behoben werden.

Extensions sollten zuerst überprüft werden. TYPO3-Upgrades werden oft durch inkompatible Extensions blockiert, nicht durch Core-Änderungen. Behebe oder ersetze nicht unterstützte Extensions, bevor du benutzerdefinierten Code refaktorisierst. Benutzerdefinierte Extensions erfordern oft mehr Arbeit als Site-Pakete oder Templates.

Es hängt von der Projektkomplexität ab. Einfache Projekte können in wenigen Tagen aktualisiert werden. Projekte mit mehreren benutzerdefinierten Extensions und Legacy-Hooks benötigen oft mehrere Wochen, einschließlich Tests und Aufräumarbeiten. Planung und Extensions-Audits haben mehr Einfluss als reine Entwicklungszeit.

Deprecations als optional zu behandeln und architektonische Fixes aufzuschieben. Legacy-Hooks, lockere Typisierung und veraltete APIs funktionieren vielleicht noch in v13, werden aber in v14 fehlschlagen. Sie frühzeitig zu beheben, reduziert die langfristigen Wartungskosten und vermeidet hektische Upgrades später.

Your One-Stop Solutions for Custom TYPO3 Development

  • A Decade of TYPO3 Industry Experience
  • 350+ Successful TYPO3 Projects
  • 87% Repeat TYPO3 Customers
TYPO3 Service
wolfgang weber
Wolfgang Weber

Wolfgang Weber

Brand & Communication Lead

Wolfgang Weber gestaltet TYPO3 mit Leidenschaft und Expertise. Als langjähriger TYPO3-Enthusiast hat er zu zahlreichen Projekten beigetragen, die Websites schneller und sicherer machen. Abseits von TYPO3 findet man ihn…

More From Author

Previous Article
15+ hilfreich TYPO3 Console Commands (CLI)-die kennen sollten
Next Article
Wiedersehen Manuell, Hallo Automated TYPO3 Installation

Post a Comment

×

You May Also Like

Claude Code & TYPO3: Ein praktischer Entwicklerleitfaden

Claude Code & TYPO3: Ein praktischer Entwicklerleitfaden

Wolfgang Weber
Development
Von Drupal zu TYPO3: Ein Migrations Playbook

Migration von Drupal zu TYPO3: Eine Schritt-für-Schritt-Anleitung

Wolfgang Weber
Development
TYPO3 Backend Intranet Extranet Gebaeude Leitfaden

Vom CMS zum Intranet: Aufbau mit dem TYPO3 nativen Backend

Wolfgang Weber
Development