Automatisiere TYPO3 Upgrades: Vollständig Rector Leitfaden 2026

TYPO3-Upgrades bedeuteten früher einmal tagelanges manuelles Refactoring, Korrekturen veralteter APIs und Changelog-Prüfungen. Im Jahr 2026 ist dieser Ansatz nicht mehr skalierbar.

Mit der Veröffentlichung von TYPO3 v14 LTS im April 2026 und dem Ende des kostenlosen Supports für TYPO3 v12 modernisieren viele Agenturen und Entwickler ältere TYPO3-Projekte schneller als je zuvor. Manuelle Upgrades sind langsam, fehleranfällig und schwer zu warten.

TYPO3 Rector automatisiert einen großen Teil des Migrationsprozesses. Aufbauend auf Rector liest es offizielle TYPO3-Changelogs und refaktoriert automatisch veralteten Code, aktualisiert TCA-Konfigurationen, modernisiert APIs und bereitet Extensions für neuere TYPO3-Versionen vor.

Anstatt Tage mit wiederholenden Korrekturen zu verbringen, kannst du dich auf Tests und Validierung konzentrieren.

In diesem Leitfaden erfährst du, wie du TYPO3 Rector installierst, konfigurierst und verwendest, um TYPO3-Upgrades im Jahr 2026 schneller und sicherer durchzuführen.

Was ist ein TYPO3 Rector?

TYPO3 Rector ist ein automatisiertes Refactoring-Tool für TYPO3-Upgrades. Es hilft Entwicklern, TYPO3-Websites und Extensions zwischen Versionen mit weniger manuellen Änderungen zu migrieren.

TYPO3 Rector analysiert Ihren Code und wendet automatisch Upgrade-Regeln basierend auf offiziellen TYPO3-Changelogs und Veraltungen an.

Es kann automatisieren:

• Ersetzungen veralteter APIs
• PHP- und TCA-Refactoring
• Namespace- und Klassenaktualisierungen
• Änderungen der Methodensignatur
• Vorbereitung der Ereignismigration
• Modernisierung der Konfiguration

TYPO3 Rector arbeitet zusammen mit anderen TYPO3-Upgrade-Tools:

• TYPO3 Rector → automatisiertes PHP/TCA-Refactoring
• Extension Scanner → erkennt veraltete TYPO3-APIs
• Upgrade Wizards → verwalten Datenbank- und System-Upgrades

Durch die Automatisierung repetitiver Migrationsarbeiten hilft TYPO3 Rector, TYPO3 v10, v11, v12, v13 und v14 Projekte mit deutlich weniger Aufwand upgradebereit zu halten.

TYPO3 Rector im Jahr 2026: Was es automatisiert vs. Was es nicht kann

Manuelle TYPO3-Upgrades sind langsam und fehleranfällig. Entwickler verbringen oft Stunden damit, Änderungsprotokolle zu überprüfen, veraltete APIs zu beheben und alte Extensions manuell zu aktualisieren.

TYPO3 Rector automatisiert einen Großteil dieser sich wiederholenden Arbeit mithilfe offizieller TYPO3-Migrationsregeln und verkürzt die Upgrade-Zeit von Tagen auf Stunden.

Was TYPO3 Rector automatisiert

TYPO3 Rector kann automatisch Folgendes bearbeiten:

• Veraltete TYPO3 API-Migrationen
• PHP-Namespace- und Klassen-Refactoring
• TCA-Normalisierung
• Aktualisierungen der Methodensignatur
• Vorbereitung der Event- und Hook-Migration
• TYPO3-Konfiguration Modernisierung
• Refactoring des Extension codes

Vorteile umfassen:

• Schnellere TYPO3-Upgrades
• Weniger übersehene Veraltungen
• Konsistentes Refactoring
• Reduzierte manuelle Arbeit
• Mehr Zeit für Tests und Qualitätssicherung

Was TYPO3 Rector nicht automatisieren kann

TYPO3 Rector erfordert weiterhin manuelle Validierung für:

• Geschäftslogik-Tests
• Fluid- und Frontend-Redesigns
• Kompatibilität von Drittanbieter-Extensions
• Entscheidungen zur Datenbankbereinigung
• Qualitätssicherung und Funktionstests
• Projektspezifische Randfälle

