Repository navigation
[2.1] Using E_USER_ERROR in trigger_error() deprecated in PHP 8.4 #9141
Description
Basic Information
E_USER_ERROR is passed to trigger_error(), indirectly, in the DB routines when preparing a backtrace. There may be other instances.
Source: https://www.php.net/manual/en/migration84.deprecated.php
See:
Line 311 in d49255b
Line 913 in d49255b
I have learned a few lessons testing #9126 that I will log separately. Pretty sure these affect both 2.1 & 3.0.
Steps to reproduce
Expected result
No response
Actual result
No response
Version/Git revision
2.1 & 3.0 Alpha 4
Database Engine
All
Database Version
No response
PHP Version
8.4
Logs
Additional Information
No response
Activity
jdarwood007 commentedon Mar 12, 2026
Only difficult part is, throwing for 2.1 may require a lot of rework. Whereas in 3.0 we can handle this (if we didn't already)
Sesquipedalian commentedon Mar 12, 2026
We did
sbulen commentedon Mar 12, 2026
I was thinking we could just return 406 or 500 instead in 2.1...
jdarwood007 commentedon Mar 12, 2026
Great, so 3.0 doesn't need fixed.
That leads me to believe that we are in a difficult spot here. The error is most likely being thrown so it can be caught by another error handler, prior to it being caught by the normal error handler. I think such cases are out of the box where the upgrader.
We may be able to change to E_USER_WARNING, but it's possible that anything checking for it to be strictly E_USER_ERROR would fail.
[-][2.1 & 3.0] Using E_USER_ERROR in trigger_error() deprecated in PHP 8.4[/-][+][2.1] Using E_USER_ERROR in trigger_error() deprecated in PHP 8.4[/+]jdarwood007 commentedon Oct 24, 2026
This only affects 2.1 since we already switched over to exceptions for 3.0