PluginUs.Net - Business Tools for WooCommerce and WordPress

[realize your idea - make your dreams come true]
Botoscope is currently in early access

Support Forum

You need to log-in to create request (topic) to the support

Fox breaking Cloudflare APO caching

The support doesn work on Saturdays and Sundays, so some Friday requests can be answered on Monday. If you have problems with registration ask help on contact us page please
If you not got email within 24~36 business hours, firstly check your spam box, and if no any email from the support there - back to the forum and read answer here. DO NOT ANSWER ON EMAILS [noreply@pluginus.net] FROM THE FORUM!! Emails are just for your info, all answers should be published only here.
The support doesn work on Saturdays and Sundays, so some Friday requests can be answered on Monday.

Hi,

Fox is setting no-store, no-cache headers on ALL pages that have the Fox widget (shop, category, product pages). This breaks Cloudflare APO caching completely.

Evidence:

  • Pages WITHOUT Fox widget → cache works ✅
  • Pages WITH Fox widget → cf-apo-via: origin,resnok + no-store, no-cache 🔴
  • Affects ALL versions including 2.4.6, 2.4.9
  • "I am using cache plugin" setting is already enabled

Our setup:

  • Cloudflare APO
  • WP Rocket 3.23
  • WordPress 7.0

Hi, after more investigation we found the actual issue:

Fox sets a NEW wp_woocs_session cookie on EVERY page request — even when the customer hasn't selected a currency yet. This cookie has a different value each time.

Cloudflare APO sees a Set-Cookie header on every response and treats the page as dynamic/uncacheable → cf-apo-via: origin,resnok → BYPASS.

Hello

The problem

With the FOX Session storage type, the plugin creates a server side session for every visitor on the very first request, including visitors who have never touched the currency switcher, and including bots and crawlers. That means a Set-Cookie header goes out with practically every page response.

For an edge cache like Cloudflare APO, a Set-Cookie header is a hard stop. The cached HTML is served to many different people, so a response that carries a personal identifier can never be stored safely, otherwise thousands of visitors would end up sharing one and the same session. This is why APO answers with cf-apo-via: origin,resnok and why the effect was not limited to the currency, it disabled page caching across the whole site.

For the same reason, the PHP Session storage type is even less compatible with caching, because session_start() in PHP additionally sends no-store and no-cache headers by itself. That is most likely where the Cache-Control values in your first message came from.

Why we did not simply remove the cookie

The tempting fix was to stop creating the session so eagerly. We decided against changing that logic. It has been in place for years, it is shared by every FOX installation, and a change there could quietly break currency persistence for a lot of shops that are working fine today. A cache problem on one configuration is not a good reason to risk regressions on all the others.

We also considered doing something on the Cloudflare side. There is no safe option there either. Making Cloudflare cache a response that carries Set-Cookie, or stripping that header at the edge, either hands the same session to every visitor or destroys currency persistence completely. Both outcomes are worse than the original problem.

What we did instead

The Transient storage type sets no cookie at all, so it is naturally compatible with page caching. Its only real weakness was that it identified visitors by IP address, which means people behind a shared IP, for example an office network or a mobile carrier, could end up sharing one currency.

So we closed that weakness and built the whole solution around it. The update introduces a mode that activates only when both of these are set:

Storage type: Transient
Option: I am using cache plugin on my site

In this mode the plugin no longer relies on the IP address, and no longer sets any cookie. Instead, the browser generates a unique random key once, stores it in its own localStorage, and sends it along with the AJAX requests. The server uses that key to keep the visitor's currency. Prices are redrawn by AJAX, and switching the currency no longer reloads the page.

The result is that the HTML responses of your catalog pages contain no Set-Cookie header at all, so Cloudflare APO can cache them normally, while every visitor still keeps their own currency, even behind a shared IP. Crawlers do not execute JavaScript, so they no longer create any storage entries either, which also reduces the load on the database.

We also improved visitor IP detection behind Cloudflare by localstorage js key.

Any other combination of settings behaves exactly as before, so nothing changes for existing installations.