TYPO3 Rector sollte als Upgrade-Automatisierungsassistent betrachtet werden, nicht als Ersatz für Tests und Freigabevalidierung.

TYPO3 Rector vs Manuelle TYPO3-Upgrades

Traditionelle TYPO3-Upgrades beinhalten manuelles Refactoring, das Beheben veralteter APIs und sich wiederholende Code-Updates. Mit zunehmender Größe von TYPO3-Projekten werden manuelle Migrationen langsamer und schwerer zu warten.

TYPO3 Rector automatisiert viele dieser Aufgaben mithilfe offizieller TYPO3-Migrationsregeln.

Für viele TYPO3-Agenturen und Entwicklungsteams im Jahr 2026 ist TYPO3 Rector zu einem Kernwerkzeug geworden, um den Upgrade-Aufwand zu reduzieren und die Kompatibilität mit TYPO3 v12, v13 und v14 zu gewährleisten.

TYPO3 Rector vs Extension Scanner vs Fractor

Moderne TYPO3-Upgrades kombinieren oft mehrere Werkzeuge, die jeweils einen anderen Teil des Migrations-Workflows abdecken.

TYPO3 Rector

Automatisiert TYPO3-spezifisches PHP- und TCA-Refactoring unter Verwendung offizieller TYPO3-Migrationsregeln.

TYPO3 Extension Scanner

Erkennt veraltete APIs und Kompatibilitätsprobleme von Extensions, schreibt jedoch den Code nicht automatisch um.

TYPO3 Upgrade Wizard

Verarbeitet Datenbankschema-Updates und Systemmigrationen nach TYPO3 Core-Upgrades.

Fractor

Ergänzt TYPO3 Rector durch Modernisierung von:

• TypoScript
• FlexForms
• XML
• YAML
• composer.json-Dateien

Viele TYPO3-Agenturen kombinieren jetzt TYPO3 Rector, Fractor, Extension Scanner und Upgrade Wizards für sicherere Upgrade-Workflows.

TYPO3-Version & PHP-Kompatibilitätsmatrix (2026)

Bevor Sie TYPO3 Rector ausführen, überprüfen Sie die Kompatibilität von TYPO3 und PHP, um Migrationskonflikte zu vermeiden.

Stand Mai 2026:

• TYPO3 14.3.1 ist die aktuelle stabile Version
• TYPO3 v14 LTS wurde am 21. April 2026 veröffentlicht

• Der kostenlose Support für TYPO3 v12 endete am 30. April 2026

TYPO3 v14 Support-Zeitleiste

TYPO3 v14 LTS umfasst:

• Fehlerbehebungssupport bis Dezember 2027
• Sicherheitssupport bis Juni 2029

Für die meisten TYPO3-Projekte im Jahr 2026 ist TYPO3 v14 mit PHP 8.2+ das empfohlene langfristige Upgrade-Ziel.

TYPO3 Upgrade-Bereitschafts-Checkliste

Bevor Sie TYPO3 Rector verwenden, stellen Sie sicher, dass Ihr TYPO3-Projekt ordnungsgemäß vorbereitet ist.

Checkliste vor dem Upgrade

• Composer-basierte TYPO3-Installation
• TYPO3- und PHP-Versionen dokumentiert
• Kompatible PHP-Version für die Ziel-TYPO3-Version
• Datenbank- und Projekt-Backups abgeschlossen
• Git-Versionskontrolle aktiviert
• Saubere Staging- oder lokale Umgebung bereit
• TYPO3 Extensions geprüft
• Nicht unterstützte Extensions identifiziert
• TYPO3 Extension Scanner ausgeführt
• Kritische Workflows dokumentiert
• CI/CD-Validierung vorbereitet

Wichtige Sicherheitsempfehlungen

Führen Sie TYPO3 Rector niemals auf Produktionssystemen aus. Führen Sie Migrationen immer in lokalen oder Staging-Umgebungen durch, in denen Änderungen überprüft, getestet und sicher zurückgesetzt werden können.

Erstellen Sie vor jedem wichtigen Migrationsschritt einen Git-Commit, um das Zurücksetzen und Debuggen zu vereinfachen.

