Matthias Gläßner – Senior TYPO3 Architekt

Erweiterungen · Architektur · Qualität & Wartbarkeit

TYPO3 Extensions: Welche Erweiterungen wirklich sinnvoll sind
– und wie Sie Ihren Extension-Zoo in den Griff bekommen

In vielen TYPO3-Systemen haben sich über Jahre dutzende Extensions angesammelt: alte TER-Pakete, Agentur-Plugins, halbfertige Eigenentwicklungen – oft kaum dokumentiert. Die Folge sind Upgrade-Schmerzen, Sicherheitsrisiken und fragile Deployments. Diese Seite zeigt, wie Sie Extensions strategisch einsetzen: wann Standard-Extensions sinnvoll sind, wann sich Eigenentwicklungen lohnen und nach welchen Kriterien Sie auswählen.

Content- & Struktur-Check nutzen Extension-Setup kurz besprechen
Fokus: TYPO3 v10–v13, Enterprise- & Behördenprojekte Für IT, Agenturen & Fachbereiche Strategie statt „wir installieren mal noch eine Extension“

Warum „einfach noch eine Extension“ selten eine gute Idee ist

TYPO3 macht es leicht, Funktionen per Extension nachzurüsten – das ist einer der großen Vorteile des Systems. Gleichzeitig sind Extensions einer der häufigsten Gründe für:

  • • Upgrade-Probleme (veraltete / inkompatible Erweiterungen)
  • • Sicherheitsrisiken (nicht gepflegte TER- oder Drittanbieter-Extensions)
  • • Performance-Einbrüche (schlecht optimierte Queries, Caching-Probleme)
  • • Komplexität im Deployment und Testing

Die wichtigste Erkenntnis lautet daher: Weniger ist mehr. Ein bewusst kuratiertes Set von Extensions ist fast immer wartbarer und sicherer als ein historisch gewachsener „Extension-Zoo“ – auch wenn letzterer auf den ersten Blick „mehr kann“.

Sinnvolle TYPO3-Extension-Kategorien – und worauf Sie achten sollten

Statt eine Liste „der besten Extensions“ aufzuzählen, ist es hilfreicher, in Kategorien und Aufgaben zu denken. Einige Bereiche, in denen Extensions häufig zum Einsatz kommen:

1. Content & Listen (News, Events, Blogs …)

Klassische Anwendungsfälle: News, Pressemitteilungen, Veranstaltungen, Fachartikel, Blogs. Hier gibt es etablierte Lösungen, aber auch viel „historischen Ballast“.

  • • Nutzen Sie wenige, flexible Basis-Domänen, statt für jeden Inhaltstyp eine neue Extension.
  • • Achten Sie auf saubere Domain-Modelle und Filter-/Listen-Logik.
  • • Planen Sie frühzeitig Mehrsprachigkeit und URL-Struktur mit ein.

2. Formulare & Interaktionen

Formulare sind oft die wichtigste Kontaktfläche zu Nutzer:innen – und gleichzeitig kritisch für Datenschutz & Security.

  • • Prüfen Sie, ob das TYPO3-Formframework Ihre Anforderungen abdeckt.
  • • Externe Extensions nur dann, wenn es wirklich komplexe Anforderungen gibt (Workflows, CRM-Integration).
  • • Achten Sie auf Logging, Double-Opt-In, DSGVO und Spam-Schutz.

3. Suche, Filter & Navigation

Die Suche ist ein eigenes Thema – oft mit Solr/Elastic und spezifischen Extensions. Auch Filter- und Facetten-Logik wird meist per Extension umgesetzt.

  • • Setzen Sie auf bewährte Integrationen, statt die Suchlogik komplett neu zu erfinden.
  • • Trennen Sie Index-Logik, Relevanz und Ausgabe klar voneinander.
  • • Ergänzen Sie das Ganze um Monitoring & Search-Checks.

4. Integrationen & Schnittstellen

