PHP 8.2 > Backend fatal error: PHP Fatal error: Uncaught TypeError

[mackaaij]

I tried to upgrade to PHP 8.2 and my site displayed a critical error. Downgraded and found this in the error log. I'm not sure which component this applies to. Happy to look for more info when needed.

[Sat Jan 21 18:55:25.535143 2023] [lsapi:error] [pid 2731617:tid 140286197896960] 
[client [redacted]:61727] [host ] Backend fatal error: PHP Fatal error:  Uncaught TypeError: session_start():
Argument #1 ($options) must be of type array, string given in [redacted]/wp-includes/class-wp-hook.php:308\n
Stack trace:\n
#0 [redacted]/wp-includes/class-wp-hook.php(308): session_start()\n
#1 [redacted]/wp-includes/class-wp-hook.php(332): WP_Hook->apply_filters()\n
#2 [redacted]/wp-includes/plugin.php(517): WP_Hook->do_action()\n
#3 [redacted]/wp-settings.php(617): do_action()\n
#4 [redacted]/wp-config.php(86): require_once('[redacted]...')\n
#5 [redacted]/wp-load.php(50): require_once('[redacted]...')\n
#6 [redacted]/wp-blog-header.php(13): require_once('[redacted]...')\n
#7 [redacted]/index.php(17): require('[redacted]...')\n
#8 {main}\n  thrown in [redacted]/wp-includes/class-wp-hook.php on line 308\n

[SergeyBiryukov]

Hi there, welcome back to WordPress Trac! Thanks for the report.

Based on the error log, the issue comes from a session_start() call with an incorrect $options parameter (a string instead of an array). WordPress core does not use that function, so it's likely called in a plugin or theme.

Does the issue still happen with all plugins disabled and a default theme (Twenty Twenty-Three) activated?

[mackaaij]

Thanks for your quick reply, Sergey!

I filed the report over here as the stack trace seems to list only WordPress files (no plugin / theme). Any idea how to get to the .php causing the fatal error?

It's not easy for me to disable plugins and switch the theme on this specific site, so I hope you have another suggestion.

If there is no other way, feel free to close this issue. I'll look for a solution later after narrowing down the issue down by disabling plugins and switching the theme as you suggested.

[SergeyBiryukov]

Replying to mackaaij:

I filed the report over here as the stack trace seems to list only WordPress files (no plugin / theme).

Right, but it points to WP_Hook::apply_filters()​, which only executes code from plugins or themes and does not itself contain the problematic session_start() call.

Any idea how to get to the .php causing the fatal error?

Code like this, when run in a plugin or a mu-plugin, should display information about the current filter, priority, and the attached callbacks after the fatal error happens:

register_shutdown_function( 'handle_php_fatal_error' );

function handle_php_fatal_error() {
	global $wp_filter;

	$last_error = error_get_last();

	if ( $last_error['type'] === E_ERROR ) {
		$wp_hook  = $wp_filter[ current_filter() ];
		$priority = $wp_hook->current_priority();

		echo '<pre>';
		echo 'Current filter: ' . current_filter() . "\n";
		echo 'Current priority: ' . $priority . "\n";

		echo 'Callbacks: ';
		print_r( array_keys( $wp_hook->callbacks[ $priority ] ) );
		echo '</pre>';
	}
}

For example, this is what I get after simulating a fatal error with add_filter( 'the_content', 'session_start' ):

Current filter: the_content
Current priority: 10
Callbacks: Array
(
    [0] => wptexturize
    [1] => wpautop
    [2] => shortcode_unautop
    [3] => prepend_attachment
    [4] => wp_filter_content_tags
    [5] => wp_replace_insecure_home_url
    [6] => session_start
)

The displayed function names could then be used to search for the PHP file causing the error.

Alternatively, just searching for session_start in the installed plugins and active theme would be a good first step.

It's not easy for me to disable plugins and switch the theme on this specific site, so I hope you have another suggestion.

I would suggest creating a copy of the site for testing and troubleshooting, that way it should be easier to track down the issue than working with a live site directly.

[mackaaij]

Thanks for taking time for this informative reply, Sergey!

I've found one weird call to session_start in my files using:
grep -rnw './' -e 'session_start'

It was in a plugin called ​WP Spam Fighter which has been closed due to a security issue in 2021 so I removed it. Somebody did post a solution to the warning a few months back:
​https://wordpress.org/support/topic/solution-for-php-error-in-class-wp-hook/

[SergeyBiryukov]

Thanks for the follow-up!