Alte Links, entfernte Funktionen: wiederkehrende 500-Fehler elegant abfangen

Christopher Zechendorf

20.07.2026

Share:

Nach einer Funktionsentfernung liefen alte, noch gültige Links auf 500er-Fehler. Wie wir sie mit schlanken Weiterleitungen sauber abgefangen haben.

Wenn der Code verschwindet, die Links aber bleiben

Software wird umgebaut, Abläufe werden vereinfacht, alte Funktionen fliegen raus – das ist gesunde Weiterentwicklung. Was dabei gern übersehen wird: Die Links, die auf diese Funktionen zeigen, verschwinden nicht mit dem Code. Sie stecken in längst versendeten E-Mails, in Kalendereinträgen, in Lesezeichen und in den Indizes von Suchmaschinen – und sie bleiben dort, lange nachdem die dazugehörige Funktion entfernt wurde.

Genau dieses Muster haben wir auf der von uns betreuten Weinplattform VINUM beobachtet. Nach einem Umbau der Event-Anmeldung endete jeder Aufruf einer alten Anmelde-Aktion nicht etwa auf einer freundlichen Hinweisseite, sondern in einem harten Serverfehler. 41 solcher Fehler in nur sieben Tagen, verteilt über die deutsche und die französische Seite – ausgelöst von echten Nutzern, die auf einen völlig legitimen, korrekt signierten Link geklickt hatten. Dieser Artikel zeigt, wie man Funktionen abkündigt, ohne Besucher auf Fehlerseiten laufen zu lassen – ein Thema, das jede über Jahre gewachsene Website betrifft.

Die Herausforderung

Die Event-Anmeldung von VINUM lief früher über einen Bestätigungslink per E-Mail: Nach der Anmeldung erhielten Interessenten eine Mail mit einem Link, der die Anmeldung abschloss. Bei einem Umbau wurde dieser Ablauf durch mehrstufige, serverseitige Anmeldeschritte ersetzt – die alte, mailbasierte Aktion wurde ersatzlos aus dem Code entfernt.

Was dabei nicht bedacht wurde: Diese Bestätigungslinks tragen in TYPO3 eine kryptografische Signatur (den sogenannten cHash), die sie gegen Manipulation absichert. Diese Signatur läuft nicht ab. Ein Link, der vor Monaten in einer Bestätigungsmail verschickt wurde, ist technisch bis heute gültig – er zeigt nur eben auf eine Aktion, die es nicht mehr gibt.

Und genau hier lag die Tücke im Detail:

• Der Absturz passiert, bevor der eigene Code überhaupt läuft. In TYPO3 muss jede aufrufbare Aktion einer Erweiterung ausdrücklich als „erlaubt” registriert sein. Trifft eine Anfrage auf einen Aktionsnamen, der nicht mehr in dieser Liste steht, bricht das Framework die Verarbeitung mit einer InvalidActionNameException ab – noch bevor der Controller mit unserem eigenen Code aufgerufen wird. Ohne Auffangnetz wird daraus ein HTTP-500.
• Es waren echte Nutzer, keine Bots. Die aufgerufenen Links trugen allesamt gültige Signaturen. Bot-Anfragen oder verstümmelte URLs hätten diese Prüfung gar nicht erst bestanden. Die 41 Treffer stammten also von realen Personen, die eine noch im Umlauf befindliche Mail geöffnet hatten – auf Deutsch wie auf Französisch, über acht verschiedene Tage verteilt.
• Niemand beschwert sich. Wer auf einen alten Anmeldelink klickt und eine Fehlerseite sieht, ruft selten die Agentur an – er zuckt mit den Schultern und schliesst den Tab. Der Fehler bleibt damit unterhalb der Beschwerdeschwelle und taucht nur als wiederkehrende Zeile im Produktions-Log auf.

Sichtbar wurde das Problem überhaupt erst durch unsere tägliche, automatisierte Auswertung der Produktions-Logs, die wiederkehrende Fehler clustert und als fertig recherchiertes Ticket aufbereitet – aus „einige 500er pro Tag” wurde so ein priorisierter Auftrag mit fertiger Ursachenanalyse.

Unsere Lösung

Die naheliegende Reaktion – „die Funktion ist weg, dann sind die Links eben tot” – greift zu kurz. Solange gültige Links auf eine Adresse zeigen, ist diese Adresse Teil der öffentlichen Oberfläche und muss sich anständig verhalten. Unser Ziel war deshalb nicht, den Fehler zu unterdrücken, sondern die alten Links wieder an ein sinnvolles Ziel zu führen.

1. Schlanke „Legacy”-Aktionen statt einer ersatzlosen Lücke

Statt die entfernten Aktionen ganz verschwinden zu lassen, haben wir sie in abgespeckter Form wieder eingeführt – nicht mit ihrer alten Logik, sondern als reine Weiterleitungen. Die frühere Bestätigungs-Aktion nimmt jetzt nur noch die Event-Kennung entgegen und leitet den Besucher direkt auf die zugehörige Event-Seite weiter. Wer also einen alten Anmeldelink anklickt, landet nicht auf einer Fehlerseite, sondern genau bei der Veranstaltung, um die es ging – inklusive des aktuellen, neuen Anmeldewegs.