Empfohlener TYPO3-Upgrade-Workflow (2026)

Ein sicherer TYPO3-Upgrade-Workflow kombiniert automatisiertes Refactoring, Kompatibilitätsprüfungen und Tests.

1. Überprüfung der TYPO3- & PHP-Versionen

Überprüfen:

• Aktuelle TYPO3-Version
• PHP-Version
• Installierte Extensions
• Composer-Abhängigkeiten

2. Zuerst PHP aktualisieren

Neuere TYPO3-Versionen erfordern oft moderne PHP-Versionen:

• TYPO3 v12 → PHP 8.1+
• TYPO3 v14 → PHP 8.2+

3. TYPO3-Extensions scanner ausführen

Erkennen:

• Veraltete TYPO3-APIs
• Probleme mit Legacy-Extensions
• Entfernte Kernmethoden

4. TYPO3 Rector installieren

Installieren Sie TYPO3 Rector global oder pro Projekt mit Composer.

5. Backups erstellen & Git Commit

git add .

git commit -m “Backup vor TYPO3 Rector Migration”

6. Trockentestmodus ausführen

vendor/bin/typo3-rector process --dry-run

Überprüfen Sie API-Ersetzungen, TCA-Updates und Namensraumänderungen, bevor Sie Migrationen anwenden.

7. TYPO3 Rector Änderungen anwenden

vendor/bin/typo3-rector process

Schrittweise aktualisieren:

• TYPO3 v10 → v11
• TYPO3 v11 → v12
• TYPO3 v12 → v13
• TYPO3 v13 → v14

8. Fractor ausführen

Verwenden Sie Fractor für TypoScript-, XML- und FlexForm-Migrationen.

9. Datenbank-Upgrades ausführen

Nach der Migration:

• Upgrade-Assistenten ausführen
• Datenbankschema-Updates anwenden
• Caches leeren

10. QA & Tests durchführen

Validieren:

• Backend-Workflows
• Frontend-Darstellung
• Extensions
• Scheduler-Aufgaben
• Formulare und APIs

11. Sicher bereitstellen

Schrittweise bereitstellen, Protokolle überwachen und Rollback-Pläne für Produktionsfreigaben bereithalten.

Installation von TYPO3 Rector

TYPO3 Rector kann global, pro Projekt oder als eigenständige PHAR-Datei installiert werden. Für die meisten TYPO3-Projekte im Jahr 2026 wird die Installation über Composer empfohlen.

Globale Installation

Nützlich für Entwickler oder TYPO3-Agenturen, die mehrere Projekte verwalten.

Global installieren:

composer global require ssch/typo3-rector

Fügen Sie das globale Bin-Verzeichnis von Composer zum PATH hinzu:

export PATH="$PATH:$HOME/.composer/vendor/bin"

Installation überprüfen:

typo3-rector --version

Projektinstallation

Empfohlen für:

• Teamprojekte
• CI/CD-Pipelines
• Versionskontrollierte Umgebungen

Lokal installieren:

composer require --dev ssch/typo3-rector

TYPO3 Rector ausführen:

vendor/bin/typo3-rector process

PHAR-Installation

Nützlich für schnelles Testen oder isolierte Umgebungen.

PHAR herunterladen:

wget https:// github.com/sabbelasichon/typo3-rector/releases/latest/download/typo3-rector.phar

Ausführbar machen:

chmod +x typo3-rector.phar

TYPO3 Rector ausführen:

./typo3-rector.phar process

Welche Installationsmethode sollten Sie wählen?

Empfohlener Ansatz für 2026

Für die meisten modernen TYPO3-Projekte ist die Composer-Installation auf Projektebene die sicherste Option, weil:

• TYPO3 Rector-Versionen konsistent bleiben
• CI/CD-Workflows reproduzierbar bleiben
• Teams das gleiche Migrationssetup teilen
• Abhängigkeiten versionskontrolliert bleiben

Die globale Installation ist weiterhin nützlich für Agenturen, die mehrere TYPO3-Projekte verwalten.

Erstellen Ihrer ersten rector.php-Konfiguration

Nach der Installation von TYPO3 Rector erstellen Sie eine rector.php-Konfigurationsdatei. Sie definiert:

