TYPO3 13.4 LTS — was 18 Monate seit Release im DACH-Markt verändert haben

Im November 2024 ist TYPO3 13.4 als Long-Term-Support-Release veröffentlicht worden, mit garantiertem Community-Support bis April 2027 und der Option auf Extended Long Term Support bis 2030. Achtzehn Monate später, im Mai 2026, lässt sich die Bilanz nüchtern ziehen: 13.4 ist im DACH-Markt angekommen, die Mehrheit der TYPO3-tragenden Mittelstandsprojekte ist von 12.4 entweder bereits migriert oder hat die Migration für 2026 geplant. Die Zahlen variieren je nach Erhebungsquelle, aber die Größenordnung ist stabil — rund 55 bis 65 Prozent der aktiven 12.4-Installationen sind im Mai 2026 auf 13.4 gehoben, ein Anteil, der für eine TYPO3-LTS-Transition im Vergleich zu früheren Zyklen (8.7 → 9.5, 10.4 → 11.5) im oberen Mittel liegt.

Die kurze Antwort vorneweg: 13.4 ist ein erfolgreiches LTS. Es ist nicht das spektakuläre Release, das 13.0 als Sprint-Release im April 2024 versprach, aber es ist das stabile Konsolidierungs-Release, das die Major-Sprünge der 13.x-Linie unter eine wartbare LTS-Klammer bringt. Wer im Mai 2026 ein 12.4-Projekt vor sich hat und über die Migration nachdenkt, hat keinen technischen Grund mehr, zu warten — alle relevanten Extensions sind portiert, die Werkzeugketten sind reif, die Dokumentation ist solide.

Die Container-Frage als Architekturweichenstellung

Das prominenteste Feature der 13er-Linie ist das integrierte Container Content Element System (CCES). Was die Community jahrelang über die Extension b13/container außerhalb des Cores gepflegt hat, ist mit 13.0 in den Core gewandert und mit 13.4 stabilisiert: Strukturelle Elemente — Spalten, Akkordeons, Tab-Gruppen, Hero-Bereiche — sind nicht mehr nur Container für tt_content-Kinder, sondern selbst als typisierte, im TCA-konfigurierte Strukturelemente erster Klasse modellierbar.

Die Konsequenz für die Agenturpraxis ist erheblich. Wer bis 12.4 für eine zweispaltige Layout-Komponente entweder Grid Elements (die Extension gridelements), Bootstrap Package oder die b13-Container-Extension einsetzte, lebte mit dem Trade-off zwischen Editor-Komfort und Strukturklarheit. Mit 13.4 ist der Trade-off neu balanciert. Die TCA-Definition eines Containers liest sich heute exemplarisch so:

<?php
return [
    'ctrl' => [
        'title' => 'LLL:EXT:my_site/Resources/Private/Language/locallang.xlf:hero_container',
        'label' => 'header',
        'iconfile' => 'EXT:my_site/Resources/Public/Icons/hero.svg',
    ],
    'columns' => [
        'background_variant' => [
            'config' => [
                'type' => 'select',
                'renderType' => 'selectSingle',
                'items' => [
                    ['label' => 'Hell', 'value' => 'light'],
                    ['label' => 'Dunkel', 'value' => 'dark'],
                ],
            ],
        ],
    ],
    'containerConfiguration' => [
        'columns' => [
            ['name' => 'Hauptbereich', 'colPos' => 200],
            ['name' => 'Seitenbereich', 'colPos' => 201],
        ],
    ],
];

Die containerConfiguration ist der neue, native Konfigurationspunkt. Sie ersetzt in der Migration den Code, der vorher in der b13-Extension lebte, und integriert sich sauber in die TCA-Mechanik des Cores. Wer aus 12.4 mit b13-Container migriert, hat einen klaren Pfad — der Migrationsleitfaden im TYPO3-Wiki dokumentiert die Schritte detailliert. Die häufigste Stolperfalle ist die Konvertierung der bestehenden tt_content-Datensätze, deren colPos-Verweise auf den neuen Container-Mechanismus umzustellen sind. Die mitgelieferten Upgrade-Wizards decken den Standardfall ab; für nicht-standardisierte b13-Konfigurationen ist Handarbeit nötig.

