phpBB.de

@Kizu

Absolut richtig, im LB hat - zumindest der vollständige - Debug Modus nichts zu suchen, alleine aus Sicherheitsgründen und Performancegründen. Dagegen sollte in einem Dev TB immer der volle Debug Modus aktiviert sein.

Sobald ich wieder am PC bin, bau ich mal paar Fehler bez. undefinierte Variablen ein um das zu testen. Ich kenne da auch evtl. das Schräubchen an dem man drehen muss, aber erst will ich sichergehen.

Ich hatte in Erinnerung, das ich dieses Problem auch schon hatte, das war jedoch was anderes wie ich vorhin in meinem LB sah.

Interessant. Bis eben dachte ich auch, dass display_errors = off eben genau das bewirken sollte. Ich vermute mal, dass das nur für PHP gilt, aber nicht für phpBB. Ich fand in phpBB jetzt auf die Schnelle nichts, um das zu "sauber" deaktivieren zu können. Allerdings gäbe es in den Core Dateien gleich 2 mögliche Stellen wo man eine Änderung vornehmen könnte um diese Debugs abzuschalten. Gib Bescheid, wenn das für dich in Frage kommt. Wenn nicht, bin ich hier erstmal raus.

Moin,

Offenbar ist in dieser Hinsicht phpBB noch nicht komplett PHP8-Kompatibel.
Ich habe auch einen entsprechenden Bugreport gefunden, der bereits im März 2021 erstellt wurde: https://tracker.phpbb.com/browse/PHPBB3-16731

MfG, Daniel

Hallo LukeWCS,

LukeWCS hat geschrieben: 12.12.2022 19:40 Allerdings gäbe es in den Core Dateien gleich 2 mögliche Stellen wo man eine Änderung vornehmen könnte um diese Debugs abzuschalten. Gib Bescheid, wenn das für dich in Frage kommt. Wenn nicht, bin ich hier erstmal raus.

In dem verlinkten Issue ist ja schon beschrieben, wie man es löst. Ich werde es mal ausprobieren und mich dann nochmal melden. Ich habe auch schon einen Kommentar hinterlassen, in der Hoffnung, das wird irgendwo bei den Entwicklern aufpoppen und dann vielleicht in einem Update berücksichtigt werden.

MfG, Daniel

Kizu hat geschrieben: 12.12.2022 20:22 Offenbar ist in dieser Hinsicht phpBB noch nicht komplett PHP8-Kompatibel.
Ich habe auch einen entsprechenden Bugreport gefunden, der bereits im März 2021 erstellt wurde: https://tracker.phpbb.com/browse/PHPBB3-16731

Ahja, guter Fund! Ich habe auch erst vor paar Tagen auf 8.0 umgestellt. Gerade eben im lokalen TB getestet mit meinem Pseudo-Fehler (undefinierte Variable). Bei PHP 8.0 erscheint die Debug Anzeige wie gehabt. Schalte ich um auf 7.4, wird die Debug Anzeige - wie es standardmässig sein soll - nicht angezeigt.

Also ein weiteres PHP 8 Problem.

Kizu hat geschrieben: 12.12.2022 20:34 In dem verlinkten Issue ist ja schon beschrieben, wie man es löst.

Okay, ich kannte bis eben den Tracker Eintrag ja nicht. Dann haben wir jetzt 3 Möglichkeiten.

@Daniel

Zwischenzeitlich habe ich das Problem genauer untersucht. Bis zu dem Zeitpunkt ging ich - wie du - von einer PHP 8 Inkompatibilität aus. Dem ist nicht so, phpBB 3.3 verhält sich auch bei PHP 8 genauso wie bei PHP 7. Des Rätsels Lösung liegt ganz einfach darin, dass etliche Meldungen die früher als E_NOTICE eingestuft waren, jetzt bei PHP 8 als E_WARNING eingestuft sind. Sprich, wo der Interpreter früher "noch ein Auge zugedrückt hat", ist er jetzt deutlicher.