What to do on your side

Update the plugin from private area of this ticket (not released yet)
In the FOX options, set Storage type to Transient.
Make sure the option I am using cache plugin on my site is enabled.
Purge all caches completely: WP Rocket, the server cache, and the Cloudflare cache.

After that, please check a category page as a fresh visitor. There should be no Set-Cookie header from FOX in the response, and cf-apo-via should no longer report a bypass.

Please let us know how it goes.

p.s. for further support please renew the support https://currency-switcher.com/downloads - we moved from codecanyon, so use please our checkout page. Share new purchse code in the private area of this ticket

https://share.pluginus.net/image/i20230222134241.png
https://share.pluginus.net/image/i20230222134615.png
https://share.pluginus.net/image/i20230222134511.png

 

Hi,

Just to clarify the timeline for you:

This was working perfectly before — we used FOX Session storage for a long time with no caching issues. Cache hit rate was consistently 80%+ on Cloudflare APO.

Around June 24th the cache rate suddenly dropped from 80% to 20% with no intentional changes on our end.

We tried rolling back to a full plugin backup from June 7th (before the issue started) but the problem persisted even with the older version.

This suggests something external changed around June 24th — possibly:

  • A WordPress core update
  • A WooCommerce update
  • A Cloudflare APO behavior change
  • A PHP version change

    We will try your solution and update you

Hello

Thank you for the details and for the timeline, it is helpful.

We are looking forward to your test results. Please take your time, and once you have checked a category page as a fresh visitor with the new build, let us know how it went.

 

worked on transient. Can not figure out what caused the issue as everything was working fine earlier.

New issue. Because of transient I think we are getting CANNOT_MIX_CURRENCIES errors for customers on checkout. Default is USD and trying to pay with CAD. Pay with  multiple currencies are allowed. Using paypal by payment plugins.

Hello

Good news that Transient solved the caching issue.

About the new CANNOT_MIX_CURRENCIES error at checkout - let me share our current theory, and then a way for us to confirm it properly.

This PayPal error generally means that the PayPal order was created in one currency and then charged in another one within the same transaction (in your case the order created in USD, while the customer pays in CAD). So the two sides of the same payment disagree on the currency.

Our suspicion is about how the currency travels in Transient plus cache mode. In this mode there is no currency cookie by design (that is exactly what makes the pages cacheable again). The selected currency is carried along with the normal AJAX requests instead. Some payment gateways, however, create their PayPal order through their own separate request, and if that particular request does not carry the currency context, the order can be created in the base currency while the rest of the checkout runs in the currency the customer selected. That mismatch is what PayPal rejects.

To be clear, this is our theory at this point, not a confirmed conclusion. To verify it and find the exact spot where the currency context is lost, the best approach is:

Please create a staging site - a clone of your current live site exactly as it is now, same plugins, same settings. On that staging copy (with PayPal sandbox activated) we can safely reproduce the checkout, watch where the currency changes between order creation and payment, and adjust the approach accordingly without touching your live shop.

Also, so we can match the staging test to your real setup, please confirm the exact name and version of your PayPal payment plugin, and whether your checkout page uses the classic checkout or the newer block-based checkout.

Also, please confirm one thing about your goal: do you actually want to charge customers in CAD (and other selected currencies), or only display those currencies while charging everyone in your base USD? And how is CAD being set - does the customer switch it manually, or is it selected automatically (for example by geolocation)? From your description it sounds like customers paying in USD go through fine, while those who switch to CAD get the error - could you confirm whether that matches what you are seeing?

One more thing on our side. We can see that your support period expired back in January 2026. To continue working on this with you, please renew it here (you can buy new license): https://currency-switcher.com/downloads

From that page you can get either a new annual license or a lifetime license, whichever suits you better. Please note we have moved away from CodeCanyon and no longer work there, so there is no need to renew or top up anything on the CodeCanyon side - use our own checkout page above.

Once the staging clone is ready and the support is renewed, share the details in the private area of this ticket and we will continue.

 

