KISS-Prinzip in der TYPO3-Entwicklung: Warum einfacher besser ist
Extensions sind kein Beiwerk — sie sind Verantwortung
Jede Extension, die auf einer TYPO3-Installation läuft, ist Code, den CWD nicht entwickelt hat. Das klingt nach einer Selbstverständlichkeit, hat aber praktische Konsequenzen: Sicherheitslücken werden von Drittentwicklern gepatcht — oder eben nicht. Kompatibilitätsprobleme tauchen beim nächsten Major-Release auf und blockieren das Update, das seit Monaten geplant war. Und im ungünstigsten Fall ist die Person, die die Extension ursprünglich gebaut hat, seit Jahren nicht mehr im Projekt — keine Tickets, kein Repository, kein Ansprechpartner.
CWD folgt daher einem Grundsatz: so wenige Extensions wie möglich, und jede, die im Einsatz ist, muss nachweislich gepflegt sein.
Kein Prinzipienreiten. Es ist eine Abwägung, die wir bei jedem Projekt neu treffen: Was leistet eine Extension, wie gut wird sie gewartet, und gibt es eine Alternative mit weniger Risiko. Projekte, die über Jahre gewachsen sind, haben oft einen Extension-Stack, den niemand mehr vollständig überblickt. Der Pflege-Check gehört daher nicht nur in die Projektübernahme, sondern in jede größere Update-Runde.
Drei Typen, drei Risikoklassen
Nicht jede Extension ist gleich riskant. Ein erster Schritt in der Bewertung ist die Einordnung nach Herkunft und Pflegestand.
Core-nahe und Community-Extensions
Extensions, die vom TYPO3-Kernteam oder von namhaften TYPO3-Agenturen gepflegt werden, folgen typischerweise dem Release-Zyklus des CMS: Kompatibilität zur aktuellen LTS ist dokumentiert, der Quellcode ist öffentlich einsehbar, Issues werden bearbeitet. Das ist die sicherste Klasse — nicht weil Fehler ausgeschlossen wären, sondern weil eine erkennbare Entwicklungsverantwortung existiert, die auch nach einem Versionswechsel trägt.
Community-Extensions sind heterogener. Manche werden seit Jahren mit hoher Disziplin gepflegt, andere haben seit zwei LTS-Versionen keinen Commit gesehen. Das TYPO3 Extension Repository zeigt das Datum des letzten Updates: Das ist der erste Blick, den wir werfen. Der zweite geht auf das zugehörige Git-Repository: Wie viele offene Issues gibt es? Wer reagiert auf Pull Requests, und in welchem Zeitraum? Gibt es eine Dokumentation für die aktuelle TYPO3-Version, oder ist die README seit Jahren unverändert?
Eine Community-Extension, die diese Fragen nicht beantworten kann, ist ein Kandidat für die Ablösung — unabhängig davon, wie reibungslos sie heute noch läuft.
Proprietäre Extensions
Extensions mit geschlossenem Quellcode stellen CWD vor ein strukturelles Problem. Im Fehlerfall können wir nicht selbst eingreifen: Wir sind auf die Reaktionszeiten und Priorisierung des Herstellers angewiesen, die sich nicht kontrollieren lassen. Dazu kommt Vendor-Lock-in: Ein Wechsel bedeutet Datenmigration und Konfigurationsaufwand, dessen Umfang sich von außen schwer beziffern lässt.
Das schließt proprietäre Extensions nicht aus. Es gibt Fälle, in denen eine spezifische Funktion nur so verfügbar ist und der Einsatz begründbar ist. Das erfordert eine bewusste Entscheidung, keine Standardwahl.
Wann eine Extension ihren Platz verliert
Drei Situationen machen einen Weiterbetrieb nicht mehr vertretbar.
Erste: die Extension ist nicht mehr gepflegt. Die letzte Version ist zwei oder mehr LTS-Zyklen alt, das Repository reagiert nicht auf Issues, eine Kompatibilitätsaussage für die aktuelle TYPO3-Version fehlt. Die Extension funktioniert heute — aber beim nächsten Update kann das kippen, ohne dass eine Lösung absehbar ist.
Zweite: bekannte Sicherheitslücken. TYPO3 veröffentlicht Security Bulletins auch für Extensions im offiziellen Repository. Wenn eine bekannte Lücke existiert und kein Patch in Sicht ist, ist der Weiterbetrieb nicht akzeptabel, unabhängig davon, wie aufwendig der Wechsel sein wird.
Dritte: die Extension blockiert ein Major-Update. Das ist in der Praxis der häufigste Grund. Nicht eine dramatische Sicherheitslücke, sondern das schleichende Veralten einer Extension, die niemand mehr anfasst, sodass das gesamte System auf einem veralteten TYPO3-Stand festhängt und jedes weitere Update verschoben wird.
Der Ersatz hat Vorrang — nicht der Aufwand
Wenn eine Extension aussortiert werden soll, ist die erste Frage nicht „Was kostet der Wechsel?", sondern: Brauchen wir das überhaupt noch als Extension?
TYPO3 hat mit jedem Major-Update Funktionen in den Core übernommen, die früher nur über Drittanbieter-Extensions verfügbar waren. Formular-Handling, SEO-Metafelder, Redirect-Verwaltung: Das ist heute Core-Funktionalität. TYPO3 hat seinen Funktionsumfang in vielen Bereichen erheblich ausgebaut. Der erste Schritt ist deshalb immer: prüfen, ob das gewünschte Verhalten ohne Extension abbildbar ist. Die Antwort ist häufiger Ja als erwartet, besonders nach einem Versions-Upgrade.
Ist das nicht möglich, suchen wir nach gepflegten Alternativen im Extension Repository, gemessen an denselben Kriterien: Aktualität, Repository-Aktivität, Kompatibilität. Eine Extension, die die Funktion abbildet, aber selbst schlecht gepflegt ist, löst das Problem nicht. Sie verschiebt es.
Als letzter Schritt steht die eigene Lösung: eine schlanke, projektspezifische Extension, die genau das tut, was benötigt wird. Nicht mehr. Der Entwicklungsaufwand ist höher, aber der Code liegt unter CWDs Kontrolle — das heißt: Updates, Anpassungen und Migrationen ohne Abhängigkeit von externer Release-Planung.
Das KISS-Prinzip greift hier auf zwei Ebenen gleichzeitig: technisch und wirtschaftlich. Zehn Extensions zu pflegen, die jeweils ein kleines Problem lösen, erzeugt einen Pflegeaufwand, der sich über Projektjahre summiert: jede Sicherheitsprüfung, jedes Kompatibilitäts-Update, jede Abhängigkeit vor dem nächsten Major-Release. Wer weniger verbaut, hat weniger zu aktualisieren, weniger zu prüfen, weniger zu migrieren.
Aufwand gehört ins Angebot
Ein Extension-Wechsel kostet Zeit, und Zeit kostet Geld. Das ist eine Einschränkung, die sich nicht wegdiskutieren lässt.
CWD benennt diesen Aufwand im Angebot explizit: Welche Extensions sind betroffen, was ist die empfohlene Lösung, was kostet der Wechsel — und welche Risiken entstehen, wenn nichts passiert. Kunden sollen nicht im Nachhinein mit einem unerwarteten Posten konfrontiert werden, sondern vorab entscheiden können, ob und wann sie handeln wollen.
Das gehört zur Projektverantwortung: Wer eine TYPO3-Installation langfristig betreut, muss den Extension-Stack kennen und beurteilen können. Ein Update, das an einer ungepflegten Extension scheitert, schadet mehr als die Kosten einer rechtzeitigen Ablösung. Die Entscheidung dafür liegt beim Kunden — die Grundlage dafür liefern wir.
