vielleicht eine dumme Frage (wobei dumme Fragen gibt es ja eigentlich nicht :D): War es schon immer so und ist es gewollt, dass mittels @-Operator unterdrückte PHP-Fehler trotzdem ins Logfile und das Meldungsfenster geschrieben werden?
Irgendwie ist mir das jetzt aufgefallen, da eine potenziell auftretende und unterdrückte Warnung, die bisher nicht eingetreten ist, nun auftritt und ich diese dann entsprechend im Log sehe, was - zumindest in dem Fall - eigentlich unnötig ist.
Hatte ich neulich auch bei jemand. In einem Modul von mir wurden PHP-Warnungen (zB „array_key_exists“) unterdrückt und von mir selbst „ausgewertet“. Auf keinem meiner IPS-Installationen wurde die Warnung ausgeben - bei einem User erschien die PHP-Warnung aber im Log!
Das war arg seltsam und meine „Lösung“ war am Ende - im Modul umbauen, damit das @ nicht mehr benötigt wird.
Hier kann es vorkommen, dass $value einen nicht existierenden Namen hat. Deswegen werden potenzielle Warnungen unterdrückt.
Im Skript selbst funktioniert das auch problemlos. Im Log und im Meldungsfenster taucht die Warnung aber (neuerdings?) auf.
Aber es passiert auch bei so banalen Dingen, wie:
$test = @(10 / 0);
Führe ich das Skript manuell aus, wird die Division durch 0 Warnung nicht angezeigt, im Log und im Meldungsfenster taucht sie jedoch auf.
Wurde ein benutzerdefinierte Fehlerbehandlungsfunktion mit set_error_handler() registriert, dann wird diese immer noch aufgerufen, aber diese benutzerdefinierte Fehlerbehandlung kann (und sollte) error_reporting() aufrufen, das 0 zurückgeben wird, wenn dem Aufruf, der den Fehler auslöste, ein @ vorangestellt war.
Ich kann es mir nur damit erklären. Somit muss du irgendwo einen eigenen Error-Handler nutzen. (z.B. den IPSLogger?)
Ich nutze aber keinen eigenen Error-Handler. Wüsste zumindest nicht wo.
Habe gerade mal alles nach set_error_handler abgesucht. Keine Treffer. Den IPSLogger nutze ich auch nicht.
Dann würde mir noch noch einfallen, dass irgendein Modul da in Sachen Error-Handler was macht. Aber wie kriege ich das am besten raus? Hatte zunächst das Patami Framework in Verdacht. Das nervt mich schon seit längerem mit irgendwelchen blöden Exceptions (im Fall eines Skript-Fehlers), die gar nichts mit dem Framework zu tun haben. Aber habe da auf die schnelle auch nichts gefunden.
BlindControl habe ich seit ein paar Tagen testweise installiert. Das hat einen Verweis auf den IPSLogger, aber wenn ich die Library nicht habe, dürfte es das ja auch nicht sein.
Hast du eine Idee, wie ich alle Module systematisch prüfen kann?
Ja, das ist wirklich so. Das klingt sich ähnlich wie die IPSLibrary überall mit ein.
Und da die Fehlermeldungen der Konsole und aus dem Log bei dir auch unterschiedlich sind, würde ich auf das Framework tippen.
Michael
Es war wirklich das Patami-Framework.
Nachdem ich zunächst die Option „Das Framework automatisch in allen Skripten laden“ deaktiviert habe, wurden die Fehler schon nicht mehr geloggt. Dafür bekam ich dann „max execution time“ Fehler von Patami. Vielleicht hätte auch die Option „Unbehandelte PHP Fehler und Ausnahmen protokollieren“ zu deaktivieren gereicht. Aber das Framework saß mir ohnehin zu tief in allem drin.
Nachdem ich es dann komplett deinstalliert habe, dabei noch zwei Threads vom Framework hängen geblieben sind, die auch den Shutdown von IPS verhindert haben und nur noch das Killen des Prozesses half, bin ich das Framework nun scheinbar wirklich los und auch die nicht gewollten Logs.
Da muss man auch erst mal drauf kommen, dass es an dem Modul lag.