Allow "Persistent Object Cache" and other Site Health options to be dismissable with a checkbox

[carlh04426]

I keep everything up-to-date on my self-maintained hosting servers, which are already extremely fast (including 10G NICs) and stable, and -- apparently up until now, according to Site Health Status -- secure.

I do not need or want to install a "1 recommended improvement" anything ... in this case, it complains about no "persistent object cache."

This "recommendation" badly needs a "dismiss" checkbox so we can avoid alarming our overly sensitive clients, who are prone to worry about *anything* they see listed on the Dashboard under the heading "Site Health Status."

Thank you

### wp-core ###

version: 6.1
site_language: en_US
user_language: en_US
timezone: +00:00
permalink: /%year%/%monthnum%/%postname%.html
https_status: true
multisite: false
user_registration: 0
blog_public: 1
default_comment_status: open
environment_type: production
user_count: 2
dotorg_communication: true

### wp-dropins (1) ###

advanced-cache.php: true

### wp-plugins-active (8) ###

Akismet Anti-Spam: version: 5.0.1, author: Automattic
Classic Editor: version: 1.6.2, author: WordPress Contributors
Contact Form 7: version: 5.6.4, author: Takayuki Miyoshi
Google XML Sitemaps: version: 4.1.5, author: Auctollo
To Top: version: 2.5.1, author: Catch Plugins
Ultimate Under Construction page: version: 1.9.2, author: HappyKite, Morrowmedia
WP Super Cache: version: 1.9.1, author: Automattic
XMLRPC Attacks Blocker: version: 1.0, author: Yehuda Hassine

### wp-server ###

server_architecture: Linux 5.4.0-131-generic x86_64
httpd_software: Apache
php_version: 7.4.3 64bit
php_sapi: cgi-fcgi
max_input_variables: 1000
time_limit: 40
memory_limit: 128M
admin_memory_limit: 256M
max_input_time: 60
upload_max_filesize: 2M
php_post_max_size: 8M
curl_version: 7.68.0 OpenSSL/1.1.1f
suhosin: false
imagick_availability: true
pretty_permalinks: true
htaccess_extra_rules: true

### wp-database ###

extension: mysqli
server_version: 8.0.31-0ubuntu0.20.04.1
client_version: mysqlnd 7.4.3
max_allowed_packet: 1048576
max_connections: 151

[brookedot]

Hi there, welcome to trac!

I'm not sure that Health Check was designed in such a way to add a checkbox, instead items can be added/removed/or manipulated with filters.

For example, by filtering site_status_tests you can remove the page_cache test:
​https://developer.wordpress.org/reference/hooks/site_status_tests/

function wp_health_cache_57005_remove_test( $tests ) {
	unset( $tests['async']['page_cache'] );
	unset( $tests['direct']['persistent_object_cache'] );
	return $tests;
}
add_filter( 'site_status_tests', 'wp_health_cache_57005_remove_test' );

You'll find a full lists of tests here:
​https://github.com/WordPress/WordPress/blob/3596d1a534182173e0a723b8872290057918b825/wp-admin/includes/class-wp-site-health.php#L2512-L2645

I think we should mark this as a "won't fix" but gonna CC:// @Clorith for a second option as they are closer to the Site Health feature than I am.

[BandonRandon]

Actually, on further investigation I found the site_status_should_suggest_persistent_object_cache filter specifically for disabling the suggestion of persistent_object_cache
​https://developer.wordpress.org/reference/hooks/site_status_should_suggest_persistent_object_cache/

You'll find more on that filter in the Make Blogs and think it's what you are looking for:
​https://make.wordpress.org/core/2022/10/06/new-cache-site-health-checks-in-wordpress-6-1/

Gonna close this as wontfix for now.

[carlh04426]

Thank you for your rapid responses, @brookedot and @BandonRandon, as well as for the links and code! :)

I really did spend quite a lot of time last night searching for just this information prior to opening a ticket.

In the event that any of the maintainers are still interested in my opinion, I would suggest that website admins should _not_ be _forced_ to touch a single line of code just to filter out a "recommendation," nor should they need to open a ticket at their hosting company.

The ripple effects introduced by simple changes such as these can sometimes have deep and extremely costly unintended consequences.

Thanks again! :)

Carl

[tigertech]

As someone who runs a hosting company: I would very much like a way to suppress this and similar messages using environment variables (not code). It could be similar to the way ​WP_UPDATE_PHP_URL works, but with the ability completely suppress the test (not just change the recommendation link, although that would also be good).

Why can't we use a filter to suppress the warning? Because we allow people to install their own copies of WordPress that don't use our plugin, so we can't force filters on everyone.

More generally, I think that site health suggestions that:

a) aren't security risks and
b) can't or shouldn't necessarily even be used on this server

... should always be filterable with environment settings.

In our case, we do offer memcache, but I don't want customers using the suggested plugin on ​the page it links to because it's buggy.

So the situation is that WordPress 6.1 is showing some people a link to a ​page that tells people "ask your hosting provider", only for many hosting companies to tell them "ignore that recommendation, we think it's bad advice". That's a poor use of people's time and doesn't build trust in either the hosting company or WordPress.

When this new health recommendation was added, the author clearly realized that some people would want to suppress it, because the filtering option to do that was included. That's great, but not everyone can force filters on their customers. Adding a check of an environment variable, too, would be much appreciated for any performance-based recommendations. (I'd be happy to provide a patch for this if it might be accepted.)