Le sélecteur de devises ne fonctionne pas avec un plugin de cache WordPress

25 December 2026

Un sélecteur de devises qui ne fonctionne pas avec un plugin de cache dans WordPress présente généralement l'un de ces quatre symptômes : les prix restent dans la devise de base après le changement, la devise revient à celle par défaut sur la page suivante, un clic sur le sélecteur ne fait rien, ou tout fonctionne quand vous êtes connecté et échoue pour les visiteurs. Deux causes différentes sont possibles. Un cache de page sert du HTML stocké qui a été construit pour un autre visiteur, et l'optimisation JavaScript (délai, report, minification, combinaison) perturbe l'ordre d'exécution des scripts du sélecteur. Chacune a une solution qui conserve votre cache et vos scores de vitesse.

Pourquoi un cache de page empêche le changement de devise

Le shortcode [wpcs_price] convertit le montant en PHP pendant que WordPress construit la page. Un cache de page enregistre ce HTML terminé et envoie la même copie aux visiteurs suivants, qui voient tous la devise du visiteur ayant rempli le cache. La devise choisie par le visiteur est bien mémorisée, mais PHP ne s'exécute jamais pour une page en cache : rien ne l'utilise donc.

La solution se trouve dans Réglages (Settings) → Currency Switcher → Options : réglez J'utilise un plugin de cache sur mon site (I am using cache plugin on my site) sur Oui (Yes). Avec cette option activée, la page se charge depuis le cache, puis le script front.js du plugin :

