zzzaaabbb

re: the setting at wordpress.com showing as “disabled” ..

That might be misleading, that it shows or showed as disabled. On my wordpress.com dashboard, it also showed as disabled, per plugin, but on hover it said something about connection was not being allowed. And, the area at the top for enabling all the plugins, in bulk, to have auto-updates was greyed-out. Together, those two symptoms indicated something else interfering with those controls.

Then, I noticed in Debug (on site Jetpack admin) that I did not have a clean connection to Jetpack. One of the tests was not passing re: the site being connected to Jetpack at wordpress.com. That may have been caused by the major Jetpack upgrade. That would explain the odd appearance and behavior of the controls at wordpress.com for the plugins’ auto-update slider (and not being able to move it back and forth).

So, I disconnected and reestablished the primary Jetpack connection to the site, and that error was resolved. Now, on wordpress.com, each plug-in has a normal-looking On/Off slider with the label Active.

In other words, prior to fixing the “Jetpack connection” to the site, the fact that the plugins showed as Disabled on wordpress.com may have been meaningless. The ACTIVE setting (reflected on your site and stored at wordpress.com) may have been controlling, causing your updates.

@jjbte

Same thing happened to me. Highly aggravating. I thought that there might be a switch in the database for it but could not locate it. Is the setting only stored at wordpress.com?

See images below for the reason that I cannot turn it OFF at wordpress.com.

This needs to be fixed. We cannot operate our sites if we cannot turn this OFF. (Fixed means that we need to be able to revert it back to OFF, not a “workaround” fix.)

Thank you.

In site admin on the domain:

In wordpress.com jetpack dashboard for plugin management:

Thanks for clarification, @wfalaa! Understood.

My site is now working fine with Cloudflare IPs. Thank you for your help.

Here is a summary of possible solutions discussed in this thread:

• mod_cloudflare on Apache server (if your hosting company supports/allows it)
• Cloudflare plug-in for WordPress
• WF option “How does Wordfence get IPs” — set to Use CF “CF-Connecting-IP” (if Cloudflare is sending that header)
• WF option “trusted proxies” list (if “X-Forwarded-For” header contains both CF and remote visitor IP)
• WF option “Whitelisted IP addresses that bypass all rules” (using range multi-brackets such as in list provided by @sohrabrika)

Thanks for your reply.

I actually did go ahead and use the trusted proxies section, so that millions of Cloudflare IPs would be ignored in the “X-Forwarded-For” header.

The trusted proxies option allows CIDR, so that a single CIDR range (104.16.0.0/12) that covers 1 million+ IPs can easily be handled. (But I see that doing so may not be necessary, because the IP in that header is the visitor IP, not Cloudflare’s IP. It would only potentially be necessary if the IP in that header is Cloudflare’s IP.)

Here is the image of the section that you requested:

Re: my other question:

I was primarily referring to syntax, for being able to input all of Cloudflare’s IPs in the WF option “Whitelisted IP addresses that bypass all rules.”

It would not be feasible to input Cloudflare’s IPs in that section, unless this works:

104.[16-31].[0-255].[0-255]

If that ^^ does not work in WF, then you would have to do this:

104.16.0.[0-255]
..etc
..etc
104.16.255.[0-255]
104.17.0.[0-255]
..etc
..etc
104.17.255.[0-255]
..etc
..etc

..which is not feasible for the average person to input. It would be 4096 lines.

So, all this started with wondering how to get Cloudflare’s IPs input to the WF option “Whitelisted IP addresses that bypass all rules.”

I saw that WF does allow that type of grouping of range brackets in IPv6, in order to identify larger ranges, so if WF also allows grouping of range brackets for IPv4, i.e., 104.[16-31].[0-255].[0-255], then it would be possible to get all of Cloudflare’s IP addresses into “Whitelisted IP addresses that bypass all rules”?

Summary:

This quest initially started with simply wanting to whitelist Cloudflare’s IPs. Then, I saw that there might be a syntax problem with getting millions of Cloudflare’s IPs input into the WF whitelist option. After that, I saw that I could use Cloudflare’s CIDR range in trusted proxies, but it appears that it’s not needed there, because the “X-Forwarded-For” header is using the visitor’s IP, not Cloudflare’s IP.

@wfalaa

Please describe if it is possible to whitelist Cloudflare’s IP ranges, when at least one of the ranges is this in CIDR: 104.16.0.0/12

That is over one million IP addresses (1,048,576 to be exact), that go from 104.16.0.0 to 104.31.255.255

So, I don’t know, but is this syntax possible to represent a range: 104.[16-31].[0-255].[0-255] ??

I am just guessing at that. Is that a real way of writing a range, to conform to Wordfence range syntax. If not, then it would not be feasible to whitelist Cloudflare’s IPs.

• This reply was modified 8 years, 10 months ago by zzzaaabbb.

I am experiencing same issue with logged in vs. not logged in. I also thought WP Super Cache might be involved in the problem. When not logged in, video appears inconsistently, from post to post and page type to page type. When logged in, video appears everywhere.

WP Super Cache does not serve cached pages to logged-in visitors, per a setting, so I bet the problem has to do with caching.

https://wordpress.org/support/topic/inconsistent-with-wp-super-cache