Ich habe im Core etliche Debugs eingebaut um verfolgen zu können, was bei unserem Fehler (undefinierte Variable) hinsichtlich Error-Handler passiert und dabei entdeckt, dass dieser Fehler bei PHP 7.4 noch den Code 8 (E_NOTICE) hatte, bei 8.0 aber plötzlich als 2 (E_WARNING) an phpBB gemeldet wurde. Des Weiteren sah ich dann, dass in der Bitmaske der zu meldenden Fehlerzustände das Bit für E_WARNING schlicht nicht entfernt wird und das geht zurück bis 3.1.0. Das heisst, phpBB hat auch früher schon Warnungen angezeigt, das habe ich mit 7.4 gezielt getestet, das ist jederzeit reproduzierbar.

Der Debug Modus von phpBB hat mehrere Funktionen. Aber was die Error Codes angeht, so hat er lediglich Einfluss auf E_NOTICE und E_DEPRECATED. Ist der Debug Modus aktiv, werden auch E_NOTICE und E_DEPRECATED angezeigt. Der Debug Modus ändert jedoch nichts an E_WARNING oder E_ERROR, um nur 2 Beispiele zu nennen.

Hier der relevante Abschnitt aus der PHP Doku zur 8.0 News:

Einige Hinweise wurden in Warnungen umgewandelt:

Der Versuch, eine undefinierte Variable zu lesen.
Der Versuch, eine undefinierte Eigenschaft zu lesen.
Der Versuch, einen undefinierten Array-Schlüssel zu lesen.
Der Versuch, eine Eigenschaft eines Nicht-Objekts zu lesen.
Der Versuch, auf einen Array-Index eines Nicht-Arrays zuzugreifen.
Der Versuch, ein Array in eine Zeichenkette zu konvertieren.
Der Versuch, eine Ressource als Array-Schlüssel zu verwenden.
Der Versuch, null, einen Boolean oder einen Float als Zeichenketten-Offset zu verwenden.
Der Versuch, einen Zeichenketten-Offset zu lesen, der außerhalb des zulässigen Bereichs liegt.
Der Versuch, einem Zeichenketten-Offset eine leere Zeichenkette zuzuweisen.

Quelle: https://www.php.net/manual/de/migration ... atible.php

edit: Text präzisiert.

Hallo LukeWCS,

Deine Erklärung ist für mich logisch, doch empfinde ich das Verhalten immer noch für falsch.

LukeWCS hat geschrieben: 14.12.2022 18:46 Das heisst, phpBB hat auch früher schon Warnungen angezeigt, das habe ich mit 7.4 gezielt getestet, das ist jederzeit reproduzierbar.

Warum denn das? Wenn ich in PHP display_errors abschalte, bedeutet das doch, dass Fehler nicht angezeigt werden sollen. Egal welcher Stufe diese Fehler zugeordnet sind. Warum setzt sich phpBB darüber hinweg und zeigt diese trotzdem an?

MfG, Daniel

Du hast dir jetzt aber viel Zeit für die Antwort gelassen, für mich war das Thema schon längst erledigt. ^^

Kizu hat geschrieben: 03.06.2023 21:11 Deine Erklärung ist für mich logisch, doch empfinde ich das Verhalten immer noch für falsch.

Jo, gut finde ich es auch nicht, hab ich ja bereits erwähnt. Aber das eine hat mit dem anderen nichts zu tun. Es ging ja darum warum das Ganze bei PHP 8 "plötzlich anders" ist. Das es nicht anders ist, habe ich ja schon dargelegt. Bei phpBB hat sich nüscht geändert in diesem Punkt.

Warum denn das? Wenn ich in PHP display_errors abschalte, bedeutet das doch, dass Fehler nicht angezeigt werden sollen. Egal welcher Stufe diese Fehler zugeordnet sind. Warum setzt sich phpBB darüber hinweg und zeigt diese trotzdem an?

Hatte ich eigentlich dargelegt. phpBB definiert selbst diese Eigenschaft, es ist irrelevant was man bei dieser Eigenschaft in der php.ini oder sonstwo definiert.

