Le sélecteur de devises revient à la devise par défaut à la page suivante

4 December 2026

Un visiteur choisit l'euro, ouvre la page suivante et voit de nouveau la devise par défaut. Ou bien la devise saute : des euros sur la page de la boutique, des dollars sur le produit, de nouveau des euros après l'ajout au panier. Lorsqu'un sélecteur de devises revient ainsi à la devise par défaut, FOX n'a rien oublié de lui-même. L'une de ces trois choses s'est produite : la page provenait d'un cache et n'a jamais atteint le plugin, le stockage qui conserve le choix du visiteur ne l'a pas gardé, ou quelque chose sur le site a de nouveau imposé une autre devise. Vous trouverez ci-dessous chaque cause avec sa solution, un diagnostic, et la raison pour laquelle une page en cache peut afficher la mauvaise devise pendant une seconde avant de se corriger.

Comment FOX mémorise la devise sélectionnée

Lorsqu'un visiteur clique sur une devise, FOX ouvre la même page avec ?currency=EUR dans l'adresse (ou, si Pas de données GET dans le lien (No GET data in link) est activé dans l'onglet Options, envoie le choix par AJAX et recharge la page). Le plugin écrit le code dans le stockage choisi dans Stockage de la devise (Currency storage). À chaque requête suivante, il y relit la devise.

Si le stockage ne contient rien pour ce visiteur, FOX le traite comme un nouveau visiteur : il reçoit la Devise d'accueil (Welcome currency), ainsi que les règles GeoIP si vous les utilisez. C'est souvent la devise par défaut que les gens voient « au retour ». Une page en cache en montre encore une autre : la devise de la première personne dont la page a été mise en cache.

Un cache de page sert la page

C'est la cause dans la plupart des cas. Une page en cache porte la devise de la personne qui l'a générée, et FOX ne s'exécute pas pour le visiteur qui reçoit la copie. La raison de ce conflit, et les deux solutions honnêtes, sont expliquées dans pourquoi un sélecteur de devises et un cache de page se battent. Les symptômes qui désignent le cache :

La devise tient pour vous lorsque vous êtes connecté, mais pas dans une fenêtre privée. La plupart des caches de page ignorent les utilisateurs connectés.
La devise tient dès que le panier contient un article. De nombreux caches serveur ignorent les visiteurs ayant le cookie woocommerce_items_in_cart.
La page avec ?currency= dans l'adresse est correcte, et la page suivante, sans ce paramètre, est erronée.
Deux navigateurs affichent deux devises différentes sur la même page.

La solution côté FOX tient en un réglage : J'utilise un plugin de cache sur mon site (I am using cache plugin on my site) = Oui (Yes) dans l'onglet Options, puis purgez tous les caches. Avec ce réglage, chaque page demande au serveur la vraie devise du visiteur après son chargement et redessine les prix lorsque ceux du cache diffèrent. Laissez-le désactivé sur une boutique sans cache de page : FOX y affiche déjà les bons prix côté serveur.

Deux règles supplémentaires s'appliquent à tout cache, quelle que soit sa marque :

Les pages panier, paiement et compte ne sont jamais mises en cache. Les plugins de cache excluent les pages WooCommerce standard, mais une page de paiement créée par un thème ou un plugin d'entonnoir de vente manque souvent dans la liste.
Avec Pas de données GET dans le lien (No GET data in link) activé, le changement recharge la même adresse, et un cache répond à ce rechargement avec l'ancienne devise. Sur une boutique en cache, cette option nécessite l'option de cache, sinon on a l'impression que le sélecteur ne fait rien.

Les couches de cache

Une boutique peut avoir trois caches, chacun purgé et configuré séparément : le plugin de cache, le cache serveur de l'hébergeur (SiteGround, Kinsta et d'autres hébergeurs gérés en exploitent un) et un CDN comme Cloudflare. Purger l'un ne purge pas les autres. Les optimiseurs qui retardent ou combinent le JavaScript (WP Rocket, LiteSpeed Cache, NitroPack et d'autres) peuvent aussi empêcher le redessin de s'exécuter : voir FOX et WP Rocket et le sélecteur de devises bloqué en chargement après l'optimisation JS pour les exclusions. La mise en cache de fragments de page (comme les blocs mfunc de W3 Total Cache) n'est pas nécessaire : FOX redessine lui-même les prix.