Hello,

Thank you for the detailed response.

Update on our side:

  •  Staging site created (clone of live)
  • Support license renewed
  • PayPal sandbox activated

The core problem we need to solve:

We used Fox Session storage for over a year with Cloudflare APO caching working perfectly at 80%+ cache rate. Customers could pay in USD, CAD, EUR, AUD without any issues. This worked flawlessly.

Suddenly around June, 2026 the same setup stopped caching. Fox Session cookies started causing Cloudflare APO to bypass cache (cf-apo-via: origin,resnok). Nothing intentionally changed on our end.

In Transient mode we now have a new problem:

  • No customers can pay in CAD, EUR, or AUD
  • Only USD payments work
  • Others get CANNOT_MIX_CURRENCIES error at checkout
  • USD is our base currency, and we display CAD/EUR/AUD for customer convenience

Ideal solution:

Could you investigate why Fox Session storage previously worked with Cloudflare APO but now doesn't? If we can fix that specific issue, we can go back to Session mode which: Allowed multi-currency payments (CAD, EUR, AUD, USD) , Worked with caching for over a year,  No CANNOT_MIX_CURRENCIES errors

Something changed on Cloudflare's side or in browser behavior around June that made Fox Session cookies incompatible with APO caching. Understanding this would solve everything.

Additional info you requested:

  • PayPal plugin: PayPal Payments (PPCP by pymntpl - Payment Plugins for PayPal WooCommerce)
  • Checkout page:  ( Fluid Checkout Plugin)
  • Currency selection: Manual by customer (no geolocation)
  • Base currency: USD, displaying CAD/EUR/AUD/USD

Staging login details will be shared in the private area of this ticket shortly.

Hello

Thank you for the staging clone.

About why FOX Session worked with Cloudflare APO before and stopped in June: we cannot investigate this reliably and we will not promise a fix. The plugin behaviour did not change, FOX Session has always set a session cookie on the first request, which is also why your June 7th rollback did not help. The change happened outside the plugin, most likely in how APO evaluates cacheability. We cannot reproduce Cloudflare's edge behaviour on our side. We can register it as a research item in our Labs program, but with no guaranteed outcome and no timeline. For a real answer on the June change, Cloudflare support is the right address, they can see the decision for your zone. If they tell you something concrete, please share it with us.

What we will work on now is the checkout problem in Transient mode, the CANNOT_MIX_CURRENCIES error.

Please add to the private area of this ticket:

  1. FTP or SFTP access to the staging site in addition to the WordPress admin, since we will need to swap plugin builds during debugging.
  2. The staging URL and confirmation that the PayPal sandbox is active there.
  3. A test product and the exact steps that produce the error.

Our records still show your support as expired since January 2026. You mentioned you renewed it, so please post the new purchase code in the private area and we will attach it. If it has not gone through yet, it can be done here: https://currency-switcher.com/downloads

We no longer work through CodeCanyon, so the renewal has to come from our own checkout page.

Hello, I remind you that you need to add FTP into private data. Write here briefly that you have updated the information so that this ticket can be up.

We have great news — Cloudflare Support confirmed the exact issue and it's a simple fix!

The Problem:
Cloudflare APO has a static bypass list that automatically bypasses cache when it sees cookies with these prefixes:

  • wp-*
  • wordpress*
  • woocommerce_*
  • comment_*
  • edd_*

Fox sets a cookie named wp_woocs_session_xxxx which matches the wp-* prefix, causing APO to automatically bypass cache!

The Fix:
Can you rename the Fox session cookie to something that does NOT start with wp_, wordpress, or woocommerce_?

For example:

  • fox_session_xxxx
  • curr_session_xxxx
  • foxc_xxxx

This would let us use Fox Session storage mode WITH Cloudflare APO caching, solving the CANNOT_MIX_CURRENCIES issue AND the caching issue at the same time!

I have updated the Staging and FTP access and support key in the private data section.  Sandbox is active and you can test on any product. Any currency other than USD gets the issue. Let me know if you need any other info