Eine Extension bricht alles — und du kommst nicht mehr rein.

Verursacher erkennen.

Die graue Fehlerseite zeigt nur eine Kennung. Die eigentliche Meldung mit Datei und Zeile steht in der Protokoll- beziehungsweise Exception-Datei auf dem Server (Weiße Seite). Darin suchst du nach dem ersten Pfad, der nicht zum Kern gehört:

Die dritte Zeile ist wichtig: Wenn eine Systemextension in der Meldung auftaucht, ist meist nicht sie das Problem, sondern etwas, das sie aufruft. Lies die Aufrufkette weiter nach unten — dort steht, wer angefangen hat.

Composer oder klassisch.

Bevor du etwas abschaltest, musst du wissen, wie die Installation aufgesetzt ist. Das entscheidet über den Weg und darüber, ob du dir die Installation zerlegst.

• Composer-Installation: Es gibt eine Datei composer.json im Hauptverzeichnis und einen Ordner vendor. Extensions werden über die Paketverwaltung installiert und entfernt.
• Klassische Installation: Extensions liegen in typo3conf/ext/ und werden im Erweiterungsmanager verwaltet.

Bei einer Composer-Installation eine Extension aus dem Ordner zu löschen, löst das Problem nicht — die Paketverwaltung erwartet sie weiterhin, und der nächste Aufruf bricht ab. Umgekehrt gibt es bei klassischen Installationen keinen Composer-Befehl, der hilft.

Abschalten ohne Backend.

Bei klassischen Installationen steht in der Konfigurationsdatei unter typo3conf, welche Extensions aktiv sind. Dort lässt sich der Eintrag der verdächtigen Extension entfernen. Vorher eine Kopie der Datei ziehen — ein Tippfehler darin legt die Installation vollständig lahm.

Der robustere Weg führt über die Kommandozeile, sofern vorhanden:

Kommst du noch ins Backend, ist der Erweiterungsmanager der einfachste Weg. Und wenn du nur den Verdacht eingrenzen willst: Deaktiviere nicht alles auf einmal, sondern die zuletzt installierte oder aktualisierte Extension zuerst — in neun von zehn Fällen ist das die richtige.

Bei Composer-Installationen.

Hier wird eine Extension nicht deaktiviert, sondern entfernt oder in einer anderen Fassung installiert. Das geschieht über die Paketverwaltung, und der entscheidende Punkt ist: Das gehört nicht auf dem Produktivserver gemacht, sondern in einer Umgebung, in der sich das Ergebnis testen lässt, bevor es ausgerollt wird.

Ist der Server die einzige Möglichkeit, gilt: vorher Sicherung von Dateien und Datenbank, und die Ausgabe der Paketverwaltung sorgfältig lesen. Sie nennt präzise, welches Paket welche Anforderung stellt und wer dagegensteht — das ist mehr Information, als jede Fehlerseite liefert (Update-Fehler).

Was danach zu tun ist.

1. Alle Caches leeren, sonst läuft weiterhin erzeugter Code der alten Fassung (Cache leeren).
2. Datenbankabgleich ausführen — Extensions legen eigene Felder und Tabellen an.
3. Frontend prüfen: Fehlt sichtbar etwas, wo die Extension gearbeitet hat?
4. Protokoll ansehen, ob neue Meldungen auftauchen.
5. Entscheiden, wie es mit der Funktion weitergeht.

Punkt drei wird gern vergessen: Eine abgeschaltete Extension hinterlässt Lücken — fehlende Formulare, leere Bereiche, kaputte Darstellungen. Die Website läuft dann zwar, ist aber unvollständig.

Extensions bewerten.

Bevor du Aufwand in eine Extension steckst, lohnt der prüfende Blick. Vier Fragen:

Diese Angaben stehen im offiziellen Extension-Verzeichnis und im Erweiterungsmanager. Fünf Minuten dort ersparen später Tage.

Verwaiste Extensions.

In fast jeder gewachsenen Installation liegen Extensions, die seit Jahren kein Update bekommen haben. Drei Wege:

• Weglassen. Der beste Fall — und häufiger möglich, als man denkt. Prüfe erst, ob die Funktion überhaupt noch genutzt wird.
• Ersetzen durch eine gepflegte Alternative. Dabei fällt meist etwas Nacharbeit an, weil Inhalte anders gespeichert werden.
• Anpassen lassen. Nur, wenn die Funktion wirklich gebraucht wird und es nichts Vergleichbares gibt. Vorher den Aufwand klären — bei größeren Extensions kann das teurer sein als ein Neubau der Funktion.

Der häufigste Fehler ist, diese Entscheidung erst während eines Upgrades zu treffen, unter Zeitdruck. Besser ist eine jährliche Bestandsaufnahme, wenn nichts brennt.

Eigenentwicklungen.

Selbst entwickelte Extensions sind ein Sonderfall: Niemand aktualisiert sie außer dir. Sie sind oft die eigentliche Hürde bei Versionssprüngen, weil sie Schnittstellen nutzen, die sich geändert haben. Was hilft, ist Dokumentation — was macht die Extension, warum gibt es sie, welche Teile werden genutzt. Fehlt die, ist der erste Schritt bei jedem Upgrade eine Analyse dessen, was man selbst gebaut hat.

Wenn eine Eigenentwicklung nur eine kleine Funktion erfüllt, lohnt beim nächsten Sprung die Frage, ob eine Standardlösung reicht. Jede eigene Extension weniger macht jeden folgenden Versionssprung billiger.

Aufräumen lohnt sich.

Zwei Zahlen aus der Praxis, die sich bei fast jeder Bestandsaufnahme bestätigen: Ein erheblicher Teil der installierten Extensions wird gar nicht genutzt, und ein weiterer Teil erfüllt eine Funktion, die der Kern inzwischen selbst mitbringt. Jede entfernte Extension bedeutet weniger Angriffsfläche, weniger Ladezeit, weniger Aufwand beim nächsten Update.

Vorgehen: Liste erstellen, je Extension notieren wo sie sichtbar wird, die Unklaren einzeln testweise deaktivieren und prüfen, ob jemand etwas vermisst. Das macht man in einer Kopie, nicht live — und mit einer Liste, auf die man später zurückgreifen kann.

Auswahl neuer Extensions.

Jede neue Extension ist eine Verpflichtung für Jahre. Vor der Installation lohnt deshalb dieselbe Prüfung wie oben, plus zwei Fragen: Lässt sich die Funktion auch mit Bordmitteln lösen? Und wie komme ich wieder raus, wenn die Extension eingestellt wird — bleiben meine Inhalte nutzbar? Besonders bei Erweiterungen, die eigene Inhaltstypen anlegen, ist das die entscheidende Frage. Wer sie vorher stellt, erspart sich beim übernächsten Versionssprung eine unangenehme Überraschung.

Wenn du nicht weiterkommst.

Wenn eine Extension deine Installation lahmlegt oder ein Upgrade blockiert, schaue ich mir an, was sie leistet und was sie ersetzen kann. 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.