Quand le redessin ne s'exécute pas

L'option de cache n'aide que si la requête de redessin est réellement envoyée et reçoit une réponse :

Les pages sans prix. FOX n'envoie la requête que si la page contient des prix de produits. Sur une page d'accueil, un article de blog ou une page de contact en cache sans prix, le sélecteur conserve la devise de la copie en cache. Le choix n'est pas perdu : la prochaine page avec des prix l'affiche. Si l'indication du sélecteur sur ces pages compte, excluez-les du cache de page.
Des prix affichés de manière non standard. FOX repère les prix grâce à l'enveloppe qu'il ajoute au HTML des prix de WooCommerce : <span class="woocs_price_code" … data-product-id="…">. Un thème, un constructeur de pages ou un plugin de remises qui construit lui-même le HTML du prix supprime cette enveloppe, et FOX ne voit alors aucun prix sur la page. Affichez le code source de la page et cherchez woocs_price_code ; s'il manque autour des prix, désactivez des plugins et passez à un thème par défaut jusqu'à ce qu'il apparaisse.
AJAX bloqué. Un pare-feu ou un plugin de sécurité qui bloque /wp-admin/admin-ajax.php pour les visiteurs empêche le redessin. La devise semble alors aléatoire, car chaque page affiche ce qui a été mis en cache.

Le stockage de la devise perd le choix

Si la devise revient en arrière même avec tous les caches désactivés, le stockage ne conserve pas le choix du visiteur, et chaque page est une première visite. Le Stockage de la devise (Currency storage) de l'onglet Options détermine comment FOX reconnaît un visiteur :

Stockage de la devise	Le visiteur est reconnu par	Raison typique des retours en arrière
Transient	l'adresse IP ; avec l'option de cache activée, une clé aléatoire que le navigateur conserve dans le localStorage	Des visiteurs partagent une même IP (bureaux, opérateurs mobiles) ou l'IP change pendant la visite. Un serveur derrière un proxy ou un répartiteur de charge qui ne transmet pas `X-Forwarded-For` ou `X-Real-IP` voit une seule adresse pour tout le monde, de sorte que les visiteurs écrasent mutuellement leur devise.
PHP Session	le cookie `PHPSESSID` et les données de session sur le serveur	Le serveur supprime les sessions inactives (la durée de vie par défaut de PHP est de 24 minutes), le cookie prend fin à la fermeture du navigateur, ou plusieurs serveurs PHP ne partagent pas les sessions.
FOX Session	un cookie qui commence par `wp_woocs_session_`, valable 48 heures ; données dans la table des sessions de WooCommerce	Un proxy ou un CDN qui supprime le cookie ; la session prend fin au bout de 48 heures.
Memcached, Redis	l'adresse IP, comme Transient	Un Serveur de stockage (Storage server) ou un Port de stockage (Storage port) incorrect : rien n'est enregistré. Proposés uniquement lorsque l'extension PHP existe ; voir Memcached ou Redis comme stockage de devise.

Une valeur Transient expire un jour après la dernière page vue du visiteur, ou après 30 jours en mode clé du navigateur. Lorsque la devise revient en arrière sans cache, passez à un autre type de stockage, enregistrez et testez de nouveau. Une devise qui « change au hasard » d'une page à l'autre sur une boutique sans cache correspond au cas de l'IP partagée : un stockage par session le résout.

