Quote from Hero on July 13, 2026, 06:29

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.

Quote from Alex Dev on July 13, 2026, 13:17

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

 

Quote from Hero on July 13, 2026, 14:30

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

Quote from Alex Dev on July 14, 2026, 12:02

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.

 

Quote from Hero on July 16, 2026, 05:14

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

Quote from Hero on July 16, 2026, 19:52

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.

Quote from Ross on July 17, 2026, 14:20

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.

 

Quote from Hero on July 19, 2026, 19:46

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.

Quote from Alex Dev on July 20, 2026, 12:55

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.

Quote from Alex Dev on July 21, 2026, 13:33

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.

Quote from Hero on July 22, 2026, 18:04

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

Quote from Alex Dev on July 24, 2026, 14:43

Hello

Thank you for the update and for the Cloudflare answer, that is useful information.

First, about the staging site. We tried to work there today and could not.

FTP is not usable. SFTP refuses the connection, and plain FTP logs in but then hangs on retrieving the directory listing and times out. We retried several times with the new credentials from the private area. This usually means the passive mode port range is blocked on the server or the FTP service is restricted by IP. Without file access we cannot upload and swap plugin builds, and this task needs several iterations of exactly that.

PayPal also does not work there at all. Any attempt to pay ends with:

There was an error processing your payment. Reason: Client Authentication failed

We get this with FOX active and with FOX completely deactivated, so it is the PayPal connection on the clone, not the currency switcher. Sandbox credentials very often break when a live site is copied.

So before we continue on staging, please do three things. First, give us working file access, SFTP preferred. Second, make PayPal work there with our plugin deactivated and place one successful test order yourself, so we know the environment is trustworthy. Third, record a short video where you reproduce the error from the start: selecting CAD, adding the product, going to checkout, pressing the PayPal button, and the error appearing.

---

Now about your question, and here we have good news.

You do not need a new build from us. The cookie name is already passed through a filter in the plugin, so you can rename it yourself without touching plugin files. Create a file, for example wp-content/mu-plugins/fox-cookie-name.php, with this content:

<?php
add_filter('woocs_cookie', function ($name) {
return 'foxc_session_' . COOKIEHASH;
});
?>

One important detail: it must be an mu-plugin. It will not work from the theme functions.php or from WPCode, because FOX creates its session object at the moment the plugin file is loaded, which happens before themes and before those snippets run. Files in wp-content/mu-plugins load before regular plugins, so the filter is registered in time.

After that, switch Storage type back to FOX Session, purge all caches, and check the response headers on a category page. The cookie should now be named foxc_session_ and APO should no longer bypass on it.

Two things to be aware of.

Every visitor who currently has a currency selected will lose it once, because the old cookie is no longer read. They simply pick the currency again, and the old session rows expire on their own.

More important: renaming the cookie removes the reason APO bypasses the cache, but the response still contains a Set-Cookie header with the session identifier. If APO now stores such a response, the same session id can be served to different visitors, and they would share one currency. Please verify this before going live. Open a category page in one browser, select CAD, then open the same page in a completely fresh browser profile with no history, and confirm that the second browser gets its own cookie and its own currency, not the one from the first. If both browsers end up on the same currency, the rename must be reverted, because that problem is much harder to notice on a live shop than a low cache rate.

Please let us know the result of that test, and update us when the staging access and PayPal are ready.

P.S. One detail about the snippet: please keep COOKIEHASH in the returned name. It is derived from your site URL and it separates installations that share the same domain. If you return a plain name like 'foxc_session' without it, cookies can overlap on a multisite or when two WordPress installations run on the same domain. The snippet as written above is correct.

Quote from Hero on July 25, 2026, 18:55

Hi,

Thanks for the detailed reply and the cookie-rename snippet — much appreciated.

PayPal sandbox:
We've updated the PayPal sandbox and it seems to work and we did a test order. On our side we ran a test CAD purchase and are still seeing the same error, so please test as well and let us know what you get with the updated credentials. A normal USD purchase goes through.

FTP login.
added  new server link , if it does not work it may be an access restriction on the server side. Send us the public IP of the machine you're connecting from and we'll allowlist it

Cookie rename fix:
Thank you for confirming this can be done via the mu-plugin filter without a new build. Before we apply it, we're checking the caching behaviour with Cloudflare to confirm it's safe and that it will actually improve the cache rate. Their initial answer is that APO does not cache responses containing a Set-Cookie header by default, so we want to confirm the rename will have the intended effect before going live.

Quote from Alex Dev on July 27, 2026, 13:31

Hello

IP address added into the private area, the same:

Status: Logged in
Status: Retrieving directory listing...

Also I tried to work trought: wp-admin/plugin-editor.php but "Sorry, you are not allowed to access this page."

Also I tried to install latest version using zip - no success

 

 

Quote from Hero on July 31, 2026, 15:50

I have updated the port. See if it works for you.

Quote from Alex Dev on August 3, 2026, 18:21

Hello

Two things.

1. New build

We have found (I hope) the cause of the checkout problem, and it is not specific to your site. In browser key mode the currency key was attached only to jQuery AJAX requests. PayPal PPCP does not use jQuery, it works through fetch, so its requests reached the server without the key and the PayPal order was created in the base currency. That is exactly the CANNOT_MIX_CURRENCIES you see. The build in the private area of this ticket carries the key on those requests as well.

Please update, purge all caches, shop cart, and place one test order in CAD. Keep Storage type on Transient and the cache option enabled.

2. Access

The FTP access still does not work after the port change. The connection logs in and then times out on the directory listing, exactly as before. A video of the attempt is attached so you can pass it to your host.

If the build above does not solve the CAD checkout, we do not need to keep fighting with remote access. Instead, please send us a snapshot of the staging site and we will deploy it on our own server:

wp-content archive plus an SQL dump, taken from your hosting panel please exclude the uploads folder, we do not need media for this please remove customer and order data before packing. You can use plugin Duplicator.

Send it as a link to Google Drive or Dropbox in the private area.

Quote from Hero on August 6, 2026, 16:42

Hello,

The updated plugin worked and no more currency mix issue and for some reason the fox session is not breaking the caching anymore as well.

Quote from Alex Dev on August 7, 2026, 11:57

Hello

Thank you for your cooperation!