TYPO3 und Composer: Moderne Entwicklung ohne manuelle Patcherei
PHP-Abhängigkeiten ohne Rätselraten
Composer ist ein Abhängigkeitsmanager für PHP. Das klingt nach einem Werkzeug für Entwickler, die eh schon wissen, was sie tun. In der Praxis ist es aber das Werkzeug, das den Unterschied macht zwischen einem Projekt, das reproduzierbar aufgesetzt werden kann, und einem, das auf eine bestimmte Kombination aus Glück und Kollegenwissen angewiesen ist.
Das Prinzip: Sie definieren in einer Datei (composer.json), welche Pakete Ihr Projekt benötigt und in welchen Versionen. Composer installiert genau diese Pakete, löst ihre Abhängigkeiten auf und schreibt das Ergebnis in eine zweite Datei: composer.lock. Diese Lock-Datei enthält die exakt installierten Versionen samt Prüfsummen, sodass jede Umgebung, die sie liest, denselben Stand reproduziert. Eine neue Entwicklungsumgebung aufzusetzen ist damit kein Puzzle mehr, sondern ein einziger Befehl: composer install.
Pakete kommen von Packagist, dem zentralen Repository der PHP-Welt, oder aus anderen Quellen per VCS-Referenz. Composer ist seit Jahren Standard in der PHP-Entwicklung, denn er überführt das, was vorher Konvention und Dokumentation leisten mussten, in maschinenlesbare Daten: welche Abhängigkeit, in welcher Version, mit welcher Prüfsumme.
TYPO3 und Composer: Wie das konkret aussieht
TYPO3 hat Composer-Support nicht als optionalen Zusatz nachgerüstet. Ab Version 9 gilt ein Composer-Setup als empfohlene Methode; ab Version 12 ist es der einzige vollständig unterstützte Weg für Neuinstallationen. Die offizielle TYPO3-Installationsdokumentation beschreibt den Composer-Pfad als primär, nicht als Experten-Alternative.
Extensions installieren und Versionen pinnen
Extensions aus der TYPO3 Extension Repository (TER) sind auf Packagist gespiegelt und lassen sich wie jedes andere PHP-Paket einbinden:
composer require georgringer/news
Ein Befehl. Kein manuelles Herunterladen, kein Entpacken, kein Hochladen per FTP. Composer prüft dabei automatisch, ob die Extension mit der installierten TYPO3-Version kompatibel ist, da Abhängigkeiten deklarativ beschrieben sind, nicht implizit erwartet werden.
Versionen pinnen Sie in der composer.json, zum Beispiel so:
"georgringer/news": "^11.0"
Das Caret-Zeichen (^) erlaubt kompatible Updates innerhalb der Major-Version, sperrt aber einen unkontrollierten Versionssprung aus. Sie entscheiden, wann ein Major-Update erfolgt, nicht der nächste Klick im Backend.
Update-Pipelines statt manueller Kontrollgänge
Sobald das Composer-Setup steht, lässt sich der Aktualisierungsprozess automatisieren. Ein CI/CD-Job führt composer update aus, läuft danach die Testsuite durch und öffnet einen Merge-Request mit dem aktualisierten composer.lock. Sie sehen in der Diff-Ansicht, welche Pakete sich geändert haben, und die Tests belegen, ob das System noch korrekt läuft.
Das ändert die Grundstruktur des Risikos: nicht mehr „wir hoffen, dass das Update nichts kaputt macht", sondern „wir sehen sofort, wenn etwas nicht stimmt". Manuelles Patchen von Extensions entfällt, da Composer die Versionierung übernimmt und Änderungen an Drittanbieter-Code in der composer.json sichtbar bleiben, nicht in unversionierten Dateien versteckt sind.
Früher: FTP-Upload und die stille Hoffnung
Ohne Composer installierten Entwickler Extensions über das TYPO3-Backend-Installationstool oder per FTP-Upload direkt in den Dateisystem-Ordner. Eine neue Extension-Version bedeutete: herunterladen, entpacken, kopieren, prüfen, hoffen. Ein maschinenlesbares Protokoll über den Installationsstand gab es nicht.
Die Folge war eine Situation, die in der Praxis häufig eskalierte. Auf dem Entwickler-Rechner lief TYPO3 mit Extension-Version 3.4.1, auf dem Produktionssystem stand seit einem unbeobachteten Backend-Klick Version 3.5.0. Die Diskrepanz war unsichtbar, bis etwas nicht funktionierte. Wer dann herausfinden wollte, was sich geändert hatte, durfte Changelogs lesen und Dateien vergleichen, da kein automatisches Protokoll half.
TYPO3-Major-Updates verschärften das Problem weiter. Wenn eine Extension für die neue Hauptversion noch keine kompatible Version hatte, blieb oft nur manuelles Patchen: Extension-Dateien direkt bearbeiten, um Kompatibilitätsfehler zu beheben. Diese Patches existierten dann irgendwo im Dateisystem, ohne Versionskontrolle, ohne Nachvollziehbarkeit. Wer das Projekt später übernahm, sah geänderte Dateien und wusste nicht, warum.
Das war nicht Fahrlässigkeit der damaligen Entwickler. Es war der Stand des Werkzeugkastens.
Was ein Composer-Setup konkret bringt
Drei Punkte, ohne Abstraktionen:
Onboarding ohne Rätsel. Ein neuer Entwickler klont das Repository und führt composer install aus. Das Lock-File sorgt dafür, dass er exakt dieselbe Umgebung erhält wie der Kollege, der vor sechs Monaten zuletzt an dem Projekt gearbeitet hat. Kein Suchen nach der richtigen Extension-Version, kein Nachfragen beim Team.
Vollständige Nachvollziehbarkeit. Jede Änderung an Abhängigkeiten ist ein Commit in der Versionskontrolle. Sie sehen, wann eine Extension aktualisiert wurde, wer das veranlasst hat und in welchem Kontext, sodass Audits, Übergaben und Wartungsverträge auf belastbarer Dokumentation basieren.
CI/CD-Fähigkeit. Automatisierte Tests, reproduzierbare Deployments, Pipelines, die Abhängigkeiten aktuell halten: all das setzt voraus, dass das System deterministisch aufgebaut werden kann. Ohne Composer-Setup ist das kaum realisierbar; mit ihm ist es Routine.
Eine Einschränkung, die ehrlich benannt werden muss: Die Migration eines Legacy-TYPO3-Projekts, das ohne Composer aufgesetzt wurde, ist Aufwand. Abhängigkeiten müssen rekonstruiert werden, Konflikte können auftauchen, Extensions, die nicht auf Packagist verfügbar sind, brauchen manuelle Behandlung. Je älter und unstrukturierter das Ausgangsprojekt, desto mehr Zeit kostet dieser Schritt. Dieser Aufwand ist einmalig. Danach steht ein sauberes Fundament, auf dem Wartung und Weiterentwicklung planbar werden.
