Disable site health

[adamziel]

MySQL is not available in the WASM runtime so /wp-admin/site-health.php displays the below error. Let's disable site-health.php entirely for now.

Fatal error: Uncaught Error: Call to undefined function mysql_get_server_info() in /preload/wordpress/wp-admin/includes/class-wp-site-health.php:2 Stack trace: #0 /preload/wordpress/wp-admin/includes/class-wp-site-health.php(2): WP_Site_Health->prepare_sql_data() #1 /preload/wordpress/wp-admin/includes/class-wp-site-health.php(2): WP_Site_Health->get_test_sql_server() #2 /preload/wordpress/wp-admin/includes/class-wp-site-health.php(2): WP_Site_Health->perform_test(Array) #3 /preload/wordpress/wp-includes/class-wp-hook.php(2): WP_Site_Health->enqueue_scripts('site-health.php') #4 /preload/wordpress/wp-includes/class-wp-hook.php(2): WP_Hook->apply_filters(NULL, Array) #5 /preload/wordpress/wp-includes/plugin.php(2): WP_Hook->do_action(Array) #6 /preload/wordpress/wp-admin/admin-header.php(17): do_action('admin_enqueue_s...', 'site-health.php') #7 /preload/wordpress/wp-admin/site-health.php(2): require_once('/preload/wordpr...') #8 php-wasm run script(90): require_once('/preload/wordpr...') #9 {main} thrown in /preload/wordpress/wp-admin/includes/class-wp-site-health.php on line 2

[adamziel]

Could be useful (props to @dd32):

It looks like removing the view_site_health_checks cap can be done, by removing this function:
https://developer.wordpress.org/reference/functions/wp_maybe_grant_site_health_caps/
add_filter( 'user_has_cap', 'wp_maybe_grant_site_health_caps', 1, 4 );

[swissspidy]

I was very confused that Site Health was disabled/missing. Can this be reconsidered? Maybe we can patch core to add a function_exists check?

[dd32]

The main issue was that Site Health expects to be running within a fully functional hosting environment, which while the WASM is mostly a fully functional PHP environment, it's actually a pretty limited hosting environment.

At the time, loopback http requests was also failing (as HTTP requests weren't supported), which caused a bunch of issues.

Ultimately, that would throw a whole bunch of warnings about how bad the hosting environment was :)

I'd recommend running it locally (That's not a hard thing to do) and disable the site health disabler, and work through anything that it flags up.

[GaryJones]

As of wp-now 0.1.54, the Site Health option is still available in the admin menu:

Though it gives the following error:

Fatal error: Uncaught TypeError: property_exists(): Argument #1 ($object_or_class) must be of type object|string, array given in /var/www/html/wp-content/plugins/sqlite-database-integration/wp-includes/sqlite/class-wp-sqlite-translator.php:2427 

[eliot-akira]

The error is a known issue, as reported here:

• Critical error on site health screen sqlite-database-integration#37

And a pull request that aims to solve it:

• Update class-wp-sqlite-translator.php sqlite-database-integration#40

[adamziel]

As of wp-now 0.1.54, the Site Health option is still available in the admin menu:

Though it gives the following error:

Fatal error: Uncaught TypeError: property_exists(): Argument #1 ($object_or_class) must be of type object|string, array given in /var/www/html/wp-content/plugins/sqlite-database-integration/wp-includes/sqlite/class-wp-sqlite-translator.php:2427 

To add to @eliot-akira’s response, this issue was about disabling site health in the in-browser version of Playground. It is not disabled in Wp-now as wp-now supports mysql