Aber das fragst du den falschen, ich habs nicht programmiert, dass musste wohl eher auf .com fragen. Ich vermute schlicht das es bewusst so gemacht wurde, damit die Admins sich um ihren Laden kümmern. Wenn's da Warnungen oder gar Fehler gibt die man nicht einfach unter den Teppich kehren kann, dann muss das behoben werden und nicht nach Wegen gesucht werden, wie man diese Meldungen unterdrückt. Damit tut man sich langfristig nämlich keinen Gefallen, weil dann der GAU schon vorprogrammiert ist, bis dann gar nichts mehr geht und man mit viel Gejammer hier aufschlägt. Was ist denn die Standardfrage bei Problemen? Wohl eher "Wie kriege ich diese Fehlermeldung weg?" und nicht "Wie behebe ich dieses Problem?". Ich denke du siehst worauf ich hinaus will.

Natürlich sieht es anders aus, wenn ein Forum einen versierten Admin hat, der sich zügig um Probleme kümmert, die in der Error Log auftauchen und vor allem auch das Knowhow hat, solche Fehler verstehen und beheben zu können. Das trifft nur auf einen kleinen Teil zu.

LukeWCS hat geschrieben: 03.06.2023 21:46 Du hast dir jetzt aber viel Zeit für die Antwort gelassen, für mich war das Thema schon längst erledigt. ^^

Jep. Manches mal brauche ich etwas Zeit

LukeWCS hat geschrieben: 03.06.2023 21:46 Was ist denn die Standardfrage bei Problemen? Wohl eher "Wie kriege ich diese Fehlermeldung weg?" und nicht "Wie behebe ich dieses Problem?". Ich denke du siehst worauf ich hinaus will.

Jep. Ich verstehe, was du meinst. Ich bin eher von der Fraktion "Ich will verstehen, was da passiert und gebe nicht so schnell auf" aber deine Erklärung macht Sinn. Dankeschön.

LukeWCS hat geschrieben: 03.06.2023 21:46 Natürlich sieht es anders aus, wenn ein Forum einen versierten Admin hat, der sich zügig um Probleme kümmert, die in der Error Log auftauchen und vor allem auch das Knowhow hat, solche Fehler verstehen und beheben zu können. Das trifft nur auf einen kleinen Teil zu.

Ich denke, ich habe für mich die Lösung gefunden, dass ich die beiden Zeilen von der startup.php in die config.php verschoben habe. Und diese Datei unterscheidet sich ja sowieso bei meinem Test- und Produktivsystem voneinander. Muss ich nur beim Update des Cores dran denken

MfG, Daniel

Kizu hat geschrieben: 04.06.2023 13:06 Ich bin eher von der Fraktion "Ich will verstehen, was da passiert und gebe nicht so schnell auf"

Zu der Fraktion gehöre ich auch. Bei einem Problem ist für mich die eigentliche Lösung immer sekundär. Primär will ich verstehen, warum ein Fehler überhaupt auftritt. Hat man das eigentliche Problem verstanden, ist die Lösung eh nur noch Fleissarbeit und kostet in den meisten Fällen dann auch keine Gehirnakrobatik mehr. Ausserdem kann man so immens dazulernen.

Mich interessiert das Thema auch und hatte deshalb damals etliche Stunden in das Thema versenkt und entsprechend dann die Details meiner Recherche und Tests mitgeteilt. Um so mehr hat es mich gewundert, ehrlich gesagt, dass dann von dir keine Reaktion mehr kam.

Ich denke, ich habe für mich die Lösung gefunden, dass ich die beiden Zeilen von der startup.php in die config.php verschoben habe.

Kreativer Ansatz. Insbesondere weil sich bei einem phpBB Update die config.php ja ohnehin nicht ändert und alleine für den beabsichtigten Zweck, wäre diese Datei hervorragend prädestiniert. In dem Fall muss man nach einem phpBB Update im Core dann lediglich 2 Zeilen in der startup.php deaktivieren und fertig ist die Laube.

Hast du das schon genauer untersucht? Weil sowohl startup.php als auch config.php werden ja zu unterschiedlichen Zeitpunkten ausgeführt und ich schätze, dass der Zeitpunkt für die Definition der ErrorLevel Bitmaske relevant ist. Damit meine ich, dass durch diese Änderung hoffentlich nicht bestimmte Warnungen/Fehler ganz unter den Teppich gekehrt werden. Das ist aber aktuell nur eine Vermutung.