Deux effets secondaires à connaître. Changer le type de stockage fait oublier une fois toutes les devises enregistrées : tous les visiteurs deviennent nouveaux. Et avec PHP Session ou FOX Session, chaque visiteur reçoit le cookie de session dès la première requête ; ajouter ce cookie à la liste « ne jamais mettre en cache » d'un cache désactive donc le cache pour presque tout le monde après sa première page. Avec un cache de page ou un CDN, Transient associé à l'option de cache est la combinaison conçue pour la mise en cache : la clé du navigateur accompagne les requêtes de redessin et de panier, et aucun cookie n'intervient.

Quelque chose impose de nouveau la devise

Lorsque le stockage fonctionne et qu'il n'y a pas de cache, la devise revient en arrière parce que quelque chose en écrit une nouvelle.

Les liens avec ?currency=. Toute adresse contenant currency=USD impose le dollar au visiteur qui l'ouvre. Un élément de menu, une bannière ou un bouton dont le lien a été copié depuis le navigateur alors qu'une devise était sélectionnée réinitialise chaque visiteur qui clique dessus. Cherchez currency= dans les menus, les widgets et le contenu des pages.
Du code qui appelle set_currency() sur chaque page. Les snippets qui choisissent une devise selon la langue, le rôle de l'utilisateur ou la page et appellent $WOOCS->set_currency() à chaque requête écrasent à chaque fois le choix du visiteur. Cherchez set_currency dans le thème enfant et les plugins de snippets. Un snippet de ce genre ne doit s'exécuter que lorsqu'il doit l'emporter, pas à chaque page vue.
Le paiement. Avec Plusieurs devises autorisées (Is multiple allowed) réglé sur Non (No) dans l'onglet Avancé (Advanced), FOX bascule sur la devise de base au paiement, et le visiteur la conserve ensuite. C'est voulu : la devise revient à la devise par défaut après le paiement l'explique. Paiement selon les règles GeoIP (Checkout by GeoIP rules) fait de même avec la devise du pays du visiteur ; voir devise de paiement selon le pays du client.

Les règles GeoIP ne provoquent pas de retour en arrière à elles seules : elles ne s'appliquent qu'à la première visite. Si la devise GeoIP revient à chaque page, c'est que le visiteur est « nouveau » à chaque page, ce qui est le problème de stockage décrit plus haut.

Trouver la cause pas à pas

Reproduisez le problème comme un visiteur. Ouvrez une fenêtre privée, sans être connecté, avec un panier vide. Choisissez une devise, puis ouvrez une page sans prix, une page produit et le panier.
Regardez dans quelle devise la page a été construite. Ouvrez le code source de la page (Ctrl+U) et cherchez var woocs_current_currency ; le "name" qu'il contient est la devise du HTML. Une page construite dans une devise que vous n'avez pas choisie provient d'un cache, ou le stockage a perdu le choix.
Observez le redessin. Ouvrez les outils de développement (F12), rechargez, filtrez l'onglet Réseau sur admin-ajax et trouvez la requête avec action=woocs_get_products_price_html. Une réponse [] signifie que la devise enregistrée est égale à celle de la page. Une réponse avec current_currency indique la devise que FOX a enregistrée pour vous. Aucune requête signifie que l'option de cache est désactivée, que la page n'a pas de prix avec l'enveloppe FOX, ou que front.js ne s'est pas exécuté ; un 403 signifie qu'un pare-feu la bloque.
Contournez le cache une fois. Ajoutez un paramètre que le cache n'a jamais vu, comme ?nocache=4821, en changeant le nombre à chaque fois. Les caches ignorent ces adresses ou n'en ont pas encore de copie, si bien que WordPress construit la page à neuf. Si la devise est correcte ainsi et erronée sans le paramètre, le cache est la cause.
Désactivez les caches. Désactivez le plugin de cache, le cache serveur dans le panneau de l'hébergeur et le cache du CDN, puis purgez les trois. Si la devise revient toujours en arrière, changez le Stockage de la devise (Currency storage), puis cherchez les liens avec currency= et le code set_currency.
Réactivez les couches une à une, en testant après chacune. La couche après laquelle le problème revient est celle à configurer.

