Thanks for the report.

Did you actually face a situation where this caused a problem ? If so it would be good to have some details about your use case.

1. Extend mantis per plugin to allow filtering
2. Go to view_all_bug_page.php, you should see this field.
3. Click on this field to filter. You receive HTTP Error

Extend mantis per plugin to allow filtering

This is not clear, what do you mean ?

class ....Filter extends MantisFilter {

class ....Plugin extends MantisPlugin {

public function hooks() {
    return array(
        'EVENT_FILTER_FIELDS' => 'filterFields',

public function filterFields() {
return array(
        '...Filter'
    );

Now is clearer?

Yes thank you.

Does your plugin make use of the @ operator ? Or is the offending call coming from a Mantis core function ? If so, which one(s) ?

A stack trace would help, or even better a reproducible test case so I can get a good understanding of the problem.

but @ has nothing here to do.
in return_dynamic_filter there is a call:

$t_content = @call_user_func_array( 'filter_form_get_input', array( $t_filter, $filter_target, true ) );

in filter_form_api there is a function filter_form_get_input:

    if( function_exists( $t_function_name ) ) {
        ob_start();
        call_user_func_array( $t_function_name, $t_params );
        return ob_get_clean();
    } else {
        # error - no function to populate the target (e.g., print_filter_foo)
        error_parameters( $p_filter_target );
        trigger_error( ERROR_FILTER_NOT_FOUND, ERROR );
        return false;
    }

In my case the function $t_function_name doesn`t exist, so the error is thrown - trigger_error( ERROR_FILTER_NOT_FOUND, ERROR );.
Then it is catched by error_handler and in this function:

    # check if errors were disabled with @ somewhere in this call chain
    if( !( error_reporting() & $p_type ) ) {
        return;
    }

Before PHP 8.0 it worked, becasue error_reporting() was 0 in case of @, but since PHP 8.0, error_reporting is: E_ERROR | E_CORE_ERROR | E_COMPILE_ERROR | E_USER_ERROR | E_RECOVERABLE_ERROR | E_PARSE so the condition in if is not fullfulled and we don`t immediately exit a function, but the error is being handled furthermore.
That is a difference between PHP < 8.0 and >= 8.0

Sorry but I'm still not seeing the whole picture...

but @ has nothing here to do.
in return_dynamic_filter there is a call:

$t_content = @call_user_func_array( 'filter_form_get_input', array( $t_filter, $filter_target, true ) );

But it does... Notice the @ before the call_user_func_array() ?

Anyway more importantly, which release of MantisBT are you using ?

I would guess it's an older, unsupported version because this code was removed in June 2021 (replaced by a try/catch block) and released in 2.25.2, see 0028803. So your problem appears to be a duplicate of that.

then sorry for bothering. We were using 2.25.0, after upgrade the error disappeared. I thought PHP 8.0 is fully tested with 2.25.0

Thanks for the feedback.

You should always upgrade to the latest hotfix for a given release, to benefit from bug and security fixes.
And of course, please make sure to test with it (or a nightly build) before reporting a bug here ;-)

Anyway, good to hear that your problem is solved.