bjf2000

Interestingly, I navigated over to the Jetpack page from my site to do that, visited the Plugins section first just to see what was there (10 or so updates pending), then navigated back to the main JetPack page. Upon which I saw notice that plugin after plugin was automatically being updated.

So, merely navigating the area (I never even got to the disconnect/reconnect section) awakened it, which is very strange. Should I open a ticket? I ran the site against your Debug page, and it came back fine.

Done.

It’s “connected” now but I see no change as far as the original issue. I didn’t have an opportunity to disable all plugins on a live site, so that remains a long-shot possibility. The other possibility is CloudFlare, but I do have its Rocket Loader disabled per your release notes, though maybe there’s another incompatibility with one of CloudFlare’s many other features. I think this is the most likely possibility at this point, unless you say that your earlier test was using CloudFlare.

• This reply was modified 6 years, 5 months ago by bjf2000.

(Was your site being run through Cloudflare when you did the Lazy Load test with Master Slider?)

Yes, I did have the rule all along. The plugin doesn’t apply, since we use Strict. And it does say “Cloudflare and Jetpack for WordPress should require no additional configuration to operate together.”

I’ll try the disconnect/reconnect thing, if for nothing else to get WordPress.com fully onboard, despite, as I mentioned, features that require the connection (like extra stats) already working.

I can’t imagine what any of this has to do with Lazy Loading images, but we’ll see.

That connection thing is strange, because clearly it is connected, at least from the vantage-point of wp-admin. All looks perfect from there, and it’s backing up, there’s a long history of site stats, etc. And when I run the “/xmlrpc.php” test (try it yourself by appending it to my URL) mentioned on your troubleshooting page, that returns correctly too. That’s supposed to indicate XML-RPC is fine.

But your Debug page, which is probably what you’re referring to, comes back and says “We were unable to make an XML-RPC request to your website.”

It is true that when on WordPress.com (as opposed to wp-admin), there is indication of a communication error on the upper-left, but given that JetPack is doing its thing, and the extra stats even display on WordPress.com(!), it’s a little hard to believe.

If I disconnect the already-connected site, what is involved once I go to reconnect (not where to go to do it, but what I have to do after)? I want that to happen as quickly as possible, and I’d hope that things aren’t wiped (backups, stats, etc) just to fix something that may not be broken.

It would be a while before I could run through all those things on a live site. I thought of something easier that would cut to the chase though: why not just install Master Slider on a site of your own? That way you’d be accounting for all the variables and would have a definitive answer. If you can’t reproduce the problem, then I can start eliminating things.

Yes, that’s what I meant (I could have been clearer). Lazy Loading is disabled now, since otherwise, no slides.

Note that if you have an ad blocker, the site should be excluded, since it can interfere.

r e e p g r e e n . c a

Wow, when they say “min” they really mean it: 103KB vs 10KB.

@wfmattr. Thanks, sounds good, especially the part about adding in some kind of general protection for this sort of thing in the future. There’s always going to be random things like this out there.

Here’s what the source for our site shows for Rocket Loader. I don’t see any date in it, though no doubt it’s the new one (and unless it was a typo, maybe you’re saying that the old one has a different filename, which would make them easy to distinguish).
https://ajax.cloudflare.com/cdn-cgi/scripts/dba9ecf7/cloudflare-static/rocket-loader.min.js

Just an FYI:
https://community.cloudflare.com/t/rocket-loader-update-is-active-in-wp-admin/17900

There have been some changes to RocketLoader which have been rolled out to a subset of zones. Additional changes/ tweaks may be forthcoming.

I’ve asked the team to look into possible WordFence issues.

I believe a blog post will be forthcoming. I don’t know the full details on the changes, but Rocket Loader has been getting some serious love from the development team.

Yes, we do use CloudFlare and have had (all along) Rocket Loader on Automatic.

I can’t get away with experimenting with it today though, by turning it off and Live Traffic back on, so someone else will have to try that. On balance though, if it’s a choice between the two now, I’d rather keep Rocker Loader.

Here’s another graph, with the timeframe being one week:

View post on imgur.com

You can see how all three are normal until, wham, Wednesday and most of today. At the extreme right are the last several hours of Thursday with Live Traffic off.

Thanks! Do you know when it started? And are the IPs involved also extremely UNsuspicious-looking in your case? If this is someone using a proxy, it’s the most realistic one I’ve ever seen, since all the IPs I’ve checked are close by and from local ISPs (seemingly). It’s one of the things that makes me think it’s not a deliberate attack but rather a malfunction.

An hour ago, I disabled Live Traffic, and so far things have settled way down, like is normally the case. It’s too early to know if that helped though, since during the last 24 hours (roughly the duration of whatever this is), there have been periods extending an hour or two where all appeared normal or close to normal.

Plus, we’ve had Live Traffic enabled for months, so why would it be doing this now? The only reason I thought to disable it is because in an old thread here, a rep tied the “GET /?wordfence_lh=1&hid” lines to Live Traffic, though that thread wasn’t about this problem, more a general query about the line.

I notice that v7.1.4 made a change related to Live Traffic, but if that were related, the problem should have started a week ago–unless WF just changed something additional server-side?

Thanks. We went ahead and enabled it and all was well.

That’s perfect. Thanks again.