bjf2000

That’s perfect. Thanks again.

Thanks for creating that over at Github.

You’re right about it not relating to the PHP version. We had temporarily switched back to 5.6 for unrelated reasons this week, and I noticed that the errors appeared twice more in the log.

Yes, to my knowledge JetPack doesn’t have a problem with the site, but as you know, JetPack does a lot of things, and I’m far from an authority on most of what it’s doing. In other words, while it would be nice if the warnings are inconsequential, I don’t know one way or the other.

No, I don’t have an environment for that. Plus, I have no idea if it even recurs, or if it does, when. Do we even know necessarily that it even relates to another plugin, as opposed to a theme, or something else like the version of PHP (7.1, for example, has been causing some problems recently for JetPack)? What is the meaning of it in the first place? That might be the best place to start. Maybe here is a better place for this:
https://github.com/Automattic/jetpack/issues

We found the exact same message (except the name of the site, of course)–four times over about five minutes–in the error_log in public_html.

We don’t have WooCommerce. And since we can’t disable every other plugin or build a new site–and we don’t know when the warning recurs anyway, since the log has all of one day in it–what is the importance of the warning? What might it mean in the context of this plugin and WP in general? Those seem important to know and are missing from the thread.

I only came across the log in the first place because we’re troubleshooting periodic high CPU/IO issues (the times in the log don’t correspond with these issues, so I don’t think they’re related). I don’t know of any issues with the plugin, though that’s not to say that there aren’t any, since it’s a big plugin and I’m not familiar with all of it.

Yes, that makes sense.

I think ultimately what you say at the end must be happening, despite the few log examples I was given, since the JetPack Protect count is over 450 points higher today than it was close to a week ago. It wouldn’t make any sense if all of these visitors from very far-off lands were just showing up and doing nothing, unless, I guess, some are just interrogating the site looking to see what flaws might exist.

Thanks

This is their response:

As far as I see that data are GET requests:
###
181.90.182.148 – – [28/Sep/2017:18:58:01 -0400] “GET /wp-login.php HTTP/1.1” 302 – “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1”
177.13.235.144 – – [28/Sep/2017:19:06:51 -0400] “GET /wp-login.php HTTP/1.1” 302 – “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1”
85.220.99.138 – – [28/Sep/2017:19:09:22 -0400] “GET /wp-login.php HTTP/1.1” 302 – “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1”
85.220.99.138 – – [28/Sep/2017:19:09:25 -0400] “GET /wp-login.php HTTP/1.1” 302 – “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1”
85.220.99.138 – – [28/Sep/2017:19:09:27 -0400] “GET /wp-login.php HTTP/1.1” 302 – “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1”
85.220.99.138 – – [28/Sep/2017:19:09:28 -0400] “GET /wp-login.php HTTP/1.1” 302 – “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1”
85.220.99.138 – – [28/Sep/2017:19:09:29 -0400] “GET /wp-login.php HTTP/1.1” 302 – “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1”
85.220.99.138 – – [28/Sep/2017:19:09:30 -0400] “GET /wp-login.php HTTP/1.1” 302 – “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1”
85.220.99.138 – – [28/Sep/2017:19:09:31 -0400] “GET /wp-login.php HTTP/1.1” 302 – “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1”
85.220.99.138 – – [28/Sep/2017:19:09:31 -0400] “GET /wp-login.php HTTP/1.1” 302 – “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1”
85.220.99.138 – – [28/Sep/2017:19:09:32 -0400] “GET /wp-login.php HTTP/1.1” 302 – “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1”
85.220.99.138 – – [28/Sep/2017:19:09:33 -0400] “GET /wp-login.php HTTP/1.1” 302 – “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1”
85.220.99.138 – – [28/Sep/2017:19:09:34 -0400] “GET /wp-login.php HTTP/1.1” 302 – “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1”
85.220.99.138 – – [28/Sep/2017:19:09:40 -0400] “GET /wp-login.php HTTP/1.1” 302 – “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1”
85.220.99.138 – – [28/Sep/2017:19:09:41 -0400] “GET /wp-login.php HTTP/1.1” 302 – “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1”
85.220.99.138 – – [28/Sep/2017:19:09:42 -0400] “GET /wp-login.php HTTP/1.1” 302 – “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1”
85.220.99.138 – – [28/Sep/2017:19:09:43 -0400] “GET /wp-login.php HTTP/1.1” 302 – “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1”
85.220.99.138 – – [28/Sep/2017:19:09:44 -0400] “GET /wp-login.php HTTP/1.1” 302 – “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1”
85.220.99.138 – – [28/Sep/2017:19:09:45 -0400] “GET /wp-login.php HTTP/1.1” 302 – “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1”
85.220.99.138 – – [28/Sep/2017:19:09:46 -0400] “GET /wp-login.php HTTP/1.1” 302 – “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1”

In our case, the site is behind CloudFlare. Does that skew things?

The data I posted was after an inquiry made to the host trying to understand why we’re having recurring, minutes-long outages. That data represents a 10-minute period, during which the outage occurred. The host described it as “Suspicious requests to your wp-login admin area,” and referred to the data as “Amount of request for admin area and xmlrpc file for mentioned period.”

I’m also curious, since we also have the feature enabled, and the widget shows a count of 75,233, though I have no idea of the time period for that.

Our host provided us with this data, which happened within a 10-minute window and coincided with a spike in CPU and I/O on the site (causing it to go offline for 3 or 4 minutes). The first column is the number of attempts. There’s no way they should have been able to get off this many attempts.

20 103.210.32.6
20 115.31.148.235
20 178.222.227.196
20 187.95.111.135
20 213.159.45.55
20 75.88.185.144
20 85.85.77.83
21 178.152.103.217
21 39.36.52.24
21 91.124.237.172
22 213.233.96.128
22 2800:810:43f:80da:9861:7f7b:7b17:9a7f
22 79.118.49.222
24 1.0.153.130
24 37.231.101.54

OK, I haven’t been reading the site long enough to pick up on the fact that the first post is essentially boilerplate. That helps put it in context now. Thanks.

It’s the one pinned to the top of this section of the forum.

All is working fine in 4.7.5, but just due to the many mentions of it in that 4.8 thread, it seemed that it was more theme-sensitive (or, at least, requiring an up-to-date theme). Maybe the 4.7 thread was similar.

Yes, I realize that it’s easy to change themes, but (and I inherited the site, which is why I can’t be more specific yet) I think some work went into tailoring our current theme for the site. I did switch over to the generic 2016 or 2017 theme once out of curiosity, and the site was all but unrecognizable (not just a different look, but broken all over the place).

Hmmm, I only see mention of UberMenu on the right side of that screen (Contact Widget)–there’s plenty about Jetpack on the left–so I guess it’s UberMenu that needs attention (helpfully, it has no relevant settings at all there). I inherited the site so am just catching up, but I’ll pursue it with them. Thanks.

Although, based on its age and the scathing recent reviews, P3 looks suspect, at least for a modern version of CF. What version did you test it on?

That’s great, I will give them a go, thanks.

Yes, absolutely. phpMyAdmin works well for us, as opposed to the backup in Search & Replace, which seems to stall out and effectively hang up the site. There’s a big difference in efficiency in backup methods, it seems.