• Welche TYPO3-Verzeichnisse gescannt werden sollen
• Welche Migrationsregeln ausgeführt werden sollen
• Welche Dateien oder Ordner übersprungen werden sollen

Eine gute Konfiguration hilft, Upgrade-Risiken und unnötige Codeänderungen zu reduzieren.

Empfohlene Starter-Konfiguration für 2026

declare(strict_types=1);

use Rector\Config\RectorConfig;
use Ssch\TYPO3Rector\Set\Typo3SetList;

return RectorConfig::configure()
   ->withPaths([
       __DIR__ . '/packages',
       __DIR__ . '/typo3conf/ext',
   ])
   ->withSets([
       Typo3SetList::TYPO3_12,
       Typo3SetList::TYPO3_13,
   ])
   ->withSkip([
       __DIR__ . '/vendor',
       '*/Resources/Public/*',
       '*/node_modules/*',
   ]);

Verstehen der Hauptkonfigurationsoptionen

Pfade

Definiert, welche TYPO3-Verzeichnisse von Rector verarbeitet werden sollen:

->withPaths([
   __DIR__ . '/packages',
   __DIR__ . '/typo3conf/ext',
   __DIR__ . '/src',
])

Gängige Pfade:

• TYPO3-Extensions
• Site-Pakete
• PHP-Quellverzeichnisse

TYPO3 Rector Sets

Definiert, welche TYPO3-Migrationsregeln ausgeführt werden sollen:

->withSets([
   Typo3SetList::TYPO3_12,
   Typo3SetList::TYPO3_13,
])

Jedes Set enthält versionsspezifische TYPO3-Upgrade-Regeln.

Überspringen-Regeln

Schließt Verzeichnisse oder Dateien von der Verarbeitung aus:

->withSkip([
   __DIR__ . '/vendor',
   '*/Resources/Public/*',
   '*/Tests/*',
])

Nützlich zum Ausschließen von:

• Vendor-Code
• Generierte Assets
• Frontend-Bibliotheken
• Testverzeichnisse

Sicherere TYPO3 Rector Konfigurationstipps

Für sicherere TYPO3-Upgrades:

• Wenden Sie ein TYPO3-Set nach dem anderen an
• Verarbeiten Sie zuerst benutzerdefinierte Extensions
• Schließen Sie Vendor/Public-Assets aus
• Beginnen Sie mit --dry-run
• Commit nach jedem Migrationsschritt

Häufige Konfigurationsfehler in rector.php

Zu viele TYPO3 Sets gleichzeitig ausführen

Das Anwenden mehrerer großer TYPO3-Migrationssets zusammen kann das Debuggen erschweren.

Verzeichnisse von Drittanbietern verarbeiten

Führen Sie Rector niemals in folgenden Verzeichnissen aus:

• /vendor
• node_modules
• generierte Frontend-Assets

Trockene Läufe überspringen

Überprüfen Sie immer die Änderungen, bevor Sie sie anwenden.

Auf Produktion ausführen

TYPO3 Rector sollte nur in folgenden Umgebungen ausgeführt werden:

• Lokale Entwicklungsumgebungen
• Staging-Server
• CI/CD-Validierungspipelines

Führen Sie niemals automatisierte TYPO3-Migrationen direkt auf Produktionssystemen aus.

Verständnis von TYPO3 Rector Sets

TYPO3 Rector verwendet vordefinierte „Sets“ für spezifische TYPO3-Versionen. Jedes Set enthält automatisierte Migrationsregeln basierend auf TYPO3-Abschreibungen und API-Änderungen.

Gängige TYPO3 Rector Sets

Beispiel:

->withSets([
   Typo3SetList::TYPO3_12,
])

TCA-Migrationssätze

TYPO3 Rector enthält auch spezielle TCA-Migrationssätze:

->withSets([
   Typo3SetList::TCA_120,
])

TCA-Regeln helfen:

• TCA-Arrays zu normalisieren
• Veraltete Elementformate zu konvertieren
• Backend-Konfigurationen zu modernisieren

Für große TYPO3-Projekte ist es in der Regel sicherer, TCA-Migrationen separat durchzuführen.

Vermeiden Sie die Kombination mehrerer TYPO3-Sets