collecte tous les prix affichés par [wpcs_price] (chacun est un span.wpcs_price portant son montant d'origine dans data-amount) ;
envoie une requête POST à /wp-admin/admin-ajax.php avec action=wpcs_get_prices_html ;
remplace les prix par la réponse, calculée pour ce visiteur, et règle le sélecteur sur la devise du visiteur.

Trois détails comptent lors du dépannage :

Tant que cette réponse n'est pas arrivée, le sélecteur ignore les clics, afin de ne jamais basculer à partir d'un état périmé. Si la requête est bloquée ou échoue, le sélecteur reste inactif. C'est une raison typique du « cliquer ne fait rien ».
L'option est écrite dans la page sous la forme d'une petite variable de script. Les pages mises en cache avant votre modification portent encore l'ancienne valeur : videz donc toutes les couches de cache après l'enregistrement, c'est-à-dire le plugin de cache, le cache serveur et le CDN.
Seuls les prix de [wpcs_price] sont redessinés. Une étiquette [wpcs_current_currency], ou des valeurs affichées par du code PHP dans un modèle avec $WPCS->wpcs_exchange_value(), restent telles qu'elles sont en cache. Excluez du cache de page les pages qui en dépendent.

La même requête applique aussi les règles GeoIP aux visiteurs des pages en cache ; si la détection elle-même est erronée, voir la détection de devise GeoIP ne fonctionne pas.

La requête wpcs_get_prices_html ralentit-elle le site ?

Les outils de test de vitesse tels que GTmetrix listent un POST vers admin-ajax.php avec wpcs_get_prices_html vers la fin de la cascade, parfois avec une durée élevée à côté. Voici ce qu'elle coûte réellement :

C'est une requête par page vue, envoyée sur chaque page qui charge le script du plugin, car le sélecteur a besoin de la devise du visiteur même là où aucun prix n'est affiché. Au maximum 500 prix sont envoyés dans une requête.
Elle démarre une fois le HTML analysé et n'empêche pas l'affichage de la page. Le visiteur voit d'abord la page ; les prix se mettent à jour un instant plus tard.
Sa durée correspond à peu près au temps dont WordPress a besoin pour se charger sans cache de page. Sur un site en bonne santé, c'est une fraction de seconde. Si elle prend plusieurs secondes, chaque requête non mise en cache du site est aussi lente, et la cause se trouve dans les plugins ou l'hébergement, non dans cette requête.
Avec un JavaScript retardé jusqu'à la première interaction, la requête ne démarre que lorsque l'outil de test en simule une : elle apparaît donc tard et gonfle le temps de « chargement complet » sans modifier ce que voit le visiteur.

Ne désactivez l'option que si aucun cache de page ne stocke vos pages : ni plugin de cache, ni cache serveur, ni mise en cache du HTML par un CDN. PHP affiche alors directement la bonne devise. Avec n'importe quel cache de page en place, la désactiver empêche les visiteurs de changer de devise.

Trouver les erreurs JavaScript avant de modifier les réglages

Testez dans une fenêtre privée où vous n'êtes pas connecté. Les caches de page et la plupart des plugins d'optimisation ignorent les administrateurs connectés, ce qui explique que le sélecteur puisse fonctionner parfaitement pour vous et échouer pour chaque visiteur. Ouvrez les outils de développement (F12), rechargez, et regardez la Console :

Message de la console	Ce qui s'est passé
`wpcs_array_of_get is not defined` ou `wpcs_current_currency is not defined`	Le petit script en ligne contenant les réglages du sélecteur a été retardé ou déplacé sous les fichiers de script du plugin
`jQuery is not defined`	jQuery a été retardé ou différé alors que des scripts qui en dépendent s'exécutaient
Erreurs dans un fichier combiné ou minifié	Toute erreur dans un fichier combiné arrête le code qui la suit, sélecteur compris

Ouvrez ensuite l'onglet Réseau (Network), saisissez admin-ajax dans le filtre et cliquez sur la requête avec wpcs_get_prices_html. Une réponse correcte a le statut 200 et commence par {"prices":. Le statut 403 signifie que la requête est bloquée (voir la dernière section). Du texte ou du HTML avant l'accolade ouvrante signifie qu'un autre plugin ou un avertissement PHP a écrit dans la réponse ; le script ne peut pas la lire, de sorte que les prix restent tels qu'en cache et que le sélecteur reste verrouillé. Aucune requête avec l'option activée signifie que le script ne s'est jamais exécuté : retournez à la console.

WP Rocket, Perfmatters et autres optimiseurs : quoi exclure

Le sélecteur a besoin que trois éléments s'exécutent dans l'ordre : jQuery, le script de réglages en ligne que le plugin affiche dans l'en-tête de la page, et les fichiers du dossier js du plugin (front.js ainsi que la bibliothèque de votre vue de liste déroulante : ddslick, chosen ou wSelect, et les scripts Designer si vous les utilisez). Ne retarder que certains d'entre eux provoque les erreurs not defined ci-dessus.

Dans WP Rocket, allez dans Optimisation des fichiers (File Optimization) et ajoutez ces lignes à Fichiers JavaScript exclus (Excluded JavaScript Files) sous Retarder l'exécution du JavaScript (Delay JavaScript execution) :

/wp-content/plugins/currency-switcher/
wpcs_
/jquery-?[0-9.](.*)(.min|.slim|.slim.min)?.js
/jquery-migrate(.min)?.js

La première ligne couvre les fichiers du plugin, wpcs_ est un mot-clé présent dans le script de réglages en ligne, et les deux dernières lignes empêchent jQuery d'être retardé. Si des erreurs subsistent avec Charger le JavaScript différé (Load JavaScript deferred) activé, excluez aussi le dossier du plugin à cet endroit. WP Rocket explique les deux champs dans Delay JavaScript execution et Exclude files from Load JavaScript deferred.

D'autres outils proposent les mêmes options sous d'autres noms : le délai des scripts dans Perfmatters, la minification et la fusion dans WP-Optimize, la minification et la combinaison dans W3 Total Cache. Excluez le même dossier du plugin et jQuery, ou désactivez la combinaison à titre de test. Si le sélecteur fonctionne avec l'optimiseur désactivé, le problème vient de sa configuration, et la console vous indique quel fichier est concerné.

Après chaque modification, videz le cache et les fichiers générés par l'optimiseur (la plupart des plugins reconstruisent les fichiers minifiés et combinés lorsque vous videz leur cache), purgez le CDN, puis rechargez avec Ctrl+F5. Tester avec d'anciens fichiers optimisés est la raison la plus courante pour laquelle une exclusion correcte semble ne pas fonctionner.

Cache serveur impossible à désactiver

Les hébergeurs gérés exploitent souvent leur propre cache de page, impossible à désactiver. Réglez J'utilise un plugin de cache sur mon site (I am using cache plugin on my site) sur Oui (Yes) et videz le cache de l'hébergeur après la modification.

Laissez Pas de données GET dans le lien (No GET data in link) sur Non (No) : le sélecteur envoie alors le visiteur vers la même page avec ?currency=EUR, PHP construit cette page et enregistre le choix. Cela ne fonctionne que tant que les URL avec ce paramètre ne sont pas servies depuis le cache. De nombreux caches de page ignorent les URL avec une chaîne de requête, mais certains caches d'hébergeur stockent chacune d'elles comme une page distincte. Le choix n'est alors jamais enregistré, et la page suivante revient à la devise précédente. Demandez à l'hébergeur de contourner le cache pour le paramètre currency. S'il ne le peut pas, réglez Pas de données GET dans le lien (No GET data in link) sur Oui (Yes). Le choix est alors enregistré par une requête admin-ajax.php (wpcs_set_currency_ajax), que les caches de page ne stockent pas, et la page rechargée voit ses prix redessinés. Le même paramètre ?currency= permet aussi de créer un lien vers une page dans une devise donnée, comme le montre les liens de devise sans shortcode.

Requêtes bloquées : « Vous n'avez pas les droits suffisants » et 403

Quand les visiteurs non connectés voient Vous n'avez pas les droits suffisants pour accéder à cette page (You do not have sufficient permissions to access this page) lors du changement de devise, ou que les requêtes ci-dessus renvoient 403, quelque chose bloque admin-ajax.php pour les requêtes anonymes : le pare-feu d'un plugin de sécurité, une fonction « masquer ou verrouiller wp-admin », une règle du pare-feu de l'hébergeur ou la protection par mot de passe du dossier /wp-admin/. Le plugin utilise admin-ajax.php pour ces actions :

wpcs_get_prices_html : redessin des prix sur les pages en cache ;
wpcs_set_currency_ajax : changement de devise lorsque Pas de données GET dans le lien (No GET data in link) est sur Oui (Yes) ;
wpcs_convert_currency et wpcs_rates_current_currency : les shortcodes de convertisseur et de taux.

Désactivez les plugins de sécurité et d'optimisation un par un sur une copie de préproduction jusqu'à ce que la requête renvoie 200, puis autorisez admin-ajax.php avec ces actions dans les réglages de ce plugin, ou demandez à l'hébergeur de l'exclure de sa règle de pare-feu.

Liste de contrôle

Test effectué déconnecté, dans une fenêtre privée, après avoir vidé tous les caches et appuyé sur Ctrl+F5.
J'utilise un plugin de cache sur mon site (I am using cache plugin on my site) est sur Oui (Yes) partout où un cache de page est actif.
Aucune erreur rouge dans la console ; la requête wpcs_get_prices_html renvoie 200 et commence par {"prices":.
Le dossier du plugin, le script en ligne wpcs_ et jQuery sont exclus du délai, du report et de la combinaison.
admin-ajax.php n'est pas bloqué pour les visiteurs.
Les URL avec ?currency= ne sont pas servies depuis le cache, ou Pas de données GET dans le lien (No GET data in link) est sur Oui (Yes).

Si le sélecteur échoue toujours, ouvrez un sujet sur le forum d'assistance WPCS avec le lien de la page, les erreurs de la console, le statut et la réponse de la requête admin-ajax ainsi que la liste des outils de cache et d'optimisation du site.