ggalow

4.12.2 is now released. thanks for the reports.

We identified the issue and a roll forward fix is in progress which will be released as 4.12.2

Its hard to give a perfect answer as it depends on what features of WPTC you have enabled and other aspects of your WP setup. Please take everything I say as a general suggestion and not hard fact given I don’t know your setup.

In general we would recommend against having multiple edge caches enabled. It looks like WPTC does have its own edge caching, but I don’t know if it can be disabled.

Otherwise if you are just using the plugin alone, I wouldn’t expect there to be issues. You will need to be aware that you have both a server side cache with WPTC and an edge cache with Cloudflare, so cache issues could be due to one or the other.

If you decide to use APO ( https://support.cloudflare.com/hc/en-us/articles/360049822312-Understanding-Automatic-Platform-Optimization-APO-with-WordPress ) which is available for free in the pro plan, then after enabling please purge all of your server side caching, so that APO can work properly. I don’t think we have positively said WPTC and CF don’t have any issues, but I wouldn’t expect there to be anything that would be fundamentally incompatible between the two.

No action is needed. The plugin is not dependent on these cookies.

@jorg953 you have two options. If you have a business plan there is a page rule for bypass cache on cookie: https://support.cloudflare.com/hc/en-us/articles/236166048-Caching-Static-HTML-with-WordPress-WooCommerce

Alternatively if you use APO, this is provided by default: https://support.cloudflare.com/hc/en-us/articles/360049822312-Understanding-Automatic-Platform-Optimization-APO-with-WordPress

@veggroups you seem to be having a different issue. All the headers you provided would mean that Cloudflare is NOT caching those pages. Both BYPASS and DYNAMIC mean cloudflare is not returning a cached response.

If you use any provider or plugin that has its own sort of server side cache (or its own edge cache) then clearing that is required as otherwise Cloudflare will just cache the other cache….”its caching all the way down” sometimes”

I haven’t run across this kind of issue before…If the date is being inserted into the HTML itself, then I don’t know of a way to only exclude that bit of info. If this only occurs on 1 or a few pages, you could use page rules to not cache those specific html pages. If this is on all or many of your pages then I don’t have a good solution.

Going to have to ask you to open up a support ticket. We won’t be able to help without digging in more and collecting some more info.

can you see this thread https://github.com/cloudflare/Cloudflare-WordPress/issues/399 if its the same issue. If so please provide info there. We are having trouble reproducing this issue (if its the same one)

Watching that github issue is the right thing to do. When we have a fix it will be linked and close that issue.

This should help you: https://community.cloudflare.com/t/apo-tiered-caching-testing/249055/6?u=ggalow

copied below as well:

Please try the following steps to fix compatibility:

go to Cloudflare WordPress plugin
disable APO in the card
enable APO in the card (will set proper settings for APO feature)
clear WP Rocket server cache (or/and any other server cache)
verify that your origin starts serving response header “cf-edge-cache: cache,platform=wordpress”
Optional step: once the origin starts serving the response header WP plugin check will pass in the dashboard.

This is the most common issue with APO compatibility: once APO is enabled all server caches requires purge & restart.

If this doesn’t resolve the issue then I would ask that you create a support ticket so we can collect more info and have someone help investigate.

Hm, I don’t think we support this. If someone has access to the CF plugin page in WP then they would have access to change any of the settings exposed in the plugin.

This was https://github.com/cloudflare/Cloudflare-WordPress/issues/380 and was fixed in version 4.2.2 of the plugin.

This was https://github.com/cloudflare/Cloudflare-WordPress/issues/378 which was just fixed with v4.2.1

We updated the tested version today in plugin v4.1.0 though there is no real functional change from v4.0.0