Das gleichzeitige Ausführen mehrerer großer TYPO3-Sets kann:

• Falsch-positive Ergebnisse erhöhen
• Überlappende Änderungen erzeugen
• Veraltete Extensions beschädigen
• Das Debuggen erschweren

Vermeiden Sie Setups wie:

->withSets([
   Typo3SetList::TYPO3_95,
   Typo3SetList::TYPO3_14,
])

Stattdessen wenden Sie Rector-Sets schrittweise an und validieren nach jedem Schritt.

Empfohlene schrittweise TYPO3-Upgrade-Strategie

Sicherster Upgrade-Pfad für 2026:

1. TYPO3 v9 → v10
2. TYPO3 v10 → v11
3. TYPO3 v11 → v12
4. TYPO3 v12 → v13
5. TYPO3 v13 → v14

Empfohlener Arbeitsablauf:

• Einen Rector-Satz anwenden
• Tests durchführen
• Probleme beheben
• Änderungen committen
• Zur nächsten Version übergehen

Dies reduziert das Migrationsrisiko und vereinfacht das Zurücksetzen.

Warum schrittweise TYPO3-Upgrades wichtig sind

Das Überspringen von TYPO3-Versionen kann verursachen:

• Defekte Extension-APIs
• Fehlende Veraltungsbehebungen
• PHP-Kompatibilitätskonflikte
• Ungültige TCA-Konfigurationen
• Schwieriges Debugging

Ältere TYPO3-Extensions verlassen sich oft auf veraltete Hooks, veraltete APIs und alte Datenbanklogik. Schrittweise Upgrades erleichtern es:

• Probleme früher zu erkennen
• Extension kompatibilität zu erhalten
• Änderungen Schritt für Schritt zu validieren
• Das Bereitstellungsrisiko zu reduzieren

Für die meisten TYPO3-Projekte

Sicheres Ausführen von TYPO3 Rector

TYPO3 Rector kann große Teile von TYPO3-Upgrades automatisieren, aber sichere Migrationspraktiken sind weiterhin unerlässlich.

Trockene Läufe

Änderungen vorschauen, bevor Dateien modifiziert werden:

vendor/bin/typo3-rector process --dry-run

Trockene Läufe helfen, riskante Refaktorisierungen und veraltete API-Ersetzungen zu erkennen, bevor Migrationen angewendet werden.

Git-Workflow

Erstellen Sie immer ein Git-Backup, bevor Sie TYPO3 Rector ausführen:

git add .

git commit -m "Backup vor TYPO3 Rector Migration"

Nach der Migration:

git diff

Beste Praktiken:

• Wenden Sie einen Rector-Satz nach dem anderen an
• Überprüfen Sie die Änderungen sorgfältig
• Commit nach jedem Migrationsschritt

Rollback-Strategie

Behalten Sie immer:

• Git-Backups
• Datenbank-Backups
• Staging-Umgebungen
• Rollback-Pläne

Wenn Probleme auftreten, Änderungen schnell mit Git oder Bereitstellungs-Workflows rückgängig machen.

Führen Sie Rector niemals in der Produktion aus

Führen Sie TYPO3 Rector niemals direkt auf Produktionssystemen aus.

Führen Sie Migrationen nur in folgenden Umgebungen durch:

• Lokale Entwicklung
• Staging-Umgebungen
• CI/CD-Pipelines

Testen Sie immer TYPO3-Upgrades vor der Bereitstellung.

Migrieren von benutzerdefinierten TYPO3-Extensions

TYPO3 Rector ist besonders nützlich für das Upgrade von benutzerdefinierten TYPO3-Extensions.

Beispielkonfiguration:

return RectorConfig::configure()
   ->withPaths([
       __DIR__ . '/Classes',
       __DIR__ . '/Configuration',
   ])
   ->withSets([
       Typo3SetList::TYPO3_12,
       Typo3SetList::TYPO3_13,
       Typo3SetList::TYPO3_14,
   ])
   ->withSkip([
       __DIR__ . '/Resources',
   ]);

TYPO3 Rector kann modernisieren:

• Veraltete TYPO3-APIs
• Legacy-Namespaces
• TCA-Konfigurationen
• Alte Hook-Implementierungen
• Vorbereitung der Event-Migration

