Hallo zusammen,
neuerdings sind beim "error handling" die "Warnings" unabwählbar aktiviert.
Warum ist das so? Wieso wird dem Admin vorgeschrieben, was geloggt wird?
Gibt es eine Möglichkeit, das zu deaktivieren?
Bei der Fehlersuche sind die "Warnings", wenn man sie sich anzeigen lässt, extrem hinderlich.
Vielen Dank.
Michael
Error handling: Warnings deaktivieren
Re: Error handling: Warnings deaktivieren
Moin Michael,
ich würde dringend davon abraten Warnings zu deaktivieren.
Dinge wie z.B. depricated Tags werden dir nicht mehr geloggt und führen dann spätestens bei Updates zu Fehlern.
Gleiches gilt für eine Menge an anderen Warnings, die über kurz oder lang zu einem Error werden.
LG
Finn
ich würde dringend davon abraten Warnings zu deaktivieren.
Dinge wie z.B. depricated Tags werden dir nicht mehr geloggt und führen dann spätestens bei Updates zu Fehlern.
Gleiches gilt für eine Menge an anderen Warnings, die über kurz oder lang zu einem Error werden.
LG
Finn
Re: Error handling: Warnings deaktivieren
Den Rat kann ich nachvollziehen und auch unterstützen, aber die Entscheidung sollte doch eher beim Admin liegen.
Re: Error handling: Warnings deaktivieren
Wenn der Admin sauber arbeitet, dann gibt es keine Warnungen und er braucht sie nicht deaktivieren.
Die Entscheidung ist auch u.a. deshalb weil viele schrieben das sie nichts im Log sehen wenn Fehler auftreten. Und auch viele Infos von WE in Warnungen stecken.
Die Entscheidung ist auch u.a. deshalb weil viele schrieben das sie nichts im Log sehen wenn Fehler auftreten. Und auch viele Infos von WE in Warnungen stecken.
webEdition-Kern-Entwickler
Re: Error handling: Warnings deaktivieren
Lieber Finn, lieber Marc,
das ist natürlich alles korrekt und das sehe ich genauso. Aber wenn man vor lauter "Warnings" die "Errors" nicht sieht ist das kontraproduktiv und ich finde es ehrlich gesagt ein Unding, dass ein System (egal welches) einem Admin so etwas vorschreibt. Wohlgemerkt einem ADMIN! Wie werden eigentlich derartige Entscheidungen gefällt?
Stellt euch vor, es kommt auch mitunter vor, dass mein ein Projekt von anderen Entwicklern übernimmt und da kann man erst einmal nichts für den Code. Wer bezahlt dann den zusätzlichen Aufwand, der durch die Unübersichtlichkeit des sog. "error handling" (eher "warning und deprecated handling") verursacht wird? Wenn es Probleme gibt und man debuggen muss sollte ein echter Admin natürlich auch auf die Warnings schauen (indem er dies aktiviert). Das erwarte ich von einem Admin. Aber dass das System ihm das vorschreibt geht gar nicht, nur weil manche Admins das nicht machen. Es sollte genügen sie darauf hinzuweisen.
Ihr macht echt alle eine Hammer-Job. Aber diese Entscheidung, die einem Admin die Entscheidungsfreiheit nimmt, enttäuscht mich sehr.
Gibt es nun eine Möglichkeit, die "warnings" zu deaktivieren oder nicht?
Grüße
Michael
P.S. @Finn: Beim "error handling" wird doch ausdrücklich zwischen "warnings" und "deprecated Notices" unterschieden, die man leider auch nicht deaktivieren kann.
das ist natürlich alles korrekt und das sehe ich genauso. Aber wenn man vor lauter "Warnings" die "Errors" nicht sieht ist das kontraproduktiv und ich finde es ehrlich gesagt ein Unding, dass ein System (egal welches) einem Admin so etwas vorschreibt. Wohlgemerkt einem ADMIN! Wie werden eigentlich derartige Entscheidungen gefällt?
Stellt euch vor, es kommt auch mitunter vor, dass mein ein Projekt von anderen Entwicklern übernimmt und da kann man erst einmal nichts für den Code. Wer bezahlt dann den zusätzlichen Aufwand, der durch die Unübersichtlichkeit des sog. "error handling" (eher "warning und deprecated handling") verursacht wird? Wenn es Probleme gibt und man debuggen muss sollte ein echter Admin natürlich auch auf die Warnings schauen (indem er dies aktiviert). Das erwarte ich von einem Admin. Aber dass das System ihm das vorschreibt geht gar nicht, nur weil manche Admins das nicht machen. Es sollte genügen sie darauf hinzuweisen.
Ihr macht echt alle eine Hammer-Job. Aber diese Entscheidung, die einem Admin die Entscheidungsfreiheit nimmt, enttäuscht mich sehr.
Gibt es nun eine Möglichkeit, die "warnings" zu deaktivieren oder nicht?
Grüße
Michael
P.S. @Finn: Beim "error handling" wird doch ausdrücklich zwischen "warnings" und "deprecated Notices" unterschieden, die man leider auch nicht deaktivieren kann.
Re: Error handling: Warnings deaktivieren
Moin Michael,
so eine Änderung erfolgte nicht einfach aus Spaß.
In der Praxis hat das bisher nicht funktioniert:
webEdition wird nun mal von einer Vielzahl an Personen mit unterschiedlichen technischen Kenntnisständen eingesetzt. Das "erzwingen" der Warnings und dep. Notices erleichtert den Support für uns enorm.
Ich habe bisher in über 100 Installationen nicht das Gefühl gehabt, das mich warnings beim debuggen einschränken. Im Gegenteil ist mir daran gelegen diese zu beheben. Mir ist auch ansonsten bisher keine andere Person bekannt, die sich an den Warnings gestört hat.
Wie gesagt, für viele Personen die nicht so affin mit dem CMS sind, ist es wichtig die Warnings drin zu haben, wir sind immer noch ein barrierearmes CMS.
Was ich mir vorstellen könnte, wären Filter die die Warnungen ausblenden um schneller durch die Bugs zu navigieren.
so eine Änderung erfolgte nicht einfach aus Spaß.
In der Praxis hat das bisher nicht funktioniert:
Ist eine romantische Vorstellung, hat aber wie gesagt nicht gut funktioniert und erschwert den Support bei einem sowieso schon sehr kleinen Team. Die Zeit die wir sparen, kann für entwicklung genutzt werden, ist eine ganz einfache Rechnung.Wenn es Probleme gibt und man debuggen muss sollte ein echter Admin natürlich auch auf die Warnings schauen (indem er dies aktiviert).
Das erwarte ich von einem Admin. Aber dass das System ihm das vorschreibt geht gar nicht, nur weil manche Admins das nicht machen. Es sollte genügen sie darauf hinzuweisen.
webEdition wird nun mal von einer Vielzahl an Personen mit unterschiedlichen technischen Kenntnisständen eingesetzt. Das "erzwingen" der Warnings und dep. Notices erleichtert den Support für uns enorm.
Ich habe bisher in über 100 Installationen nicht das Gefühl gehabt, das mich warnings beim debuggen einschränken. Im Gegenteil ist mir daran gelegen diese zu beheben. Mir ist auch ansonsten bisher keine andere Person bekannt, die sich an den Warnings gestört hat.
Wie gesagt, für viele Personen die nicht so affin mit dem CMS sind, ist es wichtig die Warnings drin zu haben, wir sind immer noch ein barrierearmes CMS.
Was ich mir vorstellen könnte, wären Filter die die Warnungen ausblenden um schneller durch die Bugs zu navigieren.
-
- webEdition Partner
- Beiträge: 1825
- Registriert: Di 7. Mär 2006, 16:50
- Wohnort: Wien
- Kontaktdaten:
Re: Error handling: Warnings deaktivieren
Hey,
Finns Vorschlag das filterbar zu machen, finde ich grundsätzlich gut und würde die Situation sicherlich entschärfen.
Grundsätzlich finde ich die Entscheidung aber auch sehr fragwürdig. Wir haben auf Produktivsystemen idR nur Errors aktiviert. Auf Staging und Dev Systemen wird alles geloggt. Das möchte ich eigentlich auch so beibehalten können.
Cheer,
Sascha
Finns Vorschlag das filterbar zu machen, finde ich grundsätzlich gut und würde die Situation sicherlich entschärfen.
Grundsätzlich finde ich die Entscheidung aber auch sehr fragwürdig. Wir haben auf Produktivsystemen idR nur Errors aktiviert. Auf Staging und Dev Systemen wird alles geloggt. Das möchte ich eigentlich auch so beibehalten können.
Cheer,
Sascha
Re: Error handling: Warnings deaktivieren
Lieber Finn,
wie bereits oben geschrieben kann ich (fast) alles nachvollziehen, nur eben nicht, dass man eine Admin-Entscheidung dem Admin abnimmt bzw. ihm eine Entscheidung aufzwingt. Wieso aktiviert ihr nicht einfach die "warnings" standardmäßig, gebt dem Admin aber die Möglichkeit, diese Admin-Einstellung zu ändern?
Mir geht es ja auch nicht darum, dass diese geloggt werden. Es geht um die Anzeige der "Fehler" im Frontend, die wir gerade immer wieder für den Umstieg von 8 zu 9 und von PHP 7.4 auf 8.1 nutzen. Erste Prio hat hierbei die Lösung der echten Fehler, zweite Prio die "warnings" und "deprecated warnings". Natürlich könnte man sich die "Fehler" auch im Backend oder direkt in der Datenbank anschauen und dort ja auch filtern.
Und nochmal meine Frage: "Gibt es nun eine Möglichkeit, die "warnings" zu deaktivieren oder nicht?" Gerne auch per private Nachricht hier, wenn ihr nicht möchtet, dass so eine Möglichkeit allen Nutzern des CMS zur Verfügung stehen.
Vielen Dank und schöne Grüße
Michael
wie bereits oben geschrieben kann ich (fast) alles nachvollziehen, nur eben nicht, dass man eine Admin-Entscheidung dem Admin abnimmt bzw. ihm eine Entscheidung aufzwingt. Wieso aktiviert ihr nicht einfach die "warnings" standardmäßig, gebt dem Admin aber die Möglichkeit, diese Admin-Einstellung zu ändern?
Davon gehe ich auch aus.so eine Änderung erfolgte nicht einfach aus Spaß.
Kommen seit dieser Umstellung tatsächlich weniger Support-Anfragen?Die Zeit die wir sparen, kann für entwicklung genutzt werden, ist eine ganz einfache Rechnung.
Mir geht es ja auch nicht darum, dass diese geloggt werden. Es geht um die Anzeige der "Fehler" im Frontend, die wir gerade immer wieder für den Umstieg von 8 zu 9 und von PHP 7.4 auf 8.1 nutzen. Erste Prio hat hierbei die Lösung der echten Fehler, zweite Prio die "warnings" und "deprecated warnings". Natürlich könnte man sich die "Fehler" auch im Backend oder direkt in der Datenbank anschauen und dort ja auch filtern.
Und nochmal meine Frage: "Gibt es nun eine Möglichkeit, die "warnings" zu deaktivieren oder nicht?" Gerne auch per private Nachricht hier, wenn ihr nicht möchtet, dass so eine Möglichkeit allen Nutzern des CMS zur Verfügung stehen.
Also geht ihr von stillschweigender Zustimmung aus? Nur weil sich niemand dazu meldet heißt es m.E. nicht, dass sich niemand daran stört. In diesem Thread sind es nun schon drei, die sich an den "warnings" stören. Ich bin mir sicher, dass es noch einige mehr gibt, die es aber vielleicht einfach resigniert akzeptieren, so wie ich jetzt wohl auch.Mir ist auch ansonsten bisher keine andere Person bekannt, die sich an den Warnings gestört hat.
Vielen Dank und schöne Grüße
Michael
Re: Error handling: Warnings deaktivieren
Code: Alles auswählen
Kommen seit dieser Umstellung tatsächlich weniger Support-Anfragen?
webEdition ist ein Open Source System, mit (das dürfte hier allen klar sein) sehr begrenzten Mitteln im Bereich Entwicklungspower und Support. Das ist ein Versuch ein kleines Bisschen an Support Zeit zu sparen. Und wenn es nur die Rückfrage spart, ob man denn mal die Warnings im Log aktiviert hat und ob die dep. Hinweise gelesen wurden.
Open Source bedeutet aber auch, alle können gestalten und mitwirken. Davon lebt das System und das macht es längerfristig besser.
Also sehr gerne dazu einen entsprechenden FR. Im FR Bereich des Forums, eventuell lässt sich in dem Zuge ja auch generell das Debugging verbessern. Ich z.B. nutze nur das Backend-Log und gebe nichts im Frontend aus. Je nach Arbeitsweise können hier durchaus unterschiedliche Bedürfnisse entstehen.
Code: Alles auswählen
Und nochmal meine Frage: "Gibt es nun eine Möglichkeit, die "warnings" zu deaktivieren oder nicht?" Gerne auch per private Nachricht hier, wenn ihr nicht möchtet, dass so eine Möglichkeit allen Nutzern des CMS zur Verfügung stehen.
Re: Error handling: Warnings deaktivieren
Naja, das ist jetzt kein wirkliches Novum von webEdition - wir müssen im Backend viele Sachen entscheiden und wollen auch nicht 1000 Optionen bauen. Wir treffen da einige Entscheidungen, die auch mit Sicherheit zu tun haben und auch Admin Entscheidungen sind und trotzdem auf vielen Systemen falsch eingestellt sind. Das macht auch jedes Betriebssystem - auch hier wird normal "alles" geloggt.dass man eine Admin-Entscheidung dem Admin abnimmt
Fehler anzeigen im Frontend halte ich für keine gute Idee; im Testsystem kann man das mal machen - aber auch hier würde ich mail oder Log empfehlen. Und sicher sind "Fehler" wichtiger, aber bspw. deprecated sollte man direkt mitbeheben, denn was in 8.1 deprecated ist, ist in 8.2 ein Fehler. Fast jede Warning weißt auf einen potentiellen Fehler hin, Sicherheitsproblem o.ä.; selbst Notices sollte man ernst nehmen. Hierüber kann man auch Angriffsversuche usw. erkennen. Sind also im Falle eines größeren Problems essentiell wichtig um im Nachhinnein etwas über ein Problem herauszubekommen. Und was nicht geloggt ist, läßt sich später auch nicht mehr herausholen. Dann ist das Kind eben in den Brunnen gefallen.
Daher macht es auch Sinn die Systeme auch Produktiv nicht nur auf Fehler zu monitoren, und auch alle Meldungen ernst zu nehmen - das ist anfangs ein Aufwand. Man kann sich aber durch den Einsatz von bpsw. Phan https://github.com/phan/phan ziemlich helfen lassen und die Fehler/Probleme finden und im Vorfeld korrigieren. Da ist man nicht darauf angewiesen nur im Nachhinnein zu reagieren.
webEdition-Kern-Entwickler
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast