TYPO3-Extensions Eigene entwickeln oder fertige aus dem TER

TYPO3 ist selbst aus Extensions aufgebaut. Seitenverwaltung, Formulare, Login und SEO-Funktionen stecken in Systemextensions, die mit dem Core ausgeliefert werden. Alles Weitere kommt über zusätzliche Extensions dazu, im deutschen Sprachgebrauch auch Erweiterungen genannt.

Eine Extension ist dabei das Paket. Mitbringen kann sie Plugins und Inhaltselemente, die etwas auf der Website ausgeben, eigene Datensätze wie Stellenanzeigen oder Termine, Aufgaben für den Scheduler, Schnittstellen zu anderen Systemen und Backend-Module. Ein Modul ist ein eigener Bereich im TYPO3-Backend, etwa eine Auswertung, ein Import oder eine Übersicht für die Redaktion. Wer nach einem „TYPO3-Modul“ sucht, sucht deshalb meistens eine Extension, die ein solches Modul enthält.

Die erste Anlaufstelle ist das TYPO3 Extension Repository, kurz TER, unter extensions.typo3.org. Jede Extension hat dort eine eigene Seite mit den unterstützten TYPO3-Versionen, der Versionshistorie und unter „Composer support“ dem Befehl für die Installation.

Daneben gibt es Packagist, das zentrale Verzeichnis für Composer-Pakete. TYPO3-Extensions sind dort als Pakettyp typo3-cms-extension gekennzeichnet. Seit TYPO3 14 braucht jede Extension eine gültige composer.json, auch in Installationen ohne Composer. Für neue Installationen empfiehlt TYPO3 Composer, und dort lässt sich eine Extension ohne Paket auf Packagist nur über Umwege einbinden.

Hinter vielen Extensions steht zusätzlich ein Repository auf GitHub oder GitLab. Ein Blick in die offenen Issues, die letzten Commits und die Diskussionen dort zeigt oft mehr über den Zustand einer Extension als ihre Beschreibung im TER.

Kompatibilität mit Ihrer LTS-Version. Aktuell ist TYPO3 14 die LTS-Version für neue Projekte, TYPO3 13 erhält noch bis Ende 2027 kostenlose Updates. Eine Extension sollte die Version unterstützen, die bei Ihnen läuft, und idealerweise auch schon die nächste. Verlässlicher als die Angabe im TER ist die Versionsbedingung in der composer.json, denn nach ihr richtet sich Composer bei der Installation.

Pflege und Releases. Bei einer gepflegten Extension kommen regelmäßig neue Versionen, vor allem kurz nach dem Erscheinen einer neuen TYPO3-Version. Liegt das letzte Release mehrere Jahre zurück, wird das nächste Upgrade sehr wahrscheinlich an dieser Extension hängen. Auch der Status zählt: Versionen mit dem Status „alpha“ oder „obsolete“ gehören laut TYPO3-Dokumentation nicht auf eine Live-Website.

Maintainer. Betreut wird eine Extension von einer Person, einer Agentur oder einer Gruppe aus der Community. Extensions, die eine Agentur in ihren eigenen Projekten einsetzt oder die von mehreren Leuten betreut werden, haben meist einen längeren Atem als ein einmal veröffentlichtes Nebenprojekt.

Abhängigkeiten. Jede Extension bringt ihre eigenen Abhängigkeiten mit, andere Extensions ebenso wie PHP-Bibliotheken. All das muss beim nächsten Upgrade mitziehen. Eine schlanke Extension, die genau Ihre Aufgabe erfüllt, fährt deshalb meist besser als eine große, von der Sie nur einen kleinen Teil nutzen.

Sicherheitshinweise. Das TYPO3 Security Team veröffentlicht Sicherheitslücken in Extensions als Security Bulletins mit der Kennung TYPO3-EXT-SA und einer laufenden Nummer. Ein früheres Bulletin ist kein Ausschlusskriterium. Entscheidend ist, wie schnell und sauber der Fix kam. Liefert eine Autorin oder ein Autor keine Korrektur, entfernt das Team die betroffenen Versionen aus dem TER und empfiehlt im Bulletin, die Extension zu deinstallieren. Eine allgemeine Sicherheitsprüfung aller Extensions findet dagegen nicht statt.

Dokumentation. Eine Anleitung auf docs.typo3.org oder im Repository, ein gepflegtes Changelog und Hinweise zu Upgrades zwischen den Versionen sparen später viel Zeit. Sie zeigen außerdem, wie ernst die Extension gemeint ist.

Für Aufgaben, die viele Websites gleich haben, ist eine verbreitete Extension fast immer die bessere Wahl: News, Volltextsuche, Formulare, Weiterleitungen oder ein geschützter Bereich für Kundinnen, Kunden und Mitarbeitende. Weil eine solche Extension auf vielen Installationen läuft, fallen Fehler schneller auf, und den Aufwand für neue TYPO3-Versionen tragen viele gemeinsam.

Ein Intranet oder Extranet ist dafür ein gutes Beispiel. Frontend-Benutzer und -Gruppen, das Login und Zugriffsrechte auf Seiten und Inhaltselemente bringt TYPO3 selbst mit. Für die Anmeldung über ein zentrales Verzeichnis wie LDAP gibt es fertige Extensions. Eigene Entwicklung braucht es erst für das, was es nur in Ihrem Unternehmen gibt.

