kizinko

@isaumya, understood. Thank you again for all your help looking into this for me!

That all makes sense. Again, thank you for all your help on this. It’s super enlightening!

Just so I fully understand, are you saying that there is a compatibility issue with using both? I realize it’s redundant, but there are significant benefits if I can make it work.

The issue with un-proxying my CF account is that we are then relying on the caching and security settings from WP Engine (which are less aggressive than SPCFC). Another issue is that they don’t purge their whole cache when someone publishes or updates a page, so it can cause issues when my clients make updates to custom post types and those updates are not reflected on other URLs around the website.

Let me know if you can think of any way we could potentially use both. Normally, I’d revert to WP Engine’s legacy DNS settings so we’re not using their CF-based “Advanced Network”, but they are phasing out legacy settings and forcing everyone over to the advanced network in their CF enterprise account.

@isaumya, sure! Here you go: https://tinyurl.com/23laua9l.

@isaumya, thank you for the follow up! My situation is a bit different from the one you linked to. They aren’t enabling the CF proxy in their account, but I am. I’m required by WP Engine to point to their “Advanced Network” which is just their enterprise CF account, but I still have my CF proxy enabled in my account so I can use this SPCFC plugin.

That’s why I was confused to hear that WP Engine would somehow be altering the CF cache control headers.

Apologies for being a noob, but I’m trying my best to learn how this works. I really appreciate your help on this.

Here’s how I have it configured on my end:
Request -> My Cloudflare (CF) which is proxied -> WP Engine Advanced Network (their CF) -> WP Engine dedicated server

WP Engine is forcing people to use their new “Advanced Network” (i.e. point through their CF). Unfortunately, their CF is set up generically and doesn’t cache things as effectively like this SPCFC plugin. As such, we have been using the SPCFC plugin to cache HTML pages in our Cloudflare account.

Are you saying that WP Engine is somehow altering the cache control headers and that is causing some of the traffic to bypass my CF account?

P.S. I did enable smart tiered cache yesterday and today the Percent Cached value has gone up to 48.84% over the last 7 days. Too early to say how impactful it is, but it does seem to have had some effect already.

Interesting. So using WP Engine interferes with Cloudflare caching? Do you have any other insight on that? Does WP Engine’s cache implementation somehow bypass or override the caching from Cloudflare?

Yes, gonna have to uninstall from all my managed sites if it’s not resolved quickly. This issue is now being reported to all users on Wrodfence as well. If it’s not patched soon, I imagine most people will abandon ship.

https://www.wordfence.com/threat-intel/vulnerabilities/wordpress-plugins/wp-simple-post-view/post-view-count-182-cross-site-request-forgery

Fyi, I had this same problem and the solution was to set the plugin to not keep settings on deactivation, deactivate, delete, clear hosting cache, re-install, re-activate, and re-configure the Super Page Cache for Cloudflare.

One additional detail that may be helpful if the plugin authors choose to explore this issue further: In my case, I had moved the domain from one Cloudflare (CF) account to another. This plugin was working perfectly until the domain changed from one account to the other. And yes, I am the full owner of both CF accounts with all of the necessary permissions, and I updated the credentials in the plugin settings as needed to connect to the new CF account (tried both API key and token methods and nothing would work).

The only solution was to remove the plugin settings; I even tried de-activating and re-activating and it didn’t work because the plugin settings had not been deleted. Going to Other > Keep settings on deactivation and turning that off before removing this plugin was what did the trick.

Great plugin! Really love it! Just thought I’d share these findings in case they are helpful.

Excellent! I will try that using an alternate server. That seems like the best next step.

And yes, I am aware that WP Crons are not real cron jobs, but you can use them as real crons by having an uptime monitor check your site every 1 minute. That’s what we do already anyway, so the WP Cron is run every minute and the schedule is reliable. Just FYI.

Found the solution! Sharing this here in case you have anyone else with the same problem.

I did some more tests with another site that I control and figured out that the issue was with a plugin conflict between the ‘WP Rocket’ and ‘Super Page Cache for Cloudflare’ plugins. Removing the caching from WP Rocket resolves the issue. In my case, I replaced the WP Rocket plugin with the Perfmatters plugin (because it does not do any of the caching – thus no cache conflict).

I sent a ticket to Avada asking them to fire one or both of the following WP actions.

• clean_post_cache
• edit_post

“Both of the action hooks that you have shared are being fired when the content is saved using the live editor. I have tested and confirmed that as well. It must be something related to your cache system. We are not removing these hooks from the live editor and they are being fired just like in the back-end. We are also using the “clean_post_cache” hook to clear Avada caches in some cases.”

is there anything else you can do on your end to see why the cache may not be clearing?

Understood! Thank you for your response. I will send them a ticket asking them to fire one the following WP actions on Save in the Avada Live editor:

• clean_post_cache
• edit_post

Ah, gotcha. Makes sense. Thanks for the quick turnaround!

Excellent, thanks!