Für TYPO3-Upgrades von v12–v14 können Extensions auch Folgendes erfordern:

• PSR-14 Event-Migration
• Composer-Updates
• PHP 8.2+ Kompatibilitätskorrekturen

Testen Sie benutzerdefinierte Extensions nach der Migration immer separat, insbesondere wenn Legacy-TYPO3-Integrationen beteiligt sind.

Umgang mit Drittanbieter-Extensions während TYPO3-Upgrades

Drittanbieter-Extensions sind eines der größten Risiken bei TYPO3-Upgrades.

Häufige Probleme:

• Composer-Konflikte
• Nicht unterstützte TYPO3-Versionen
• Verwaiste Extensions
• Veraltete APIs
• Fehlende PHP 8.2+ Unterstützung

Vor dem Upgrade:

• Installierte Extensions prüfen
• TYPO3/PHP-Kompatibilität überprüfen
• Composer- und TER-Einschränkungen überprüfen

Häufige Strategien:

• Veraltete Extensions ersetzen
• Verwaiste Pakete forken
• Composer-Patches anwenden
• TYPO3 Rector auf benutzerdefinierten Forks ausführen

Manchmal ist es sicherer, eine veraltete Extension zu ersetzen, als nicht unterstützten Code zu pflegen.

TYPO3 v14 Migrationsüberlegungen

Mit der Veröffentlichung von TYPO3 v14 LTS im April 2026 sollten Projekte sich vorbereiten auf:

• PHP 8.2+ Kompatibilität
• Entfernte TYPO3 APIs
• PSR-14 Event-Migrationen
• Backend-Modernisierung
• Aktualisierungen der Extension kompatibilität

TYPO3 v14 setzt TYPO3s Weg zu modernen PHP-Standards, Dependency Injection und saubereren APIs fort.

Ältere TYPO3-Extensions erfordern möglicherweise weiterhin manuelle Refaktorisierung und Tests.

Echte TYPO3-Migrationsbeispiele

Signal/Slot → PSR-14

Vorher:

$dispatcher->connect(...);

Nachher:

services:
 MyEventListener:
   tags:
     - name: event.listener

TCA-Migration

Vorher:

['Label', 123, 'icon.svg']

Nachher:

[
 'label' => 'Label',
 'value' => 123,
 'icon' => 'icon.svg'
]

Datenbank-API-Migration

Vorher:

$GLOBALS['TYPO3_DB']->exec_SELECTquery(...);

Nachher:

GeneralUtility::makeInstance(ConnectionPool::class)

Erweiterte TYPO3 Rector Konfiguration

Für große oder komplexe TYPO3-Projekte unterstützt TYPO3 Rector erweiterte Konfigurationsoptionen für bessere Leistung, benutzerdefinierte Migrationen und schnellere Verarbeitung.

Benutzerdefinierte Regeln

Sie können benutzerdefinierte Rector-Regeln für projektspezifische TYPO3-Migrationen hinzufügen:

return RectorConfig::configure()

    ->withRules([
       MyCustomRector::class,
   ]);

Benutzerdefinierte Regeln sind nützlich für:

• Veraltete interne APIs
• Unternehmensspezifische Kodierungsstandards
• Wiederholte manuelle Refactoring-Aufgaben

Parallele Verarbeitung

Aktivieren Sie die parallele Ausführung, um große TYPO3-Migrationen zu beschleunigen:

return RectorConfig::configure()

    ->withParallel()
   ->withPaths([
       __DIR__ . '/packages',
   ]);

Dies ist besonders nützlich für Unternehmens-TYPO3-Projekte mit vielen Extensions.

Speichergrenzen

Große TYPO3-Codebasen können höhere PHP-Speichergrenzen erfordern:

return RectorConfig::configure()
   ->withMemoryLimit('2G');

Oder über CLI:

php -d memory_limit=2G vendor/bin/typo3-rector process

Selektive Verarbeitung

Verarbeiten Sie nur geänderte PHP-Dateien für schnellere CI/CD-Workflows:

CHANGED_FILES=$(git diff --name-only --diff-filter=AM main...HEAD | grep '\.php$')

vendor/bin/typo3-rector process $CHANGED_FILES

