anotherdave

I couldn’t review the plugin since I don’t use it (a client of mine does) but I rated your support 🙂

4.7.3 definitely resolved the issue.

iThemes Security reports 4.7.2 as vulnerable to CSRF as well.

@terry777 – it’s not just you. I manage over 100 sites all on the same server, all fully SSL secured, and for no apparent reason on at least 8 if them the mute button doesn’t display / doesn’t work even when the hidden mute link is clicked. All of the sites in question are running iTsec Pro / paid version. I’ve just spent 2 days muting this like crazy and cannot find any clue as to why on some sites the mute simply does not work. I’m checking server / PHP error logs and comparing sites hoping to spot something that would explain this behavior, and if/when I day I’ll post the info here.

This false-positive just started occurring last night on all of the sites I manage as well. Both free version and Pro / Paid version. Regardless of the fact that on most I have XMLRPC and Pingbacks / Trackbacks disabled, doesn’t matter – iThemes thinks the latest version of WordPress 6.1.1 is vulnerable. Crazy.

This new page_cache check introduced to production in WordPress 6.1 Site Health Check is generating nothing but headaches and support requests from users whose WordPress sites are working perfectly fine / loading fine without caching plugins, even regardless of whether a server is running something like LiteSpeed and even regardless of whether the result contains “server response time is slow” or “server response time is OK”.

The fact that is displayed as “Critical” in the Site Health Check results is already beginning to cause frenzy of WP site owners to now think that there’s something wrong when there isn’t, and resulting in some of them blaming ANY issue with their WP site on this new addition to the Health Check.

I’ve received at least 8 client requests to “fix” something that isn’t broken during the last 48 hours just because of this new check.

The fact is, if someone is running a shared hosting server environment for WP users, and that environment is deliberately left “plain vanilla” without any extra caching or CDN or Varnish or other (unnecessary in cases of a proper server config), then all users on that server are going to see this “Critical” warning in Site Health Checks, and they’re either going to think something has gone wrong with their WP or that there’s a problem where no problem exists.

In many cases, the user / site owner will scramble to download and install an unnecessary cache plugin, thinking that they’re going to fix a problem that isn’t there.

Again, this notice / warning shows up under “Site Health Status” as “Critical” for no reason at all on properly working servers and WP sites.

Observation so far – the difference between the “server response time is slow” or “server response time is OK” actually has nothing to do with the server, and everything to do with how well or poorly the user has handled their WP site management – especially when it comes to how many plugins / editors / etc they have installed. I’ve been doing some comparisons, and on the SAME EXACT server the results of this “check” differ from site to site based on just how much bloat the user has allowed their WP database and excess plugins to accumulate. I can view right this minute / compare two sites right this minute on the same server, and even large sites with much more content & features will say “server response time is OK” when their WP has been well maintained vs even small sites with barely much content but tons of excess plugins giving a “server response time is slow” result on this new page_cache check.

Meanwhile all sites I’ve examined in regard to this are loading fast and running well as they have been for years before this new site check addition / before WordPress 6.1

There are many cases in which cache is NOT a good thing for particular sites, and in which it is GOOD that the hosting / server environment is “plain vanilla” in order to accommodate a wide variety of clientele along with their specific usage & needs.

But now we have this lovely “Critical” site health status upon check, along with users now installing cache plugins that they absolutely do not need (and in several cases to their detriment).

There are past examples of other new Site Health Check additions that were proven to be either useless or even semi-consequential, but I’ll leave my input as this for now…

Another “addition” to our collective migraine headaches. 🙁