deprecation errors - php 8.2 / EE 7.4.9 about expressionengine HOT 4 CLOSED

@jcogs-design I'm not sure we would want to suppress errors here, then people with PHP in their templates would never know that they needed to fix a problem. It sounds like this is more an issue of some PHP code in a template needing to be updated for PHP 8.2?

from expressionengine.

For sure I don't know if supressing the error is the right thing to do - it is however a way to clean up the mess.
I'm not sure though that simply allowing the php errors (whatever they are) to bleed into the EE output is that helpful either. Sure it alerts you to there being an issue somewhere, but the errors themselves are not that useful.
A better solution perhaps would be to not simply dump inline php into an eval() function and hope for the best (which is, I find, apparently all that EE does). Maybe a better solution would be to make even a primitive attempt to trap errors arising and report them in some more useful fashion: there are plenty of mechanisms that could be used for this - simply exposing the raw output from php's eval() function is not one of them.

from expressionengine.

Few thoughts that might be helpful.

Whenever possible we encourage uses to move PHP out of templates and into plugins (new installs also require a flag in the config to enable PHP in templates). If this is an option I'd head this direction.

It's also best to set the debug level to 0 or 1 so the errors don't display publicly.

Sounds like it might be a good idea for this site to setup logging as well so the errors get recorded to the log file. (Please note, this will still capture errors if debug is set to 0)

My gut is that you would only need to use log_threshold 1 for the example above.. But it might be worth checking a few other options as well.

from expressionengine.

Thanks for the thoughts Tom. As said above I avoid using inline php and suspect the best solution for this case is simply to remove it and do the work in an add-on. More generally however I'm of the view that EE / add-ons / etc should be designed in a way that aims to avoid error handling / reporting that is uncontrolled - so exception errors or php warnings bleeding through - the php try / throw / catch / finally construct appears to make it possible to avoid such in most cases.

from expressionengine.