Für CRM, ERP, Payment, externe Datenquellen usw. sind Extensions oft Integrationshüllen um REST-/SOAP-APIs.

  • • Bündeln Sie Integrationen in klar abgegrenzten Extensions (z. B. Vendor-Schnittstelle, Import-Jobs).
  • • Vermeiden Sie „API-Aufrufe direkt im Template“ – das rächt sich beim Upgrade.
  • • Planen Sie Retry-Logik, Logging und Monitoring mit ein.

Wichtig: Es gibt kein universelles Set an Extensions, das für jedes Projekt passt. Entscheidend ist, dass Sie eine bewusste Auswahl treffen und die Erweiterungen in eine Gesamtarchitektur einbetten.

Auswahlkriterien: Woran Sie gute TYPO3 Extensions erkennen

Ob TER-Extension, Packagist-Paket oder Eigenentwicklung: einige Kriterien helfen, Qualität und Wartbarkeit realistisch einzuschätzen:

Technische Kriterien

  • • Kompatibilität mit aktuellen TYPO3-Versionen (v12/v13).
  • • Nutzung von Extbase/Fluid bzw. modernen APIs statt Legacy-Patterns.
  • • Kein wildes „Core-Hooking“ an allen Stellen – stattdessen klar definierte Integrationspunkte.
  • • Sinnvolle Tests (Unit/Functional), Coding-Standards, Namespaces.
  • • Composer-fähig, sauberer Autoloading-Namespace.

Organisatorische Kriterien

  • • Aktive Pflege / Releases in den letzten 12–18 Monaten.
  • • Klare Maintainer / Vendor – idealerweise kein „One-Man-Fork ohne Kontaktinfos“.
  • • Lizenzklarheit (Open Source, kommerzielle Lizenz, Support-Optionen).

Fachliche & UX-Kriterien

  • • Gute Backend-UX für Redaktionen – verständliche Labels, sinnvolle Defaults.
  • • Flexibles Templating (Fluid, Partial-Overrides, Konfigurierbarkeit).
  • • Klar dokumentierte Konfigurationsoptionen.
  • • Unterstützung für Mehrsprachigkeit, SEO (URLs, Meta-Daten), Berechtigungen.

Strategische Kriterien

  • • Passt die Extension in Ihre Architektur- & Content-Strategie?
  • • Verhindert sie spätere Migrationen (z. B. proprietäre Datensilos)?
  • • Gibt es eine plausible Migrations-Story, falls Sie später wechseln?

In vielen Projekten lohnt es sich, diese Kriterien im Rahmen eines kurzen Extension-Reviews systematisch durchzugehen – z. B. im Vorfeld eines Upgrades oder Relaunches.

Standard-Extension oder Eigenentwicklung? – Eine pragmatische Abwägung

Die zentrale Frage lautet oft: Sollen wir eine vorhandene Extension nutzen oder etwas Eigenes entwickeln? Eine pragmatische, häufig sinnvolle Entscheidungsmatrix:

Wann Standard-Extensions sinnvoll sind

  • • Es geht um Standardprobleme (Content-Listen, einfache Formulare, Basis-Suche).
  • • Es gibt etablierte, gepflegte Pakete, die Ihren Anforderungen nah kommen.
  • • Sie profitieren von Updates & Bugfixes aus der Community.
  • • Ihre individuellen Anforderungen lassen sich über Konfiguration / Hooks abbilden.

Wann sich Eigenentwicklungen lohnen

  • • Sie haben stark domänenspezifische Logik (Branchen-Workflows, Fachprozesse).
  • • Kein Standardpaket passt wirklich – alles wäre ein Kompromiss.
  • • Sie benötigen klare Ownership und langfristige Erweiterbarkeit.
  • • Sie wollen Abhängigkeiten von Drittanbietern bewusst minimieren.

In vielen Enterprise-Setups ist die Kombination ideal: ein schlanker Kern aus gut ausgewählten Standard-Extensions plus einige sauber designte Eigenentwicklungen für Ihre fachlichen Besonderheiten. Entscheidend ist eine klare Architektur – nicht die Anzahl der Pakete.

Praxisbeispiele: Wie ein bewusstes Extension-Setup Projekte stabiler macht

Aus anonymisierten Projekten (Behörden, Verbände, Mittelstand) lassen sich einige Muster ableiten:

Behördenportal · Extension-Reduktion vor Upgrade

Ausgangslage: > 60 Extensions, Upgrade auf v12 geplant. Nach Audit und Bereinigung: Reduktion auf ~30 Extensions, Zusammenführung ähnlicher Funktionalitäten, klare Trennung von Domain-Logik & Integrationen. Ergebnis: Upgrade wurde planbarer, weniger Überraschungen.

Verband · Eigenentwicklung statt Fork-Wildwuchs

Ausgangslage: Mehrere Forks derselben Basis-Extension für leicht unterschiedliche Use Cases. Lösung: Konsolidierung in eine saubere Domain-Extension mit Konfiguration und Rollenmodell. Ergebnis: Weniger Pflegeaufwand, klarer Upgrade-Pfad.

Industrie · Schnittstellen in eigene Layer ausgelagert

Ausgangslage: API-Aufrufe direkt in Plugins & Templates verteilt. Nach einer Reorganisation: zentralisierte Schnittstellen-Extensions, Scheduler-Jobs, Monitoring. Ergebnis: Stabilere Integrationen, weniger Seiteneffekte bei Änderungen.

Häufige Fragen zu TYPO3 Extensions & Empfehlungen

Einige Fragen tauchen in Workshops und Audits mit IT, Agenturen und Fachbereichen immer wieder auf:

Gibt es eine Liste „der besten Extensions“, die wir einfach übernehmen können? ›
Eine pauschale Liste ist in der Praxis wenig hilfreich, weil Use Case, Branche und Architektur stark variieren. Sinnvoller ist es, pro Projekt eine kurze Architekturskizze zu erstellen und daran entlang zu entscheiden, welche Basis-Extensions und welche Eigenentwicklungen passen. In Audits dokumentiere ich typischerweise ein „empfohlenes Kernset“ je System – statt generische Listen zu pflegen.
Wie viele Extensions sind „zu viele“ für ein TYPO3-System? ›
Die absolute Zahl ist weniger relevant als die Qualität und Struktur. Eine Multidomain-Plattform mit 40 gut gepflegten, klar getrennten Extensions kann deutlich wartbarer sein als eine kleinere Site mit 15 „wilden“ Paketen. Spätestens ab ~30 Extensions lohnt sich aber ein Blick darauf, ob sich Funktionalitäten zusammenlegen oder vereinfachen lassen.
Sollten wir alte Extensions ersetzen, wenn sie „noch funktionieren“? ›
„Funktioniert noch“ ist nur ein Kriterium. Genauso wichtig sind Security, Wartbarkeit, Upgrade-Fähigkeit und Performance. In vielen Projekten arbeite ich mit einer Risikomatrix: Welche Extensions sind kritisch für Betrieb oder Security? Diese Kandidaten sollten frühzeitig modernisiert oder ersetzt werden – idealerweise im Rahmen eines Audits.
Wie dokumentieren wir sinnvoll, welche Extension was macht? ›
Bewährt hat sich ein kurzer Extension-Katalog je System: Name, Zweck, Verantwortliche:r, Kritikalität, Besonderheiten (z. B. Schnittstellen, Migrationsaufwand). Das muss kein 50-seitiges Dokument sein – oft reichen 1–2 Seiten oder ein gepflegtes Markdown/Confluence-Doc, das im Rahmen von Upgrades und größeren Änderungen aktualisiert wird.

Sie möchten Ihren Extension-Zoo entschlacken?

Ob Upgrade, Relaunch oder Security-Fragen – ein bewusstes Extension-Setup macht Ihr TYPO3-System wartbarer, sicherer und upgrade-fähiger. In einem kurzen Erstgespräch klären wir, wie Ihr aktuelles Setup aussieht und welches Vorgehen sinnvoll ist: Audit, Refactoring oder gezielter Ersatz kritischer Extensions.

Audit & Extension-Review ansehen Upgrade-Check durchführen Kurz Ihr Setup besprechen