In der Agenturpraxis wird das CCES bisher uneinheitlich angenommen. Die Häuser, die seit Jahren auf Bootstrap Package und Mask aufsetzen, haben den Container-Ansatz teilweise übernommen, teilweise — mit guten Gründen — bei ihren etablierten Strukturen belassen. Mask in Kombination mit Bootstrap Package ist ein robustes, in vielen Projekten produktiv laufendes Muster, das mit 13.4 keinen unmittelbaren Migrationsdruck erzeugt. Wer neu in TYPO3 einsteigt, baut heute aber typischerweise direkt auf CCES auf.

Webhook-Architektur als Brückenschlag zum Headless-Ökosystem

Das zweite tragende Feature von 13.4 ist die im Core integrierte Webhook-Architektur. TYPO3 versendet seit 13.0 Webhook-Events bei einer Reihe vordefinierter Trigger — Änderungen an Pages, Content-Elementen, FrontendUsern, Site-Konfigurationen — an konfigurierbare Endpunkte. Die zugrundeliegende Implementation nutzt PSR-14-Events und die TYPO3-eigene Webhook-Engine, die mit 13.4 um Retry-Logik und Signatur-Validierung erweitert wurde.

Die Konfiguration erfolgt deklarativ in YAML-Files unterhalb von Configuration/Webhooks/:

webhooks:
  my-site:
    page-update:
      url: 'https://frontend.example.com/api/revalidate'
      method: POST
      events:
        - 'TYPO3\CMS\Core\Page\Event\AfterPageWithRootLineIsResolvedEvent'
      headers:
        X-Webhook-Secret: '%env(WEBHOOK_SECRET)%'
      retryStrategy:
        maxAttempts: 5
        backoffMs: 500

Die praktische Relevanz für DACH-Mittelstandsprojekte ist die Brücke zu entkoppelten Frontend-Stacks. Wer TYPO3 als Content-Backend für ein Astro-, Next- oder Nuxt-Frontend betreibt, hatte bis 12.4 die Wahl zwischen Polling, manuellen Cache-Invalidations via Custom-Code oder dem Einsatz von Drittanbieter-Tools wie der mfc/typo3-webhooks-Extension. Mit 13.4 ist die ISR/On-Demand-Revalidierung über Next.js 15 oder Astro 5 nativ machbar — der Webhook löst die Revalidierung aus, das Frontend zieht den neuen Content, der Cache ist konsistent.

In der Praxis sind die Webhook-Implementierungen, die ich in DACH-Projekten gesehen habe, fast durchweg pragmatisch: Sie nutzen die Core-Webhooks nicht für vollständige Headless-Architekturen, sondern für punktuelle Integrationen — CRM-Synchronisation bei Newsletter-Anmeldungen, Algolia-Index-Updates bei Content-Änderungen, Trigger für Build-Pipelines bei strukturellen Page-Tree-Änderungen. Der vollständige Headless-Use-Case bleibt eine Minderheit, was wenig mit 13.4 und viel mit dem typischen TYPO3-Adoptions-Profil zu tun hat.

Site Sets — die strukturelle Konsolidierung der Site-Composition

Die dritte tragende Neuerung sind die Site Sets, die mit 13.1 eingeführt und mit 13.4 stabilisiert wurden. Sie sind die saubere, deklarative Antwort auf das jahrealte Problem der TypoScript-Komposition: Wie kombiniere ich generische Module (Header, Footer, News-Listing) mit projektspezifischen Site-Overrides, ohne in der TypoScript-Vererbung zu ertrinken?

Ein Site Set ist eine deklarative Einheit aus TypoScript, TSconfig, YAML-Konfiguration und PHP-Service-Definitionen, die als Paket aktiviert oder deaktiviert wird. Die Site-Konfiguration referenziert die benötigten Sets über eine Liste, die Reihenfolge bestimmt die Override-Reihenfolge:

dependencies:
  - typo3/fluid-styled-content
  - bootstrap-package/contentelements
  - my-vendor/corporate-design
  - my-vendor/site-specific-overrides

