Die Einstellung des 404 Error Handling in TYPO3 ist nicht ganz einfach und auch nicht ganz logisch. So klappts ohne die Verwendung von ominösen Extensions:
#Muss 1 sein
$TYPO3_CONF_VARS[‚SYS‘][‚curlUse‘] = ‚1‘;
#Muss leer sein
$TYPO3_CONF_VARS[‚EXTCONF‘][‚realurl‘][‚_DEFAULT‘][‚init‘][‚postVarSet_failureMode‘] = “;
#Hier der logische Teil
$TYPO3_CONF_VARS[‚FE‘][‚pageNotFound_handling‘] = ‚/seite-nicht-gefunden.html‘;
$TYPO3_CONF_VARS[‚FE‘][‚pageNotFound_handling_statheader‘] = ‚HTTP/1.0 404 Not Found‘;
Telefon: 
e-Mail schreiben
zum Kontaktformular
Aus welchem Grund muss curlUse = 1 sein?
Gruß
Peter
Keine Ahnung. Aber ohne gehts nicht.
curlUse muss nicht sein. Es geht auch ohne. Hängt denk ich davon ab, ob beim Server allow_url_fopen aktiv ist. CURL ist ja dann nur die Alternative. Übrigens ist es Empfehlenswert eine separate HTML-Datei für die 404-Seite zumachen und diese dann bei [‚pageNotFound_handling‘] mit READFILE: anzusprechen. Dann wird einfach nur bei einem 404 der Inhalt der HTML zurückgeliefert. Was weniger Serverperformance kostet, da keine Datenbank abfragen gemacht werden müssen.
Hallo Michael,
ich habe momentan das gleiche Problem, nur noch in Verbindung mit realUrl. Durch den redirect wird zuerst ein 404 header und dann ein 200 header (für die gefundene Fehler-Seite in Typo3) ausgegeben. Dadurch wird der Header vor dem Doctype ins HTML geworfen (quasi ein echo).
Hat irgendjemand ne Idee, wie ich realurl / TYPO3 dazu bringe, das zu lassen?
Kann leider nur angewendet werden, wenn nur eine Sprache vorhanden ist.
Bookmarks und Links in zugangsbeschränkte Seiten enden mit der oben beschriebenen Einstellung auch in Fehlerseiten. Ungeübte Besucher würden den Login vermissen oder verlieren und diese Lösung als „ominös“ werten.
wohin damit? ist das typoscript? ins Template Setup? funzt nicht. Konstanten? funzt auch nicht… als TS Config auf der Seite… geht auch nicht… schlechte beschreibung… damit wirds nicht einfacher.
@knuetzn: Das gehört in die /typo3conf/localconf.php! Erkennt man daran, dass der vom Michael geschriebene Code eben PHP-Code ist, daher in eine PHP-Datei muss.
Beim Errorhandling auf jeden Fall aufpassen mit URL-Rewriting: existiert die Seite aus irgendeinem Grund nicht mehr (Seitentitel geändert oder RealURL deaktiviert), schickt das sonst den Server in eine Schleife, die ihn je nach Konfiguration auch in die Knie zwingen kann.
@Frank
Das könnte daran liegen, dass deine Fehlerseite nicht gefunden wird. Passiert zb dann wenn du auf einen Pfad verweist, der in einer Subdomain nicht verfügbar ist.
Bei mir reicht ebenfalls das
wobei die gegebene ID natürlich die PID der 404-Fehlerseite darstellt.
Beide Werte lassen sich übrigens auch bequem per Install Tool unter „All Configuration“ (suche nach pageNotFound_handling) einstellen.
Bitte beachtet, dass es bei Servern die nicht per http auf sich selbst zugreifen können (z. B. weil allow_url_fopen nicht erlaubt ist oder weil über eine .htaccess ein Passwortgeschutz gesetzt ist), zu einer Weiterleitung (303) kommt und nicht der erwartete 404 Header geliefert wird.
Außerdem kann RealURL dazwischenfunken und evtl. zuerst eine Weiterleitung (301) verursachen. Meiner Meinung nach sollte dies aber kein Problem darstellen, oder?
Hallo,
ich habe ein Problem mit der 404 Seite.
Bei mir erscheint keine 404 Seite bei ehemaligen URLs (Produkte die gelöscht wurden.
Beispielsweise ist die Seite http://www.vogtgmbh.com/produkte/details/hersteller/binderberger/produkt/einzel/ansicht/foerderband-fb-44.html
einfach nur Weiß!
Hat jemand eine Lösung?
Ich wäre sehr Dankbar!
Also ich hab mit 404 das Problem, dass es auf Unterseiten tadellos funktioniert. Nur auf root-ebene nicht.
Gibt man z.B. folgendes ein http://www.domain.com/de/ueber-uns/greqwgfewf/ erscheint die 404er korrekt
Gibt man allerdings http://www.domain.com/greqwgfewf/ ein erscheint nicht die 404er. Stattdessen wird auf http://www.domain.com umgeleitet, war ja eigentlich nicht korrekt ist.
Kann da jemand helfen bzw. gleiches Problem bestätigen?