TB 1.1.0 new error reporting

[smarterweb]

Hi,

in the past we where able to disable PHP notices in defines.inc but it seems this has changed now.

I found ErrorHandler.php in classes and changed line 77 from

@error_reporting(E_ALL | E_STRICT);

to

@error_reporting(E_ALL | E_STRICT & ~E_NOTICE & ~E_DEPRECATED & ~E_STRICT & ~E_WARNING);

But this has no influence. All notices still get logged. How do I disable this in latest TB?

Thanks

[Traumflug]

Messages get written for a reason: to allow fixing the issues behind them. And one should really do this. Out of the box, a thirty bees installation doesn't even create a log file.

[smarterweb]

15 hours ago, Traumflug said:

Messages get written for a reason: to allow fixing the issues behind them. And one should really do this. Out of the box, a thirty bees installation doesn't even create a log file.

Yes, I see where you are coming from - however this is almost never a real life scenario. No one runs an out-of-the box install.
We just want to disable php notices from being logged. That's all. Any idea how this can be achieved?

[datakick]

3 hours ago, smarterweb said:

Yes, I see where you are coming from - however this is almost never a real life scenario. No one runs an out-of-the box install.
We just want to disable php notices from being logged. That's all. Any idea how this can be achieved?

What you are trying to do is modify the code to NOT generate these notices/warnings. While that's valid approach, I think it would be better to tweak your web server logging to log only levels you want. So when php application emits NOTICE, it will be ignored.

[datakick]

But to answer your original question:

you can edit method ErrorHandler::errorHandler. If this method returns FALSE, then the standard error handling will take place (error or notice will be logged into server's log file). So, you should add code that (conditionally) returns true for error levels you don't want to log. You can do this for specific notices messages as well - for example, you can ignore any notice or warning raised from specific php class.

Also, please don't change core file. Use override system instead. 

[Traumflug]

10 hours ago, smarterweb said:

this is almost never a real life scenario.

The real life scenario is that one can fix all the bugs generating messages. Did this recently with a shop with no less than 103 modules of all flavors installed. Some bugs were harmless, others caused parts of the software working the wrong way.

[smarterweb]

On 8/22/2020 at 12:13 AM, Traumflug said:

The real life scenario is that one can fix all the bugs generating messages. Did this recently with a shop with no less than 103 modules of all flavors installed. Some bugs were harmless, others caused parts of the software working the wrong way.

then please tell me how to debug something like this:

PHP Notice:  Trying to get property of non-object in /home/website/vendor/smarty/smarty/libs/sysplugins/smarty_internal_templatebase.php(157) : eval()'d code on line 42

that's all I see in the log. not a hint as to what or where...

maybe we can hire you @Traumflug to do some debugging on our site? How would we go about this?

[Traumflug]

On 8/25/2020 at 2:12 AM, smarterweb said:

then please tell me how to debug something like this:

PHP Notice:  Trying to get property of non-object in /home/website/vendor/smarty/smarty/libs/sysplugins/smarty_internal_templatebase.php(157) : eval()'d code on line 42

Yes, these are hard to catch. Usually a problem with one of the used Smarty templates or PHP code loading this template.

First steps to find the issue includes finding a trigger to reproduce the problem. Which page to load to get another entry in the error log. Being able to reproduce a problem is the key to fix it.

Did you perhaps edit templates? Replace them temporarily with their originals to find out whether this changes something.

Another fairly simple procedure is to disable overrides. Does this remove the log report? Then the problem is triggered by one of the overrides.

Next step would be to disable modules until the log entry vanishes. This narrows down the problem to just this module.

Bug hunting is much like one of these early adventure games, where one had to look here and look there, collecting hints and ask questions in order to find the door to the next room. Then going on to the next room, finding more hints and more doors. At the end there is the glorious last room, where fixing just a typo magically morphs an error log entry into a newly appearing feature.

There are more expert procedures, of course, like injecting PHP debugging code or attaching a debugger. For those which feel comfortable with it. Still the same kind of adventure game, just a bit faster.

[Traumflug]

That said, if you don't feel like gaming, I'll write a PM in a minute with another solution.