Composer bricht ab — und die Meldung ist länger als die Fehlerseite.

Was Composer in TYPO3 macht.

Composer ist die Paketverwaltung für PHP. Bei modernen TYPO3-Installationen verwaltet sie den Kern, alle Extensions und deren Abhängigkeiten: Welche Version wird gebraucht, welche passt zu welcher, was muss zusammen aktualisiert werden. Die Vorgaben stehen in einer Konfigurationsdatei, der tatsächlich installierte Stand in einer Lockdatei.

Der Vorteil: Updates werden nachvollziehbar und wiederholbar. Der Preis: Man muss verstehen, wie Abhängigkeiten funktionieren — sonst wirken Fehlermeldungen willkürlich.

Fehlermeldungen lesen.

Composer gibt bei Konflikten eine lange Liste aus, die wie Kauderwelsch wirkt. Der Trick: Die wichtigste Zeile steht meist am Ende der Aufzählung, und jede Zeile ist ein Glied einer Kette. Gelesen wird sinngemäß so: „Paket A braucht Paket B in Version X, aber installiert ist Version Y, weil Paket C das so verlangt."

Damit hast du den Konflikt benannt — und meist auch den Schuldigen: Das Paket, das eine veraltete Version festhält, ist fast immer eine Extension, die seit Längerem kein Update bekommen hat. Notier dir aus der Meldung die zwei bis drei Paketnamen; alles andere ist Beiwerk.

Abhängigkeitskonflikte.

Was man vermeiden sollte: den Konflikt mit dem Ignorieren von Anforderungen zu erzwingen. Das funktioniert manchmal und führt zu Fehlern, die später an völlig anderer Stelle auftauchen und sich nicht mehr zuordnen lassen. Wenn es gar nicht anders geht, dann bewusst, dokumentiert und mit anschließendem Test — nicht als Standardlösung.

Oft ist die beste Antwort die unbequeme: Eine Extension, für die es keine passende Fassung gibt, hält die ganze Installation auf. Dann steht die Frage an, ob sie wirklich gebraucht wird (Extensions bewerten).

Speicherlimit.

Composer berechnet Abhängigkeiten und braucht dafür erstaunlich viel Arbeitsspeicher — bei größeren Installationen deutlich mehr, als auf vielen Servern erlaubt ist. Das Ergebnis ist ein Abbruch mit einer Meldung über erschöpften Speicher, mitten im Vorgang.

Ein Nebeneffekt, den man kennen sollte: Composer braucht auch Festplattenplatz für Zwischendateien. Ist der Webspace fast voll, scheitert der Vorgang ebenfalls — mit einer Meldung, die nicht danach aussieht (Speicherplatz).

PHP-Version und Erweiterungen.

Composer läuft auf der Kommandozeile, und dort kann eine andere PHP-Version aktiv sein als im Webserver. Das führt zu zwei verwirrenden Fällen: Composer installiert Pakete für eine Version, die die Website gar nicht nutzt — oder er verweigert die Installation, obwohl die Website die Anforderung erfüllt.

Prüfe die Version auf der Kommandozeile und rufe im Zweifel PHP mit vollem Pfad auf, statt dich auf den Standard zu verlassen. Dasselbe gilt für fehlende PHP-Erweiterungen: Composer meldet sie klar, und sie müssen auf der Kommandozeile vorhanden sein, nicht nur im Webserver (Hosting-Anforderungen).

Die Lockdatei.

Sie hält fest, welche Versionen tatsächlich installiert sind. Damit lässt sich derselbe Stand auf einem anderen Server exakt wiederherstellen — die Grundlage für verlässliche Abläufe zwischen Test- und Produktivumgebung.

Zwei Regeln dazu. Erstens: Die Lockdatei gehört in die Versionsverwaltung, nicht ausgeschlossen. Zweitens: Auf dem Produktivserver wird nicht aktualisiert, sondern installiert — also der in der Lockdatei festgehaltene Stand eingespielt. Das Aktualisieren passiert in der Testumgebung, und die neue Lockdatei wird ausgerollt. Wer diese Trennung einhält, hat die Hälfte aller Composer-Probleme nicht (Testumgebung).

Rechte und Pfade.

Composer legt Dateien an und braucht dafür Schreibrechte im Projektverzeichnis. Läuft er unter einem anderen Benutzer als der Webserver, gehören die erzeugten Dateien dem falschen Konto — und die Website kann sie nicht lesen oder nicht schreiben, wo sie müsste.

Symptom: Nach einem Composer-Lauf funktioniert die Website nicht mehr, obwohl der Vorgang durchlief. Dann stimmen die Besitzverhältnisse nicht. Bei gutem Hosting ist das kein Thema, bei selbst verwalteten Servern gehört es geprüft (Dateirechte).

Sicheres Vorgehen.

1. Backup von Dateien und Datenbank, bevor etwas angefasst wird.
2. In der Testumgebung aktualisieren, nicht auf dem Produktivserver.
3. Ausgabe lesen, bevor bestätigt wird — besonders bei Paketen, die entfernt werden sollen.
4. Nach dem Lauf: Caches leeren, Datenbankabgleich ausführen (Cache).
5. Testen, dann die Lockdatei ausrollen und auf dem Produktivsystem installieren.
6. Dort erneut: Caches, Datenbankabgleich, kurz prüfen.

Wenn kein SSH vorhanden ist.

Ohne Kommandozeile lässt sich eine Composer-Installation nicht sinnvoll betreiben. Es gibt Hilfskonstruktionen — Pakete lokal vorbereiten und hochladen —, aber die sind umständlich und fehleranfällig. Wenn du eine Composer-Installation hast und keinen SSH-Zugang, ist das die eigentliche Baustelle: Entweder ein Hosting mit SSH, oder zurück zu einer klassischen Installation.

Für eine ernsthaft betriebene TYPO3-Installation würde ich SSH als Pflichtmerkmal behandeln. Die Zeit, die man ohne verliert, kostet mehr als der Aufpreis für ein geeignetes Paket.

Von klassisch auf Composer.

Viele ältere Installationen laufen noch klassisch, mit Extensions im Dateisystem. Die Umstellung auf Composer ist ein eigenes kleines Projekt: Alle Extensions müssen als Pakete verfügbar sein, eigene Erweiterungen brauchen eine passende Beschreibung, und die Verzeichnisstruktur ändert sich.

Der Aufwand lohnt, wenn regelmäßig aktualisiert wird oder ein Versionssprung ansteht — danach sind Updates deutlich einfacher und nachvollziehbar. Bei einer kleinen, selten geänderten Installation kann klassisch auch bleiben; dann sollte man aber wissen, dass bestimmte Wege nicht offenstehen (Updates).

Wenn du nicht weiterkommst.

Wenn Composer abbricht und die Meldung nichts hergibt, lese ich die Abhängigkeitskette und sage dir, welches Paket blockiert. Schreib mir mit Domain, TYPO3-Version und einer kurzen Beschreibung — du bekommst eine ehrliche Einschätzung, ob ich der Richtige bin. Den Überblick über alle Themen gibt TYPO3-Fehler beheben. Wenn sich am Ende herausstellt, dass ein Wechsel die bessere Lösung ist: TYPO3 zu WordPress.

Orientierungswerte, keine Fixpreise — nach einem kurzen Gespräch bekommst du ein Festpreisangebot.

Wer hilft.

Ich bin Manuel Killert, Web-Entwickler aus Quakenbrück. Mein Schwerpunkt liegt auf WordPress — an TYPO3-Installationen arbeite ich dort, wo es um Betrieb und Fehlersuche geht: Ausfälle, Serverthemen, Datenbank, Mailversand, Updates und die Frage, wie es mit einer alten Installation weitergehen soll. Das sind die Probleme, bei denen die Ursache meist nicht im System selbst liegt, sondern darunter. Geht es um tiefe Entwicklung in TYPO3 — eigene Extensions, komplexe Mehrsprachigkeit, große Redaktionssysteme —, sage ich dir das offen und empfehle jemanden, der genau das macht. Ehrlich beraten heißt für mich auch, eine Anfrage abzugeben.