Die Wirkung in der Agenturpraxis ist überraschend deutlich. Wer 15 ähnliche Konzern-Tochterseiten betreibt — typischer Anwendungsfall für mittelständische Industrieholdings im DACH-Raum — kann die gemeinsame Basis in ein zentrales Site Set extrahieren und die individuellen Overrides als dünne, projekt-spezifische Sets hinzufügen. Die Praxis-Vorteile: weniger duplizierter TypoScript-Code, klarere Override-Pfade, sauberere Onboarding-Geschichten für neue Entwickler.

Die größte Adoptionsbarriere ist nicht die Technik, sondern die Refactoring-Investition. Wer eine bestehende Multi-Site-Installation mit gewachsenen TypoScript-Hierarchien hat, muss die Reorganisation als eigenes Vorhaben planen — sie kommt nicht beiläufig im Upgrade-Wizard mit. In Projekten, die ich 2025 begleitet habe, war die typische Entscheidung: 13.4-Upgrade durchziehen, Site Sets als Folge-Projekt für 2026 oder 2027 einplanen.

Migration aus 12.4 — die nüchterne Bilanz

Die Migration von 12.4 auf 13.4 ist die am besten dokumentierte TYPO3-Major-Migration der letzten Jahre. Der upgrade:run-Befehl mit den eingebauten Wizards deckt den Standardfall ab, der extension scanner identifiziert Code-Inkompatibilitäten in Custom-Extensions, die make:upgrade-Helfer im TYPO3-Console-Paket erleichtern die wiederkehrenden Refactoring-Schritte.

Die wesentlichen Brüche zwischen 12.4 und 13.4:

PHP-Anforderungen: TYPO3 13.4 verlangt mindestens PHP 8.2, optimal ist PHP 8.3 oder 8.4. Wer auf 12.4 mit PHP 8.1 lief, muss zuerst die PHP-Version heben. In DACH-Hosting-Konstellationen — typische Mittelstand-Hoster wie Mittwald, Hetzner, Hostsharing oder dedizierte Konzern-Infrastrukturen — ist PHP 8.3 mittlerweile Standard, PHP 8.4 weitgehend verfügbar.

Symfony-Komponenten: Die unter 12.4 verwendeten Symfony-6.x-Komponenten sind in 13.4 auf Symfony 7.x gehoben. Custom-Extensions, die direkt gegen Symfony-Klassen entwickelt sind (was selten ist, aber vorkommt), brauchen Anpassungen — vor allem bei DI-Container-Konfigurationen und Console-Commands.

TCA-Bereinigungen: Eine Reihe von TCA-Konfigurationsoptionen ist deprecated oder entfernt. Der Extension-Scanner findet die meisten Fundstellen automatisch; eine Handvoll bleibt für manuelle Prüfung.

Fluid-Anpassungen: Die Fluid-Templating-Engine hat in 13.x einige Breaking Changes bei ViewHelpern erlebt. Wer Custom-ViewHelper pflegt, prüft die Kompatibilität. Die häufigste Stolperfalle sind ViewHelper, die mit deprecated initializeArgumentsMethoden arbeiten.

In der Bilanz: Eine sauber strukturierte 12.4-Installation lässt sich in zwei bis fünf Personentagen auf 13.4 heben. Eine über Jahre gewachsene Installation mit umfangreichen Custom-Extensions und nicht aktuell gehaltenen Drittanbieter-Extensions kann in den zweistelligen Personentage-Bereich rutschen. Die Mehrheit der DACH-Projekte liegt erfahrungsgemäß im einstelligen Bereich.

Die kritische DACH-Adoptions-Bilanz

Achtzehn Monate nach Release-Datum: Wo steht TYPO3 13.4 im DACH-Markt?

Die Agenturlandschaft hat 13.4 mehrheitlich akzeptiert, aber nicht euphorisch begrüßt. Die größeren TYPO3-Häuser — die etablierten Agenturen im Verband der deutschen TYPO3-Agenturen — haben 13.4 in ihre Standard-Stacks aufgenommen, Neuprojekte werden seit Frühjahr 2025 mehrheitlich auf 13.4 ausgeliefert. Die Bestandskunden-Migration läuft selektiver, vor allem dort, wo das 12.4-System produktiv und stabil läuft und kein akuter Anlass besteht.