Selektive Verarbeitung hilft, die Ausführungszeit während Pull-Requests und automatisierten TYPO3-Upgrade-Checks zu reduzieren.

TYPO3 Rector für Unternehmen & Große Legacy-Projekte

Große TYPO3-Projekte umfassen oft Monorepos, Multisite-Setups und große Extension ökosysteme. Während TYPO3-Upgrades in Unternehmen wird die Leistungsoptimierung wichtig.

Empfohlene Praktiken:

• Parallele Verarbeitung aktivieren
• PHP-Speichergrenzen erhöhen
• Extensions schrittweise verarbeiten
• Vendor- und öffentliche Asset-Ordner ausschließen
• CI-Chunking für große Repositories verwenden

Beispiel:

return RectorConfig::configure()
   ->withParallel(8)
   ->withMemoryLimit('4G');

Häufige TYPO3 Rector Fehler und Lösungen

Speicherfehler

php -d memory_limit=2G vendor/bin/typo3-rector process

Composer-Konflikte

• Composer-Abhängigkeiten aktualisieren
• Kompatibilität der TYPO3-Extensions überprüfen
• PHP-Version-Unterstützung prüfen

Fehlende Klassenfehler

In der Regel verursacht durch veraltete Extensions oder fehlerhaftes Autoloading.

Beheben mit:

composer dump-autoload

Debug-Modus

vendor/bin/typo3-rector process --debug

Xdebug-Unterstützung

php -d xdebug.mode=debug vendor/bin/typo3-rector process

Teststrategie nach TYPO3-Migration

Nach dem Ausführen von TYPO3 Rector sollten Sie Ihr TYPO3-Projekt immer sorgfältig testen.

Empfohlene Überprüfungen:

• Backend-Smoke-Testing
• Validierung der Frontend-Darstellung
• Testen des Redakteur-Workflows
• Überprüfung der Scheduler-Aufgaben
• Integrationstests von Extensions
• PHPUnit und CI/CD-Pipelines

TYPO3 Rector automatisiert Migrationen, aber manuelle QA und funktionale Tests sind weiterhin unerlässlich.

Integration von TYPO3 Rector in CI/CD

Die Integration von TYPO3 Rector in CI/CD-Pipelines hilft Teams, veralteten TYPO3-Code frühzeitig zu erkennen und upgrade-bereite TYPO3-Projekte zu pflegen.

GitHub Actions

name: TYPO3 Rector Check

on: [push, pull_request]

jobs:
 rector:
   runs-on: ubuntu-latest

   steps:
     - uses: actions/checkout@v3

     - name: Setup PHP
       uses: shivammathur/setup-php@v2
       with:
         php-version: 8.2

     - name: Install dependencies
       run: composer install

     - name: Run TYPO3 Rector
       run: vendor/bin/typo3-rector process --dry-run

GitLab CI

rector:
 image: php:8.2

 script:
   - composer install
   - vendor/bin/typo3-rector process --dry-run

PHPStan & Integration der statischen Analyse

Viele TYPO3-Teams kombinieren TYPO3 Rector mit:

• PHPStan
• TYPO3 Extension Scanner
• PHPUnit

Dies hilft, Folgendes zu erkennen:

• Typfehler
• Veraltete TYPO3-APIs
• Fehlerhafte Extension logik
• Migrationsregressionen

Automatisierte Pull-Request-Validierung

Das Ausführen von TYPO3 Rector-Checks bei Pull-Requests hilft:

• Veralteten Code frühzeitig zu erkennen
• TYPO3-Projekte upgrade-bereit zu halten
• Zu verhindern, dass veraltete APIs in den Code gelangen
• Konsistente Kodierungsstandards über Teams hinweg zu wahren

Für Unternehmens-TYPO3-Projekte ist die CI/CD-Validierung nun ein Standardbestandteil der langfristigen Upgrade-Wartung.

Arbeiten mit Fractor

Fractor ergänzt TYPO3 Rector, indem es sich um nicht-PHP TYPO3-Dateien kümmert, wie zum Beispiel:

• TypoScript
• FlexForms
• XML
• YAML
• composer.json