Für die codebasierte Bestätigung, die statt einer Event-Kennung einen individuellen Anmeldecode trägt, geht die Weiterleitung einen Schritt weiter: Der Code wird nachgeschlagen, die zugehörige Anmeldung und deren Event ermittelt, und der Besucher landet auf der richtigen Event-Seite. Aus einem Serverfehler wird so eine saubere Weiterleitung mit erhaltenem Kontext.

2. Die Aktionsnamen wieder als „erlaubt” registrieren

Die eigentliche Ursache des 500ers – der Abbruch, noch bevor der Controller läuft – lässt sich nur an einer Stelle beheben: in der Konfiguration der Erweiterung, die festlegt, welche Aktionen ein Plugin ausführen darf. Wir haben die beiden alten Aktionsnamen dort wieder eingetragen, und zwar in beiden Varianten der Liste (der gecachten und der ungecachten). Erst dadurch reicht das Framework die Anfrage überhaupt an unseren Code weiter, statt sie vorzeitig mit einer InvalidActionNameException abzuweisen.

3. Robuste Fallbacks für fehlende oder manipulierte Parameter

Alte Links kommen nicht immer sauber an. Manche tragen gar keine Kennung mehr, manche eine veraltete oder abgelaufene, manche eine durch mehrfaches Weiterleiten verstümmelte. Eine Weiterleitung, die stur mit einem gültigen Parameter rechnet, würde bei genau diesen Fällen wieder abstürzen – diesmal mit einem anderen Fehler.

Deshalb sind alle Parameter der neuen Aktionen bewusst optional. Fehlt eine Kennung, lässt sich ein Code nicht auflösen, oder ist ein Event längst vergangen, führt die Weiterleitung sauber auf die allgemeine Event-Übersicht zurück, statt einen Fehler zu werfen. Diese Nachsicht ist kein Beiwerk, sondern die Kernanforderung: Der Besucher soll immer auf einer funktionierenden Seite landen, egal in welchem Zustand sein alter Link ist.

4. Tote Verweise entfernen, damit keine neuen Altlasten entstehen

Beim Aufräumen zeigte sich, dass im Code noch alte Vorlagen schlummerten, die weiterhin Links auf die entfernte Aktion erzeugten – eine potenzielle Quelle für immer neue tote Links. Diese Vorlagen haben wir entfernt. Damit gibt es keine lebende Stelle mehr, die frische Verweise auf eine nicht mehr existierende Funktion ausgibt; das Problem kann sich nicht aus sich selbst heraus nachbilden.

Das Ergebnis

Aus jedem der bisher 41 Serverfehler pro Woche wird jetzt eine unauffällige Weiterleitung. Wer heute einen Monate alten Anmeldelink anklickt – aus einer archivierten Mail, einem Kalendereintrag oder einem Lesezeichen – landet direkt bei der gewünschten Veranstaltung oder, falls diese vorbei ist, auf der Event-Übersicht. Die InvalidActionNameException für die alten Aktionen ist aus den Logs verschwunden, und kein Besucher sieht mehr eine Fehlerseite, nur weil er einem völlig legitimen Link gefolgt ist.

Wichtiger als der einzelne Fix ist das Prinzip dahinter: Wir haben eine entfernte Funktion nicht wiederbelebt, sondern nur einen schmalen Migrationspfad für die noch kursierenden Links gebaut. Der neue Code ist bewusst minimal – er nimmt einen alten Aufruf entgegen und übergibt ihn an die aktuelle Oberfläche. So bleibt die Vereinfachung, die der Umbau gebracht hat, vollständig erhalten, ohne dass die Nutzer den Preis dafür zahlen.

Fazit

Eine Funktion aus dem Code zu entfernen ist einfach. Die Spuren, die sie in der Aussenwelt hinterlassen hat, verschwinden aber nicht mit ihr: Signierte Links in E-Mails leben unbegrenzt weiter, Kalender und Lesezeichen sind ein Archiv, das man nicht kontrolliert, und Suchmaschinen halten alte Adressen hartnäckig fest. Wer eine Funktion abkündigt, braucht deshalb einen Plan für die URLs, die bereits im Umlauf sind – und in aller Regel heisst dieser Plan: weiterleiten statt ersatzlos streichen.

Das kostet wenig. Eine schlanke Weiterleitung, die einen alten Aufruf auf ein sinnvolles Ziel führt und mit fehlenden Parametern gnädig umgeht, ist in kurzer Zeit gebaut – und erspart realen Nutzern die Sackgasse einer Fehlerseite. Der teure Weg ist der, diese Altlasten erst dann zu bemerken, wenn sie sich als wiederkehrende 500er im Log stapeln.

Planen Sie einen Umbau, bei dem Funktionen oder ganze Seitenbereiche wegfallen? Sprechen Sie uns an – wir sorgen dafür, dass Ihre bestehenden Links den Übergang überstehen und Besucher weich aufgefangen werden, statt in Serverfehlern zu landen.