Die mittelständischen Endkunden — Industrieunternehmen, Hochschulen, Verwaltungen, Verbände — sind die schwerere Adoptionszielgruppe. Hier gilt die TYPO3-typische Konstellation: TYPO3 ist die etablierte CMS-Wahl, das Vertrauen in die LTS-Wartung ist hoch, der Innovationsdruck gering. Eine Migration von 12.4 auf 13.4 ist keine strategische Entscheidung, sondern eine planbare Routinemaßnahme — und die wird oft an das Ende des 12.4-Support-Fensters (April 2026) geschoben.

Die Folge: Im Mai 2026 sind viele Migrationen erst jetzt in der heißen Phase. Die Welle der Last-Minute-Migrationen, die in den vergangenen LTS-Zyklen typisch war, wiederholt sich. Wer als Agentur Kapazitäten hat, kann die nächsten Quartale gut auslasten.

Internationaler Vergleich

Im internationalen Vergleich bleibt TYPO3 das, was es seit der 4.x-Linie ist: ein im DACH-Markt dominantes, international nischenhaftes Enterprise-CMS mit klarer technischer und kultureller Verortung. Der US-Markt wird weiterhin von WordPress dominiert (rund 43 Prozent globaler CMS-Marktanteil nach W3Techs-Erhebungen), gefolgt von einer mittleren Schicht aus Shopify, Wix und Squarespace; Enterprise-CMS-Sucher greifen dort eher zu Sitecore oder Adobe Experience Manager als zu TYPO3.

Drupal — mit Drupal 11 im August 2024 und dem Drupal-7-EOL im Januar 2025 in einer eigenen Konsolidierungsphase — ist die nähere internationale Vergleichsgröße. Beide Systeme teilen die PHP-Basis, beide leben von einer Open-Source-Community mit hoher Beteiligungsdichte, beide adressieren Enterprise-Anforderungen. Die strukturellen Unterschiede bleiben: TYPO3 hat ein stärker integriertes Editorial-Erlebnis und einen klareren LTS-Pfad, Drupal hat das größere internationale Ökosystem und die längeren Innovations-Sprünge.

Im DACH-Mittelstand bleibt TYPO3 für die nächsten Jahre die führende Wahl für Mittelstands- und Hochschul-Sites. Die Frage nach Headless-Architekturen, die seit 2020 in der Branche kursiert, hat sich pragmatisch beantwortet: Wer ein bestehendes TYPO3 hat und Headless-Frontend will, baut die Brücke über Webhooks und APIs. Wer neu plant, prüft ernsthaft den Einsatz eines reinen Headless-CMS — und entscheidet sich in der Mehrzahl der Mittelstands-Fälle weiterhin für TYPO3, weil das Gesamtpaket aus Editorial-Erlebnis, LTS-Versprechen und DACH-Agenturlandschaft das robustere Angebot ist.

Was bis 13.5 und darüber hinaus zu erwarten ist

Die TYPO3-Roadmap weist für die zweite Hälfte 2026 keine spektakulären Sprünge aus. 13.4 ist das LTS, die Wartung läuft. Die Sprint-Releases der 14.x-Linie werden voraussichtlich ab Frühjahr 2027 sichtbar, das 14.x-LTS wird traditionell auf Herbst 2028 datiert.

Die größeren Diskussionen in der Community drehen sich um drei Felder: erstens die Headless-API-Standardisierung (eine in der Core-Diskussion befindliche, vollständig REST-konforme Content-API als Ergänzung zur bestehenden Headless-Extension); zweitens die KI-Integration auf Editorial-Ebene (Übersetzungs-Workflows, Content-Vorschläge, Bildbeschreibungs-Automatisierung); drittens die Performance-Optimierung auf TYPO3-Frontend-Ebene mit Web-Vitals-Awareness — LCP unter 2,5 Sekunden, INP unter 200 Millisekunden, CLS unter 0,1 sind die 2026er-Standards, die TYPO3-Standard-Templates nicht durchgängig erreichen.

Für die Agentur- und Hauspraxis bedeutet das: 13.4 ist die stabile Basis für die nächsten zwei bis drei Jahre. Wer jetzt migriert, ist bis April 2027 sicher und kann das ELTS-Programm für die Verlängerung bis 2030 prüfen. Wer ein 12.4-Projekt im Mai 2026 noch produktiv betreibt, hat genau diesen Sommer für die Planung — die Migration auf 13.4 ist 2026 die strategisch richtige Investition.