La mauvaise devise s'affiche une seconde, puis change

Sur une boutique en cache avec l'option de cache activée, ce scintillement est normal. La page en cache arrive avec les prix de la première personne dont la page a été mise en cache. Lorsque le HTML a été analysé, front.js attend 300 ms, collecte les prix et envoie une requête à admin-ajax.php. Le serveur compare la devise de la page avec celle enregistrée pour le visiteur et, si elles diffèrent, renvoie un nouveau HTML de prix qui remplace les anciens et met à jour les sélecteurs. L'attente que vous voyez correspond au temps de démarrage du script plus cette requête, qui n'est jamais mise en cache et charge tout WordPress. Sur un téléphone lent, cela peut prendre plusieurs secondes.

Pour la raccourcir ou la rendre invisible :

Ne retardez pas les scripts de FOX. Un réglage de type « retarder jusqu'à l'interaction » suspend le redessin jusqu'à ce que le visiteur fasse défiler la page ou touche l'écran. Les exclusions se trouvent dans l'article sur l'optimisation JS.
Accélérez la page et le serveur. Le redessin ne peut pas commencer avant l'analyse de la page, et il ne peut pas se terminer plus vite que le serveur ne répond à une requête non mise en cache.
Activez Préchargeur des prix (Prices preloader). Il s'affiche sous l'option de cache dans l'onglet Options dès que cette option est activée. Il masque les prix en cache derrière un petit indicateur de chargement depuis l'apparition de la page jusqu'au démarrage du redessin par front.js, ce qui représente la plus grande part de l'attente sur une page lente ou avec des scripts retardés. Pendant l'exécution de la requête de redessin elle-même, les prix en cache sont de nouveau visibles : un serveur lent les montre donc brièvement.

Le préchargeur a deux effets secondaires connus. Les produits chargés plus tard, par pagination AJAX, défilement infini ou filtre AJAX, ne sont pas redessinés, car le redessin s'exécute une fois par chargement de page, et rien ne retire l'indicateur de chargement de leurs prix. Désactivez le chargement AJAX pour les listes de produits en cache, ou désactivez le préchargeur. Et un modèle de variation tiers qui modifie le prix sans passer par les événements de variation standard de WooCommerce laisse l'indicateur sur le prix de la variation ; utilisez le modèle standard, ou demandez à son auteur de retirer la classe woocs_preloader_ajax de .woocs_price_code après chaque changement.

Désactiver l'option de cache supprime le scintillement mais fait revenir le retour en arrière, car les prix en cache restent alors tels quels. La seule configuration sans aucun scintillement consiste à ne pas mettre en cache les pages qui affichent des prix. Si la boutique peut supporter la charge serveur, c'est le choix le plus propre.

Checklist

Test effectué déconnecté, dans une fenêtre privée, avec un panier vide, après la purge de toutes les couches de cache.
J'utilise un plugin de cache sur mon site (I am using cache plugin on my site) = Oui (Yes) si un cache de page ou un CDN met en cache les pages de la boutique, Non (No) si aucun ne le fait.
Pages panier, paiement et compte, y compris les pages personnalisées, exclues de tous les caches.
Prix enveloppés dans des balises woocs_price_code, et requête woocs_get_products_price_html avec une réponse de statut 200.
Stockage de la devise (Currency storage) modifié et testé si le retour en arrière se produit sans aucun cache.
Aucun lien avec currency= dans les menus ou le contenu, aucun code qui appelle set_currency() à chaque page, Plusieurs devises autorisées (Is multiple allowed) = Oui (Yes) si la devise doit survivre au paiement.

Si la devise revient toujours en arrière après tout cela, ouvrez un sujet sur le forum de support de FOX avec le lien de la page, votre configuration de cache et la réponse de la requête woocs_get_products_price_html, et nous l'examinerons.