Fractor wird nützlich, wenn TYPO3-Upgrades eine Modernisierung von TypoScript oder eine Umstrukturierung der Konfiguration erfordern, die über PHP-Codeänderungen hinausgehen.

Typischer Arbeitsablauf:

1. Führen Sie TYPO3 Rector für PHP- und TCA-Migrationen aus
2. Führen Sie Fractor für TypoScript- und XML-Updates aus
3. Führen Sie die TYPO3 Upgrade Wizards aus
4. Testen Sie das Projekt

Für größere TYPO3-Upgrades bieten Rector + Fractor zusammen einen vollständigeren Migrationsworkflow.

Empfohlene TYPO3-Upgrade-Toolchain im Jahr 2026

Moderne TYPO3-Upgrade-Workflows kombinieren in der Regel mehrere Werkzeuge:

Die Verwendung dieser Werkzeuge zusammen hilft, das Upgrade-Risiko zu reduzieren und die langfristige Wartbarkeit von TYPO3 zu verbessern.

Kann TYPO3 Rector TYPO3 7 Projekte aktualisieren?

Ja, aber ältere TYPO3 v7 Projekte erfordern in der Regel einen gestuften Migrationsansatz.

Typischer Upgrade-Pfad:

• TYPO3 v7 → v8
• TYPO3 v8 → v9
• TYPO3 v9 → v10+
• Schrittweise fortfahren bis TYPO3 v14

Häufige Herausforderungen sind:

• Veraltete Extension architektur
• Nicht unterstützte PHP-Versionen
• Veraltete TYPO3 APIs
• Entfernte Hooks und Datenbankmethoden
• Alte TCA-Strukturen

TYPO3 Rector kann viele Refactoring-Aufgaben automatisieren, aber TYPO3 7 Projekte erfordern oft noch manuelle Bereinigung, Extension ersetzungen und zusätzliche Tests.

Wie viel Zeit kann TYPO3 Rector sparen?

Der größte Vorteil von TYPO3 Rector ist die Reduzierung der sich wiederholenden Migrationsarbeit.

Typische Schätzungen im Jahr 2026:

TYPO3 Rector eliminiert nicht das Testen oder die Qualitätssicherung, aber es kann einen großen Prozentsatz der sich wiederholenden TYPO3-Upgrade-Aufgaben automatisieren und Teams helfen, sich mehr auf die Validierung statt auf manuelles Refactoring zu konzentrieren.

Beste Praktiken für TYPO3 Rector

Um sicherere und zuverlässigere TYPO3-Upgrades mit TYPO3 Rector zu erhalten, befolgen Sie diese bewährten Praktiken:

• Wenden Sie TYPO3-Upgrades schrittweise an
• Führen Sie TCA-Migrationen nach Möglichkeit separat durch
• Verwenden Sie immer die Git-Versionskontrolle
• Beginnen Sie mit dem --dry-run-Modus
• Testen Sie nach jedem Migrationsschritt
• Schließen Sie Vendor- und öffentliche Asset-Ordner aus
• Halten Sie TYPO3 Rector regelmäßig auf dem neuesten Stand
• Führen Sie Rector niemals direkt in der Produktion aus

TYPO3 Rector automatisiert repetitive Migrationsarbeiten, aber manuelles Testen und Qualitätssicherung sollten immer Teil des Upgrade-Prozesses bleiben.

Fazit

TYPO3 Rector hat die Art und Weise, wie Entwickler TYPO3-Upgrades im Jahr 2026 handhaben, revolutioniert. Anstatt Tage damit zu verbringen, veraltete APIs manuell zu beheben und Änderungsprotokolle zu vergleichen, können Teams einen Großteil der sich wiederholenden Migrationsarbeit automatisieren und sich mehr auf Tests und Validierung konzentrieren.

TYPO3 Rector ist kein vollständiger Ersatz für QA, Debugging oder architektonische Entscheidungen. Aber es reduziert den Upgrade-Aufwand erheblich, verbessert die Konsistenz und hilft, TYPO3-Projekte schneller zu modernisieren.

Für die langfristige Wartung von TYPO3 helfen automatisierte Upgrade-Workflows, technische Schulden zu reduzieren, die PHP-Kompatibilität zu verbessern und zukünftige TYPO3-Migrationen weitaus handhabbarer zu machen.