Unsupported operand types in Site Health

[lw5]

I get the following error:

AH01071: Got error 'PHP message: PHP Fatal error: Uncaught TypeError: Unsupported operand types: string - int in [..]/wp-admin/includes/class-wp-site-health.php:2521
Stack trace:
0 [..]/wp-admin/includes/class-wp-site-health.php(1728): WP_Site_Health->has_missed_cron()
1 [..]/wp-admin/includes/class-wp-site-health.php(192): WP_Site_Health->get_test_scheduled_events()
2 [..]/wp-admin/includes/class-wp-site-health.php(137): WP_Site_Health->perform_test()
3 [..]/wp-includes/class-wp-hook.php(307): WP_Site_Health->enqueue_scripts()
4 [..]/wp-includes/class-wp-hook.php(331): WP_Hook->apply_filters()
5 [..]/wp-includes/plugin.php(474): WP_Hook->do_action()
6 [..]/wp-admin/admin-header....', referer: https://[..]/wp-admin/

This is on a WordPress 5.9.1 multisite running on PHP 8.0.13 which was just upgraded from WP 5.5.8/PHP 7.3.33.

[azouamauriac]

Hello there, welcome to WordPress trac and thanks for the report.

Please can you confirm the issue when you downgrade PHP version under 8? Thanks.

[lw5]

When I downgrade to PHP 7.4.26 the issue turns into a warning:

Warning: A non-numeric value encountered in [..]/wp-admin/includes/class-wp-site-health.php on line 2521

[SergeyBiryukov]

Hi there, thanks for the report.

It looks like this can happen if one of the entries in the cron array is not an integer timestamp as it's supposed to be, but a non-numeric string instead.

This was fixed in [33936] / #33475 for WordPress 4.4, and a descriptive error message was added in [50143] / #49961 for WordPress 5.7. However, the current fix just means that new events cannot be scheduled with a non-numeric timestamp. If there is already an existing event like that, it remains in the array.

I'm open to suggestions on what a correct fix here would be. I think just hiding the notice in Site Health would not be ideal, we may need an upgrade routine to clean up the cron array and remove any events with an invalid timestamp.

[jrf]

Pinging @peterwilsoncc as I know he's working on improved handling of invalid entries in the cron array.

[peterwilsoncc]

Thanks for the ping, Juliette.

Currently, neither _set_cron_array() nor _get_cron_array() check the form of each entry for validity. As with the timestamp, it's also possible the event is incorrectly formatted.

A number of plugins call either the private ​_set_cron_array() function or ​directly set the cron option.

I think the safest approach is to:

• add cron to sanitize_option() to check for validity
• include _set_cron_array( _get_cron_array() ); in an upgrade routine

I do worry about the performance impact of this on sites with a large array of cron jobs as this would increase both the number of events to be validated and the frequency with which the option is updated.

[hellofromTonya]

Reviewed this ticket to determine if it is an incompatibility with PHP 8.0 and should be listed in the known incompatibilities for WP 6.3.

Findings:
This ticket is more about improving "handling of invalid entries in the cron array", rather than an incompatibility with PHP 8.0.