Tim Reeves

Thanks Mehmet, what follows is the reply from the Author of “WP Crontrol”:

John Blackbourn wrote: Thanks for the report. This is due to the WP Statistics plugin only adding callbacks for its cron events when the request is not a request to the admin area. In the code you posted above, the calls to add_action are contained within a guard condition so the code only runs when !Request::isFrom(‘admin’) is true. This means that when you look at the Cron Events screen in the admin area, those events don’t actually have any actions registered and WP Crontrol is correct. Only when the code runs in a request that isn’t to the admin area do those events have callbacks registered. This is covered by the “Conditionally registered actions” section in the WP Crontrol documentation ( https://wp-crontrol.com/help/no-action-cron-events/#conditionally-registered-actions ), although this is the first time I’ve ever seen a plugin use a conditional check for an admin area request. That was a long way of saying that WP Statistics should move those add_action calls out of the !Request::isFrom(‘admin’) guard condition. There’s no reason for that code to be conditional. Post Link: https://ww.wp.xz.cn/support/topic/wp-crontrol-says-no-action-but-developer-says-yes/#post-18429923

Sadly I’m still seeing similr (not identical) entries in my log. I’ve condensed the old and new entries to make them a bit easier to read:

OLD:
WHERE flt = ‘cron’ AND id NOT IN (
SELECT id FROM…’ at line 1 for query DELETE FROM ‘b3wp_nxs_log’ WHERE flt = ‘cron’ AND id NOT IN (
SELECT id FROM (
SELECT id FROM ‘b3wp_nxs_log’ ORDER BY id DESC LIMIT 360
) foo
) made by do_action_ref_array(‘nxs_hourly_event’), WP_Hook->do_action, WP_Hook->apply_filters, nxs_do_this_hourly, W3TC\DbCache_WpdbNew->query, W3TC\DbCache_WpdbInjection_QueryCaching->query, W3TC_CallUnderlying->query, W3TC\DbCache_WpdbNew->query, W3TC\DbCache_WpdbInjection->query, W3TC\DbCache_WpdbNew->default_query

NEW:
SELECT id FROM ( S…’ at line 1 for query DELETE FROM ‘b3wp_nxs_log’ WHERE id <= ( SELECT id FROM ( SELECT id FROM ‘b3wp_nxs_log’ ORDER BY id DESC LIMIT 1 OFFSET 150 ) foo ) made by do_action_ref_array(‘nxs_hourly_event’), WP_Hook->do_action, WP_Hook->apply_filters, nxs_do_this_hourly, W3TC\DbCache_WpdbNew->query, W3TC\DbCache_WpdbInjection_QueryCaching->query, W3TC_CallUnderlying->query, W3TC\DbCache_WpdbNew->query, W3TC\DbCache_WpdbInjection->query, W3TC\DbCache_WpdbNew->default_query

I’ve decided to deactivate the plugin, the site is hardly active in the respect covered anyway.

Hi Marc,

thanks for your reply. Yes I am using the latest version, and now I’m not seeing the problem. Perhaps it was something to do with my caching plugin compacting too much.

Cheers, Tim

I’ve looked at all the different content types listed on the “Titles & Meta” page – there are 33 (!) of them. For better or worse, my client likes BIG plugins, so I’ve got items from Thrive, from Tribe, and God knows what else there. Is there any way I can easily find out which if them is creating an incomplete WP_Post_Type without actually editing the code and having it output debugging info?

Thanks!

66.249.69.186 – – [21/Jan/2023:16:11:59 +0100] “GET /wp-json/wp-statistics/v2/hit?_=1654885129&_wpnonce=b9de9124f8&wp_statistics_hit_rest=yes&browser=Googlebot&platform=Unbekannte&version=2.1&referred=https%3A%2F%2Ftimreeves.de&ip=66.249.64.195&exclusion_match=yes&exclusion_reason=CrawlerDetect&ua=Mozilla%2F5.0+%28compatible%3B+Googlebot%2F2.1%3B+%2Bhttp%3A%
2F%2Fwww.google.com%2Fbot.html%29&track_all=1×tamp=1654892329¤t_page_type=category¤t_page_id=13&search_query&page_uri=/internet-technologie/kategorie/linux-server/&user_id=0 HTTP/1.1″ 403 107 “-” “Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.5414.74 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”

I’ve also checked the version of WP Statistics via FTP, downlaoded it to my PC. The files are from 13.01.2023 15:06 and the readme.txt says Stable tag: 13.2.15

I do have a lot of security stuff in my nginx config, but also this line to let WP Statistics off the hook:
if ( $request_uri ~ “^/wp-json/wp-statistics” ) { set $susquery 0; }

In WP Cerber the REST API namespace “wp-statistics” is explicitly allowed. This must work because normal visitors are getting a 200 reply.

I’m out of ideas…

Hi Mostafa,

just got round to looking at this again – prompted by my access logs still being too long. I’m using the current version 13.2.15 (and nginx btw).

66.249.76.224 – – [21/Jan/2023:10:32:59 +0100] “GET /wp-json/wp-statistics/v2/hit?_=1657532437&_wpnonce=a497ad569d&wp_statistics_hit_rest=yes&browser=Googlebot&platform=Unbekannte&version=2.1&device=bot&model=Unknown&referred=https%3A%2F%2Ftimreeves.de&ip=66.249.64.192&exclusion_match=yes&exclusion_reason=CrawlerDetect&ua=Mozilla%2F5.0+%28compatible%3B+Googlebot%2F2.1%3B+%2Bhttp%3A%2F%2Fwww.google.com%2Fbot.html%29&track_all=1×tamp=1657539637¤t_page_type=post_tag&current_page_id=22&search_query&page_uri=/internet-technologie/tag/nginx/&user_id=0 HTTP/1.1” 403 107 “-” “Mozilla/5.0 (L
inux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.5414.74 Mobile Safari/53
7.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”

When I call up the website myself, as a normal visitor, Firefox Console shows me a 200 reply, as expected.

Do you have any ideas? I’ve just added /wp-json/ to robots.txt, which should save the plugin some work, but even so…

Many thanks for your work for the community, really appreciated!