404 Seite aus eigenem Tag/Modul heraus anzeigen

[nhaack]

Hallo zusammen,

ich würde gerne je anch Ausgabe eigener Tags die 404 Seite des CMS anzeigen.

In meinem Template rufe ich einen Tag auf und prüfe ob das Ergebnis "False" ist, in diesem Fall soll die Fehlerseite angezeigt werden.

Code: Select all

{my_udt assign"result"}

{if $result == false}
  {trigger_404}
 {else} 
  ... do some stuff ...
{if}

Die Frage ist nur, wie rufe ich die 404 Seite auf?

Ich habe einen kleinen UDT-Einzeiler, mit dem ich zwar einen 404 Header senden kann, aber nicht die Fehlerseite selbst auslöse.

Code: Select all

header("HTTP/1.0 404 Not Found");

Das Problem sind die Rewrite-Regeln. Die URL-Pfade werden so gemapt, dass CMSMS nicht vor Berechnung der Seite feststellen kann ob es die Seite geben wird oder nicht. Das finde ich erst mit Ausführen des eigenen Tags heraus. Deshalb suche ich nach einem Weg, die 404 Seite gesondert zu triggern.

Ganz plump:

http://www.example.com/some-parameter-value/

wird auf folgende URL umgeschrieben

http://www.example.com/index.php?page=s ... eter-value

Somit ist es egal was übergeben wird, der eigentliche CMSMS Seitenaufruf ist per se ja kein 404 weil es die Seite "some-alias" gibt. Parameter ist z.B. leer oder existiert nicht kann ich per htaccess abfangen.

Jemand mit 'ner Idee?

Beste Grüße
Nils

[NaN]

Warum leitest Du nicht einfach via smarty plugin {redirect_page} auf irgendeine Dummy Seite um, die garantiert nicht existiert?

Code: Select all

{my_udt assign"result"}

{if $result == false}
  {redirect_page page="irgendein fiktives alias das nicht existiert"}
 {else} 
  ... do some stuff ...
{if}

Ist zwar nicht unbedingt optimal, aber sollte doch am Ende auch die CMSms Fehlerseite anzeigen, oder?
(Mal ganz nebenbei: Ich habs noch nie hinbekommen, die CMSms eigene 404 Fehlerseite anzuzeigen. Gab jedesmal 'nen Serverfehler. Welche Server-Konfiguration ist denn dafür verantwortlich, dass man eigene 404 Fehlerseiten setzen darf, oder nicht? Wäre auch für die Systemvorraussetzungen für CMSms interessant zu wissen. Dann könnte man z.b. diese Option im Backend einfach deaktivieren, falls sie aufgrund der Server-Konfiguration eh nicht zur Verfügung stehen sollte oder gleich bei der Installation entsprechende Meldungen anzeigen.)

[nhaack]

Hi NaN,

das mit dem Redirect hatte ich erst drinne, die Option gefiel mir aber nicht so gut, da ich dann erst den Redirect ausführe und dann den 404 liefere.

URL1 + Falscher Parameter -> 301 auf URL2 -> 404

Die ursprüngliche Adresse wäre damit weiterhin "gültig" (meine ich). Trotzdem danke für die Idee.

Ich habe jetzt als Zwischenlösung den 404-Text und den -Title einfach in mein Template kopiert und liefere im Falle eines Fehlers nur diesen Teil des Templates aus. Sieht jetzt nach außen wie 'ne saubere 404 aus. Da dies allerdings auf sehr vielen Templates notwendig wäre, habe ich den Fehlertext nun in einen Globalen Content Block gelegt.

Aber irgendwie erscheint mir diese Lösung immer noch nicht wirklich elegant. Seite rendern, feststellen das es nicht geht, 404 Header senden, Content-Weiche und GCB. Im Grunde müsste man mit Erkenntnis, dass die Seite nicht vorhanden ist, das Rendern der Seite unterbrechen und direkt den 404 Content aus der DB Laden und einschieben. Vielleicht wäre hier ein UDT, dass die aktuelle 404-Seite aus der DB lädt und einbindet die beste Lösung, damit bleibt der Code auf der Seite noch übersichtlich und ich habe geringen Pflegeaufwand.... was meint ihr?

Zu den Fehlerseiten und die Einrichtung kann ich nicht viel sagen, hat bei mir eigentlich immer problemlos out-of-the-box geklappt (mit normalen Content-Seiten). Wobei ich selten mit vielen Modulen arbeite, bei denen 404 der Fall sein könnten. Die Fehlerseiten über CMSMS auszugeben finde eigentlich super, da man hier noch auf einige CMSMS Komponenten zurückgreifen kann (z.B. "sorry, die Seite haben wir nicht, aber vielleicht interessiert dich ja X, Y oder Z?").

Grüße
Nils

[cyberman]

Die Fehlerseiten über CMSMS auszugeben finde eigentlich super, da man hier noch auf einige CMSMS Komponenten zurückgreifen kann (z.B. "sorry, die Seite haben wir nicht, aber vielleicht interessiert dich ja X, Y oder Z?").

Das ist aber seit der 1.6 der Systemstandard  - schau mal in die Inhaltstypen ...

[nhaack]

mhh.. aber müsste ich dafür nicht einen Redirect auf die entsprechende Seite ausführen? Mir ist immer noch nicht klar, wie ich den Fehler direkt auslösen kann... In der Doku habe ich auch nichts hierzu finden können (oder falsch gesucht :p).

Das Konstrukt mit dem GCB ist erstmal i.O.. Langfristig würde ich auf die Variante mit dem UDT, dass die entsprechende Fehlerseite lädt wechseln.

Will nur nichts entwickeln, und am ende sagt wieder jemand, dass es das ganze schon gab

Grüße
Nils

[cyberman]

Vielleicht wäre hier ein UDT, dass die aktuelle 404-Seite aus der DB lädt und einbindet die beste Lösung,

Ist in der Tat nicht einfach nachzuvollziehen.

Die Fehlerseite, die man über den Inhaltstyp erstellt, bekommt den Alias "error404" - nur dies allein nützt dir relativ wenig, da du durchaus diese Seite via Alias aufrufen kannst, aber als Status 200 mitgeliefert bekommst (wird wohl systemseitig gesetzt - hab da /lib/classes/class.pageinfo.inc.php, ab Zeile 164 lokalisiert.

Habs für mich mit einem udt gelöst, der den 404er header setzt und im Template der Fehlerseite vor dem eigentlichen Template aufgerufen wird. Wird aber spätestens dann doof, wenn ein "echter" 404er Fehler ausgelöst wird - damit würde der 404er header ja 2x gesetzt ...

[nhaack]

Ich danke euch schonmal für das Feedback. Ich werde das mal im englischen Forum platzieren. Vielleicht haben ja CalGuy und Co. eine Idee?

Danke & Grüezis
Nils

P.S.: Antwort poste ich natürlich hier