Auch wenn eine fertige Extension nicht ganz passt, muss das nicht gleich eine Eigenentwicklung bedeuten. Gute Extensions lassen sich über eigene Templates, Konfiguration und Events anpassen, ohne ihren Code zu verändern. Diese Anpassungen liegen dann in Ihrer Site und überstehen Updates der Extension.

Eine eigene Extension lohnt sich, wenn die Aufgabe so nur in Ihrem Unternehmen vorkommt.

Fachlogik. Für eine Online-Bestellung von Sperrgut habe ich zwei eigene Extensions entwickelt. Die Bestellstrecke führt in vier Schritten zum Abholtermin, unterscheidet zwischen Sperrgut und Schrott und hat einen Wartungsmodus mit zwei Stufen. Für eine allgemeine Extension sind solche Abläufe zu speziell.

Eigene Datenmodelle. Für ein Theater verwaltet TYPO3 den Spielplan mit Spielzeiten, Produktionen, Vorstellungen und Personen. Die Besetzung einer einzelnen Vorstellung überschreibt dabei rollenweise die Standardbesetzung der Produktion. Ein Datenmodell mit so genauen Regeln geht über das hinaus, was eine allgemeine Event-Extension abbildet.

Schnittstellen. Dieselben beiden Projekte hängen außerdem an fremden Systemen: Termine kommen direkt aus SAP, der Spielplan aus Theasoft, die Ticketverfügbarkeit von Eventim. Jede dieser Anbindungen folgt den Regeln des jeweiligen Systems, und genau diese Regeln stecken in der eigenen Extension.

Backend-Module. Beim Mixometer pflegt der Hersteller einen Produktkatalog, den eine App abruft. Eigene Backend-Module nehmen Produktvorschläge aus der App entgegen und importieren Produktlisten, die Hersteller als Excel-Datei liefern. Die Redaktion arbeitet damit direkt in TYPO3 statt in einem zusätzlichen Werkzeug.

Ein weiteres Signal: Eine fertige Extension müsste so weit umgebaut werden, dass von ihr kaum mehr als der Name übrig bleibt. Dann tragen Sie die Wartung ohnehin selbst, nur in fremdem Code. Eine eigene, schlanke Extension ist in diesem Fall leichter zu pflegen.

Dafür liegt bei einer eigenen Extension jedes Upgrade, jede Anpassung an eine neue PHP-Version und jede Sicherheitskorrektur bei Ihnen. Das ist gut planbar, aber es ist Aufwand, der bei einer verbreiteten Extension auf viele Schultern verteilt ist.

Ob eine eigene Extension das nächste Upgrade gut übersteht, entscheidet sich bei ihrer Entwicklung.

Offizielle Schnittstellen nutzen. TYPO3 bietet für Anpassungen Events, Dependency Injection, TCA und Site-Konfiguration. Wer darüber arbeitet, bleibt innerhalb dessen, was TYPO3 über Versionen hinweg pflegt. Klassen des Core zu überschreiben, etwa per XCLASS, wirkt kurzfristig einfach, bindet die Extension aber eng an genau eine Version.

Klein und fokussiert bleiben. Eine Extension pro Aufgabe ist leichter zu verstehen, zu testen und zu aktualisieren als ein großes Paket, das alles Projektspezifische sammelt.

Sauber als Paket anlegen. Eine composer.json mit klaren Versionsbedingungen, ein eigenes Repository und nachvollziehbare Versionen machen die Extension zu einem Baustein, der sich wie jede fertige Extension installieren und aktualisieren lässt.

Deprecations früh abarbeiten. Was TYPO3 in einer Hauptversion als veraltet markiert, funktioniert bis zu deren Ende weiter und entfällt mit der nächsten. Das Deprecation-Log und der Extension Scanner im Upgrade-Modul zeigen die betroffenen Stellen. Werkzeuge wie TYPO3 Rector für PHP-Code und Fractor für TypoScript, FlexForms und Fluid übernehmen einen großen Teil der Umstellung automatisch.

Tests und statische Analyse. Automatische Tests und eine Prüfung mit PHPStan zeigen nach einem Upgrade schnell, ob alles noch so funktioniert wie vorher.

Jede LTS-Version mitnehmen. Ein Sprung über eine Version hinweg sammelt die Änderungen von zwei Hauptversionen. Wer jede LTS-Version zeitnah nachzieht, hat pro Upgrade überschaubare Schritte.

Mit Jobs habe ich selbst eine Extension im TER veröffentlicht. Sie verwaltet Stellenanzeigen als eigene Datensätze und gibt sie mit strukturierten Daten nach schema.org/JobPosting aus, die den Rich-Results-Test von Google bestehen. Stellenanzeigen braucht fast jede Unternehmenswebsite. Genau für solche Fälle lohnt sich eine fertige Extension.

Jobs bringt deshalb mit, worauf ich selbst bei fertigen Extensions achte: Installation per Composer über Packagist, Quellcode auf GitHub, das mitgelieferte Design über CSS Custom Properties anpassbar oder ganz abschaltbar. So passt die Extension sich an eine Site an, ohne dass jemand ihren Code verändern muss.

Bei einer gewachsenen TYPO3-Installation stellt sich die Frage oft rückwärts. Vor dem Upgrade steht dann eine Bestandsaufnahme der eingesetzten Extensions: welche noch gepflegt werden und wo eigener Code steckt. Daraus ergibt sich, was übernommen, was durch eine gepflegte Extension ersetzt und was neu als eigene Extension gebaut wird. Wie ich dabei vorgehe, beschreibe ich bei der TYPO3-Entwicklung.