| Description | On PHP 8.4, MantisBT 2.28.x displays error messages with empty parameters. For example, when I open a non-existent issue, I get Issue "0" not found. instead of the id I requested. I first noticed it in a plugin I maintain (Calendar): plugin_error() preceded by error_parameters() shows the same "0", so both core and plugin errors are affected.
Cause: in PHP 8.4, trigger_error( ..., E_USER_ERROR ) first emits an E_DEPRECATED ("Passing E_USER_ERROR to trigger_error() is deprecated since 8.4, ..."), and only then the actual error. Both go through error_handler(). After handling the deprecation notice, error_handler() resets $g_error_parameters = array() at its end. So when the real E_USER_ERROR arrives, the parameters are already gone: vsprintf() receives empty strings, %d placeholders render as 0 and %s ones as empty. |
|---|
| Steps To Reproduce | Run MantisBT 2.28.4 on PHP 8.4.
Log in and open view.php?id=99999 (a non-existent issue).
The error reads Issue "0" not found.
With the same code on PHP 8.3, the message is correct: Issue "99999" not found.
Minimal PHP reproduction of the double handler call:
<?php
set_error_handler( function( $t, $m ) { echo $t, ' ', $m, PHP_EOL; return true; } );
trigger_error( 'X', E_USER_ERROR );
// PHP 8.4:
// 8192 Passing E_USER_ERROR to trigger_error() is deprecated since 8.4, throw an exception or call exit with a string message instead
// 256 X
// PHP 8.3:
// 256 X |
|---|
| Additional Information | As far as I can tell, this is fixed in master as part of 0036812, in particular by commit 7c8b6b92b "Treat $g_error_parameters as a stack". I am filing this separately because 0036812 and its duplicate 0037353 describe only the deprecation notice, not this user-visible symptom.
2.28.x officially supports PHP 8.4 (0035216 was fixed in 2.28.0, and PHP_MAX_VERSION is not set), yet its child 0036812 was only fixed in 2.29.0. So every 2.28.x installation on a supported PHP version shows wrong error messages. Would you consider backporting the fix, or at least the $g_error_parameters part of it, to 2.28.x?
Cherry-picking 7c8b6b92b alone would not work on 2.28, since it relies on error_string() consuming the parameters it uses (905f74e51). A minimal fix for 2.28 could be to keep $g_error_parameters when error_handler() handles an E_DEPRECATED:
if( $p_type != E_DEPRECATED ) {
$g_error_parameters = array();
}
If you are interested, I would be glad to submit a PR against master-2.28 with this change, tested on 2.28.4 with PHP 8.4. |
|---|
related to
child of
duplicate of
