Errorlog erweitern

[Malcolm Beck´s]

hi,

404-Seiten gehören im Access-Log geloggt - indem das CMS HTTP-Status 404 zurückliefert anstelle von 200. Wenn dein CMS das bislang noch nicht kann, gehört diese Funktion schleunigst integriert. Dann können dir auch alle gewöhnlichen Logfile-Statistik-Programme die Info zusammenfassen.

Mein CMS generiert schon die richtigen Header, nur möchte ich so kleinigkeiten nicht direkt aus den Access-Logs rausfiltern. Mit meiner Variante ist es einfacher zu Handhaben, da ich kaum was zu beachten brauche, ausser das error_logs auf dem Webspace verfügbar sind.

Aber deine Logfunktion erfordert zwingend einen zweiten Parameter, der ein Objekt mit der Eigenschaft "error" sein muss, und greift außerdem auf mysqli_connect_error() zu.

Nein, der zweite Parameter erwartet lediglich die Variable für $_dbConnect, das auch nur, weil ich diese nicht in der Funktion als global deklarieren wollte.
Ich hate schon Gestern ein wenig weiter gebastelt, werde es aber jetzt nochmal komplett neu schreiben.

  /*  
   * eigenes Error_log  
   *  
   * Param $_content: Die Fehlermeldung, bspw. Error 404 - not found  
   * Param $_connect: Datenbankverbindung, um Mysql-Fehler abzufragen  
   * Param $_errfile: Die Errorlog-Datei  
  */  
  function my_errorlog ($_content,$_connect,$_errfile=ErrorLogFile)

Diese explizite Festlegung hat ihre Nachteile dann, wenn dein CMS nicht von dir auf deinem Host eingesetzt werden soll, sondern woanders. Üblicherweise würde man vermutlich erwarten, dass die Fehler genau in dem Logfile auftauchen, welches von der php.ini definiert wurde.

Ja, dieses Problem ist mir bewusst, leider kann ich noch nicht soweit denken ;)
Wenn
ini_set('error_log', 'error/error_log.inc.php'); ## Error-Log
nicht funktioniert, gibt es halt kein error_log ;)

Aber diese Fehler landen nur dann in DIESEM Logfile, wenn die php.ini entsprechend konfiguriert ist - oder du einen eigenständigen Error-Handler definiert hast, der dann wieder deine eigene Logfunktion benutzt.

Das ist bei mir ja der Fall, meine php.ini ist für meinen Fall angepasst; klar, wenn ich dieses Script weiter gebe, könnte es Probleme geben, nur steht das derzeit ausser Frage, da dass CMS bei weitem nicht massentauglich ist.

Dann ist die Definition eines dritten optionalen Parameters in der Funktion überflüssig. Entweder der Dateiname wird als Konstante definiert

Das habe ich korrigiert, Danke für den Hinweis.

Beides ist nicht die Aufgabe des Loggers. Denn der Logvorgang hat gefälligst maximal schnell abzulaufen - das Zippen einer Gigabyte-Logdatei dauert hingegen seine Zeit.

Im Admin-Backend habe ich schon eine Option zum speichern der Error_logs, nur, wenn ich mal vergesse, das Admin-Backend aufzurufen (Bsp. wegen Urlaub) und die Datei schon 1,5 GB gross ist, soll es spätestens an diesem Punkt abgefangen werden.

Wenn du es vernünftiger lösen willst, dann schreibst du dir einen Mechanismus, der pro Tag, Woche oder Monat einen neuen Logfilenamen verwendet, und bietest in deinem Admin-Backend eine Möglichkeit, die generierten Logfiles zu verwalten, zu zippen, auszuwerten oder zu löschen.

Das würde wohl Cronjob voraussetzen, was 1und1 leider nur gegen aufpreis anbietet; mein nächster Provider wird all-inkl sein, dass steht schon mal fest.

» ich kann jetzt z. B. mitloggen, wenn jemand eine nicht existierende Seite aufruft

Braucht bzw. verursacht die Fehlermeldung scheiternde Datenbankzugriffe?

Quasi ;)
Ja,ich weiss, in den Access-Logs werden diese Aufrufe auch mitgeloggt, aber ich möchte ja auch ein wenig Datenhandling lernen.

Wenn das Datenbankfehler erzeugt, ist auch irgendwas ganz böse falsch in deinem Datenbankcode. Es taucht aber in jedem Fall im Access-Log auf, dafür ist das ja da.

Mein CMS generiert hier auch die richtigen Header, nur ist mir die auswertung der Access-Logs mit zuviel arbeit verbunden, meine Variante habe ich mit 4-5 Funktionen sehr gut im Griff.
Im Admin-Backend sieht es derzeit so aus (Links funktionieren natürlich nicht).

Wie gesagt: Wenn die Datenbank irgendwelche Fehler produziert, dann willst du das loggen, indem du die DB-Fehlermeldung in die Logdatei schreibst. Gerne auch mit Host, URL und Uhrzeit dabei. Du willst aber nicht irgendwas loggen,

An sich hatte ich mir gedacht, wenn ich schon dabei bin, logge ich einfach alles mit, was in meinen Augen ein Fehler ist, ist dass der falsche Ansatz?

Aktuell sieht meine index.php so aus, allerdings bastel ich noch dran.

mfg