Repository navigation
[3.0]: Errors logged in PHP log, not SMF log #8343
Description
Basic Information
I've seen a fair amount of this, I think somewhere along the line our standard error routine gets stuffed in a locker...
I believe the most common factor is cron jobs, but one of these examples is being run via SMF\Forum->execute().
Some examples:
#8342 - Two issues, one was in the PHP log, not the SMF log; for the 2nd the error was in the .html for the export instead of any log at all.
#7898 - Error was in PHP log, not SMF log.
Steps to reproduce
- Revert [3.0] Some string recasts needed for exports #8342. Pretty simple - just remove the two "(string)" casts in Members.php.
- Run an HTML export and an XML export...
- Try & find the errors...
Expected result
All errors in the SMF log.
Actual result
Errors were in the PHP log or in the exported profile html file.
Version/Git revision
3.0 Alpha 2 - current GH
Database Engine
All
Database Version
8.4
PHP Version
8.3.8
Logs
No response
Additional Information
No response
Activity
jdarwood007 commentedon Jul 2, 2025
Your two examples are a fatal error, which isn't catchable by PHP. There are workarounds. https://stackoverflow.com/questions/277224/how-do-i-catch-a-php-fatal-e-error-error
The register_shutdown_function is not like other functions. Only the last registered function is executed, so if something else calls it after we do, it becomes the shutdown function.
There is an ob method as well that may work.
I am thinking it's not worth us trying to catch it if we are dealing with a fatal error. It may not be possible for the code to function.
sbulen commentedon Jul 2, 2025
Yeah sounds like this should be closed as not planned.
I just don't recall seeing so many errors in the PHP log vs the SMF log.
If I see one for a non-fatal error, I'll open a new issue.