Seit 1998 arbeiten wir mit TYPO3, und in dieser Zeit sind viele eigene Extensions entstanden. Die meisten lagen in privaten Repositories. Im Oktober 2026 haben wir die ersten drei veröffentlicht. Der Code lief längst im Alltag, trotzdem hat der Schritt nach draußen Fehler sichtbar gemacht, die vorher niemand bemerkt hatte.
Kurz gesagt
- Wir haben drei Extensions für TYPO3 13.4 LTS und 14 freigegeben: im TER, auf Packagist und auf GitHub.
- Am meisten hat uns die Vorbereitung gebracht: Sie hat Fehler aufgedeckt, die im Alltag unbemerkt geblieben waren.
- Viel Traffic bringt das nicht. Eine veröffentlichte Extension ist ein Beleg, kein Reichweitenkanal.
- Wer veröffentlicht, übernimmt die Pflege. Eine verwaiste Extension schadet mehr als gar keine.
Warum eine Agentur ihren Code öffnet
Dass wir TYPO3-Extensions entwickeln, steht auf unserer Leistungsseite. Das kann jede Agentur von sich behaupten. Prüfen lässt es sich erst, wenn der Code offen liegt. Dafür hatten wir vier Gründe:
- Beleg statt Behauptung. Wer wissen will, wie wir arbeiten, liest Code, Tests und Dokumentation selbst.
- Bessere Wiederverwendung. Ein Paket mit Versionsnummer lässt sich in jedes Projekt einbinden. Kopien in einzelnen Projekten laufen dagegen schnell auseinander.
- Höherer Anspruch. Code, den andere lesen, schreibt man sorgfältiger.
- Etwas zurückgeben. Unsere Arbeit beruht seit Jahrzehnten auf einem Open-Source-CMS und seiner Community.
Was wir veröffentlicht haben
Ausgewählt haben wir Extensions, die allgemein nützlich sind und keine Geschäftslogik von uns oder von Kunden enthalten. Module, die eng an unsere eigenen Prozesse gebunden sind, bleiben intern.
| Extension | Aufgabe | Besonderheit |
|---|---|---|
| pxe_counter | Animierte Kennzahlen | Der Endwert steht immer im HTML, das Zahlenformat folgt der Sprache der Website |
| pxe_compareslider | Vorher-Nachher-Vergleich von Bildern | Bedienbar mit Maus, Touch und Tastatur, responsive Bilder, keine Fremdbibliothek |
| pxe_composer_report | Veraltete Pakete und Sicherheitshinweise im Backend | Liest nur und ändert nichts am Projekt, läuft auch per Scheduler, Kommandozeile und E-Mail |
Alle drei stehen unter GPL-2.0-or-later. Den Code finden Sie auf GitHub.
Was dabei aufgefallen ist
Unser Plan war, Lizenz und Dokumentation zu ergänzen und die Extensions freizugeben. Es wurde deutlich mehr, weil der Code zum ersten Mal unter Bedingungen lief, die wir nicht selbst gewählt hatten.
Tests, die niemand ausführt, sind keine Tests
Die Testsuiten lagen seit Monaten im Repository. Als wir sie gegen TYPO3 13.4 starten wollten, brachen die Functional-Tests schon beim Setup ab, weil in der Konfiguration ein alter Paketname stand. PHPUnit 12 meldete außerdem „No tests found“, weil es die alten Annotationen nicht mehr kennt. Heute läuft jede Änderung automatisch durch die Tests.
Das Frontend lief, das Backend nicht
Beim Vergleichs-Slider zeigte das Bearbeitungsformular unter TYPO3 14 nur noch einen Platzhalter statt der Bildfelder. Das Frontend rendert unabhängig davon, und das Element war gerade nirgends im Einsatz, also fiel es niemandem auf. Beim Composer Report brach der Scheduler-Task ab, weil er einen Service nicht laden konnte. Beim Zähler gab es ein Feld für Nachkommastellen, doch aus 4,9 wurde beim Speichern 4. Alle drei Fehler sichern heute eigene Tests ab.
Screenshots finden, was Tests übersehen
Für die Dokumentation haben wir ein frisches TYPO3 mit Demo-Inhalten aufgesetzt und jede Ansicht als Screenshot festgehalten. Schon die ersten Bilder zeigten Mängel, die alle Tests bestanden hatten: Backend-Module ohne Kopfleiste und Abstände, eine unlesbare Kennzahl, eine verdeckte Beschriftung im vertikalen Slider. Fehler dieser Art zeigen sich erst, wenn jemand die Oberfläche ansieht wie ein neuer Nutzer.
Was wir heute anders machen
- Zwei TYPO3-Versionen, eine Codebasis. Die meisten Installationen laufen noch auf 13.4 LTS. Deshalb unterstützen wir 13.4 LTS und 14 gleichzeitig. Wo sich die Kern-APIs unterscheiden, gibt es eine gezielte Weiche. Fünf Kombinationen aus TYPO3 und PHP laufen bei jeder Änderung und einmal pro Woche automatisch durch.
- Assets nur dort, wo sie gebraucht werden. CSS und JavaScript laden nur auf Seiten mit dem Element. Für Themes, die Assets bündeln, gibt es einen Schalter.
- Datenschutz offen dokumentieren. Der Composer Report fragt externe Dienste ab. Die Dokumentation nennt genau, was wohin geht, und private Pakete lassen sich ausschließen.
- Neu anfangen statt Historie mitnehmen. Commit-Nachrichten interner Repositories erwähnen schnell Server, Projekte und Zwischenstände. Die öffentlichen Repositories haben wir deshalb mit einem frischen Stand begonnen.
- Die eigenen Pakete selbst nutzen. pixelegg.de installiert die drei Extensions wie jedes andere Projekt von Packagist. Probleme merken wir so zuerst.
Der Weg ins TER in sieben Schritten
- Code prüfen: Zugangsdaten, Kundennamen, interne Pfade und Kommentare müssen raus.
- Lizenz klären: LICENSE-Datei ergänzen und die Lizenz in der composer.json angeben.
- Repository anlegen: öffentlich, mit Links zu Issues und Quellcode in der composer.json.
- Extension Key registrieren: im TER unter „My Extensions“. Der Key lässt sich später kaum ändern, weil bestehende Inhalte daran hängen.
- Packagist anbinden: Repository einreichen, neue Tags kommen dann automatisch an.
- Release automatisieren: Ein Tag löst per GitHub Action und tailor den Upload ins TER aus. Der Upload-Kommentar erscheint dort als Klartext, Markdown aus dem Changelog wirkt deshalb unsauber.
- Dokumentation einbinden: Ein Webhook rendert den Ordner Documentation auf docs.typo3.org. Dafür muss das Repository im TER verlinkt sein.
Eine Falle für Site Sets: TYPO3 13 und 14 laden deren TypoScript nur, wenn die Root-Seite keinen sys_template-Datensatz hat. Wir dokumentieren deshalb beide Installationswege.
Was es bringt und was nicht
Reichweite bringt es kaum. Nach einzelnen Extensions wird selten gezielt gesucht, und auch das Thema TYPO3-Entwicklung ist klein. Der Nutzen liegt woanders: Wir haben einen überprüfbaren Beleg unserer Arbeit und einen Eintrag im TER. Außerdem ist der Code in unseren Kundenprojekten besser geworden.
Wie sich das auf die Sichtbarkeit auswirkt, können wir noch nicht sagen. Die Extensions sind erst seit Oktober 2026 öffentlich. Wir prüfen das nach einigen Monaten und ergänzen diesen Beitrag.
Häufige Fragen
Was kostet die Veröffentlichung im TER?
Die Registrierung des Extension Keys und der Upload sind kostenlos. Der eigentliche Aufwand steckt in der Vorbereitung und in der Pflege danach: Antworten auf Issues und Anpassungen an neue TYPO3-Versionen.
Reicht Packagist, oder braucht es auch das TER?
Für Composer-Installationen reicht Packagist. Das TER lohnt sich trotzdem: Es ist das offizielle Verzeichnis der TYPO3-Community, und die Dokumentation erscheint auf docs.typo3.org.
Unter welcher Lizenz muss eine Extension stehen?
Für das TER muss sie GPL-kompatibel sein, üblich ist GPL-2.0-or-later. Fremde Bibliotheken im Paket müssen dazu passen. Prüfen Sie das vor dem ersten Upload.
Dürfen Extensions aus Kundenprojekten veröffentlicht werden?
Nur, wenn die Rechte daran klar sind und der Code nichts über den Kunden verrät. Wir veröffentlichen ausschließlich Eigenentwicklungen ohne Kundenbezug.
Sie brauchen eine Funktion, die keine bestehende Extension abdeckt? Mehr dazu auf unserer Seite zur TYPO3-Extension-Entwicklung.