FOX

Dans le mode où le client paie dans la devise sélectionnée, raw_woocommerce_price() est attaché à woocommerce_product_get_price, aux accesseurs de prix normal et promotionnel et aux accesseurs de variations. S'exécuter à 9999 le place après les autres extensions qui ajustent le prix de base. En mode affichage seul, seul le filtre raw_woocommerce_price est utilisé, de sorte que les montants enregistrés du panier et des commandes restent dans la devise de base.

Cas limites gérés dans le convertisseur : les prix vides passent sans modification, un parent variable interrogé avec display=false est ignoré pour éviter de convertir deux fois le min/max, et l'accesseur du prix promotionnel renvoie une chaîne vide quand aucun prix promotionnel n'est stocké. Sans cela, un prix promotionnel vide converti devient 0 et WooCommerce affiche un prix barré.

WooCommerce met en cache les tableaux de prix calculés d'un produit variable dans un transient indexé par un hachage des entrées de tarification. Si la devise ne fait pas partie de ce hachage, les prix convertis du premier visiteur sont servis à tout le monde. woocommerce_get_variation_prices_hash() ajoute la devise courante.

woocommerce_variation_prices() convertit ensuite chaque entrée, applique les prix fixes par variation et retrie chaque tableau avec asort(). La fourchette de prix est lue sur le premier et le dernier élément, et les prix fixes par devise peuvent changer l'ordre des variations par rapport à la devise de base.

Les prix fixes sont stockés comme meta de produit par champ et par devise (_woocs_regular_price_EUR, _woocs_sale_price_EUR), -1 signifiant « non défini, utiliser le taux ». Un prix fixe dans la devise du visiteur est utilisé tel quel. Sinon, un prix par pays remplace le prix de base et le résultat est converti par le taux. Les prix par pays regroupent les pays en blocs avec un prix par bloc, et le pays du visiteur provient de la géolocalisation WooCommerce enregistrée dans l'état du visiteur.

Les prix par rôle sont appliqués après cette étape. Lorsqu'un prix est défini pour le rôle de l'utilisateur, il remplace le prix retenu jusque-là, y compris un prix fixe par devise, et il est converti par le taux.

Lorsqu'un prix promotionnel par pays est laissé vide, get_product_geo_data() y copie le prix normal, sinon le produit deviendrait gratuit dans ce pays. Lorsqu'un champ de prix promotionnel fixe est vide, la recherche se rabat sur le champ de prix normal fixe.

Les prix fixes sont stockés par champ, mais woocommerce_product_get_price ne transmet qu'un nombre. get_price_type() compare la valeur entrante aux prix normal et promotionnel bruts du produit lus en contexte « edit ». Si aucun ne correspond, elle conserve une table statique du premier prix vu pour chaque produit dans la requête et traite une valeur plus grande, vue ensuite, comme le prix normal.

C'est une heuristique ; des types de champ explicites sont donc transmis partout où l'appelant les connaît. Les prix par rôle utilisent leur propre copie de la même logique.

La liste de prix facultative sous un produit est construite dans woocommerce_price_html(). Pour chaque devise, la devise courante est changée, la valeur est formatée avec les décimales et les séparateurs de cette devise, puis la devise d'origine est restaurée.

La fourchette d'un produit variable ne peut pas être calculée comme min/max de base multiplié par le taux, car certaines variations peuvent avoir des prix fixes. _get_min_max_variation_prices() recalcule le prix de chaque variation pour la devise cible et écarte les valeurs nulles. Les produits groupés parcourent leurs enfants et traitent de la même façon les enfants variables.

woocs_skip_conversion est vérifié en premier dans le convertisseur : une intégration qui a déjà tarifé un article dans la devise active retourne true et le montant passe sans modification. L'indicateur de requête woocs_block_price_hook désactive la conversion pour une section de code, utilisé par exemple pendant la construction des charges utiles des webhooks.

Pour la direction opposée, woocs_convert_price et woocs_back_convert_price permettent aux extensions tierces de convertir leurs propres montants en devise de base, et convert_from_to_currency() convertit entre deux devises quelconques de la boutique en passant par la base : value / rate_from * rate_to.

WooCommerce lit le nombre de décimales dans une seule option. FOX répond à cette option avec le réglage de la devise courante, et le convertisseur arrondit avec number_format() à la même précision, de sorte que la valeur enregistrée du panier et la valeur affichée concordent.

JPY et TWD sont codés en dur comme devises sans centimes, l'administrateur peut en ajouter d'autres, et le filtre woocs_precision_on_calc permet à un site de remplacer la précision par devise.

Les tarifs de livraison sont calculés dans la devise de base et convertis plus tard dans woocommerce_package_rates. S'ils étaient d'abord arrondis aux décimales de la devise du visiteur (par exemple 0 pour JPY), la valeur de base perdrait en précision avant la conversion. woocs_fix_decimals() renvoie les décimales de base lorsque add_rate se trouve dans la pile d'appels.

Il en va de même pour les tableaux de prix des variations : woocs_fix_variation_decimal() les formate avec les décimales de base avant que le convertisseur ne leur soit appliqué.

Les séparateurs décimal et des milliers sont filtrés par devise (six schémas dans get_decimal_sep() et get_thousand_sep()). Dans l'éditeur de commande de wp-admin, les champs de saisie de WooCommerce, leur validation JS et wc_format_decimal() supposent tous le séparateur de la boutique ; une virgule comme séparateur décimal changerait donc les montants enregistrés. Les séparateurs par devise sont donc désactivés dans l'éditeur de commande.

woocs_is_admin_order_edit_context() reconnaît par leur nom les actions AJAX de l'éditeur de commande, les autres appels AJAX par le referer (page wc-orders, type de contenu shop_order, ID du post de commande), ainsi que les écrans HPOS et historiques. La partie liée à la requête est mise en cache dans une variable statique ; le contrôle de l'écran est réévalué car get_current_screen() est vide au début de la requête. Les montants de remboursement saisis avec une virgule sont normalisés avant que WooCommerce ne les valide.

apply_conversion() s'exécute sur woocommerce_paypal_args et reformate chaque champ amount_* et tax_cart avec 0 décimale lorsque la devise courante n'a pas de centimes. enable_custom_currency() étend la liste blanche des devises PayPal de WooCommerce pour que la passerelle reste disponible lorsque le visiteur paie dans une devise autre que la devise de base.

Un taux tel que des jetons par USD peut être très inférieur à 0.0001, et la conversion de float en chaîne de PHP donne une notation exponentielle que le formulaire d'administration et l'e-mail de taux ne peuvent pas utiliser. rate_to_string() calcule le nombre de décimales à partir du log10 de la valeur, le plafonne à 20 et retire les zéros finaux.

WOOCS_STORAGE expose set_val/get_val/is_isset et bascule selon le backend configuré. Le stockage par transient est indexé par un hachage de l'IP du client, avec CF-Connecting-IP de préférence derrière Cloudflare, car Cloudflare écrase toute valeur fournie par le client. Memcached et Redis sont également pris en charge.

WOOCS_SESSION réutilise la table woocommerce_sessions avec un cookie signé par HMAC, lit via le cache d'objets, et n'écrit à l'arrêt (shutdown) que si les données ont changé.

Avec le stockage par transient et le mode cache activés, front.js crée une fois un identifiant aléatoire (crypto.randomUUID lorsqu'il est disponible) et l'envoie avec chaque requête. Le serveur l'assainit avec sanitize_key() et le hache dans la clé du transient, si bien que les utilisateurs d'un NAT de bureau ou d'un opérateur mobile ont des compartiments distincts. L'identifiant est généré en minuscules volontairement : sanitize_key() met en minuscules, et un identifiant en casse mixte donnerait un hachage, donc un compartiment, différent.

Dans ce mode, le transient vit 30 jours au lieu de 1, car la clé est stable pour un navigateur donné. Si localStorage est bloqué, le code se rabat silencieusement sur la clé IP.

Les requêtes jQuery reçoivent la clé par un gestionnaire ajaxSend, mais WooCommerce Blocks, la Store API et PayPal Payments utilisent fetch() et démarrent avant DOM ready. L'enveloppe est installée au niveau supérieur. La clé passe dans un en-tête X-WOOCS-SK, pas dans un argument de requête, car un argument de requête propre à chaque visiteur diviserait le cache de pages par visiteur. Les appels inter-origines sont laissés tels quels, puisqu'un en-tête personnalisé déclenche une requête CORS preflight qui peut casser les SDK de paiement.

Côté PHP, les requêtes wp-json vers les routes cart, store et batch gardent l'extension chargée pour que le panier et le paiement en blocs s'affichent dans la devise du visiteur.

woocommerce_price_html() enveloppe chaque prix dans un span portant l'ID du produit et un ID de redessin unique. Sur une page en cache, front.js collecte les marqueurs et les envoie à woocs_get_products_price_html ; le JSON des variations dans le formulaire d'ajout au panier et les shortcodes de prix personnalisés sont rafraîchis de la même façon. Un style de préchargement peut masquer les prix périmés jusqu'à l'arrivée de la réponse.

Le serveur renvoie une réponse vide quand la devise dans laquelle la page en cache a été rendue est déjà celle enregistrée pour le visiteur, si bien qu'un tel affichage de page ne coûte aucun rendu. Il ne rend get_price_html() que pour les produits publiés et visibles.

WooCommerce stocke les fragments du panier dans sessionStorage, indexés par le hachage du panier, et ce hachage ne dépend que du contenu du panier. FOX filtre woocommerce_cart_hash en md5(panier + devise), si bien qu'un changement invalide les fragments stockés et que la livraison est recalculée.

Lorsque la devise arrive dans l'URL sur une page en cache, front.js la reflète d'abord dans le compartiment de la clé du navigateur et ne déclenche wc_fragment_refresh qu'ensuite ; sinon, le rafraîchissement lirait un compartiment vide et se rabattrait sur la devise de base.

set_currency() ne stocke que les devises activées, et la valeur stockée est revérifiée à chaque requête, si bien qu'une devise retirée par l'administrateur retombe sur la devise de base. get_woocommerce_currency() ne renvoie jamais un code inconnu à WooCommerce, car WooCommerce l'écrirait sur la commande.

Les devises marquées comme privées ne peuvent pas être sélectionnées via ?currency= ni via le changement AJAX. La valeur de requête woocs_in_order_currency n'accepte une devise privée que pour les utilisateurs disposant de edit_shop_orders.

woocommerce_package_rates() multiplie le coût et chaque entrée de taxe par le taux et arrondit aux décimales de la devise. Un coût forfaitaire fixe par devise est stocké dans l'option de réglages d'instance de la méthode de livraison elle-même. Lorsqu'un coût fixe est utilisé, appliquer un facteur à l'ancienne taxe serait faux ; la taxe est donc recalculée avec WC_Tax::calc_shipping_tax().

Un coût forfaitaire tel que '[cost] * 0.1' reçoit le coût du panier dans la devise du visiteur, et le tarif de livraison obtenu est ensuite converti à nouveau dans woocommerce_package_rates. woocommerce_fix_shipping_calc() divise d'abord l'argument de coût par le taux, de sorte que la conversion n'a lieu qu'une fois.

La méthode de livraison gratuite compare le sous-total affiché à min_amount. Lorsque le client paie dans la devise sélectionnée, le sous-total du panier est dans cette devise ; la vérification est donc réimplémentée : le sous-total est reconverti avec le taux courant, la remise et la taxe sur la remise sont également reconverties, les réglages ignore_discounts et d'affichage des taxes sont respectés, et les exigences coupon/either/both sont évaluées comme dans WooCommerce.

Si un minimum fixe par devise est défini, il est lui aussi reconverti, de sorte que les deux côtés de la comparaison sont dans la devise de base.

woocommerce_coupon_loaded() convertit le montant du coupon (pas pour les types percent et percent_product) et les dépenses minimale et maximale, puis les réécrit avec les setters du coupon, si bien que toute la validation de WooCommerce s'exécute dans une seule devise. Les montants et limites de coupon fixes par devise, stockés comme meta du coupon, remplacent les valeurs converties.

En mode affichage seul, la devise est remise à la devise de base sur la page de paiement, sur checkout_process, sur le paiement en blocs et lors des mises à jour du récapitulatif de commande. En mode paiement dans la devise sélectionnée, la requête de paiement lit explicitement la devise stockée, et la devise peut en option être imposée par le pays du visiteur. Une commande en attente réglée plus tard depuis son lien de paiement est basculée sur la devise propre de la commande.

Les passerelles de paiement peuvent être masquées ou affichées par devise, car beaucoup de passerelles ne prennent en charge que certaines devises.

RateProvider::getRate() construit l'URL, récupère avec un délai d'expiration et délègue à parseResponse(). Les flux des banques centrales sont cotés par rapport à leur propre devise, les analyseurs calculent donc des taux croisés : la BCE est basée sur l'EUR, et le flux de la Banque de Russie porte aussi un Nominal (taux pour 10 ou 100 unités) qu'il faut diviser.

get_rate_provider() associe le nom de source configuré à un fichier de classe. Les sites peuvent ajouter leurs propres sources via les filtres woocs_add_custom_rate et woocs_add_aggregator_processor.

La source Pulse Verity renvoie un prix en USD pour n'importe quel symbole, si bien qu'un code de monnaie fiduciaire obtiendrait silencieusement le prix d'un jeton sans rapport. Le fournisseur vérifie d'abord une liste ISO 4217 codée en dur, car les extensions de paiement crypto ajoutent des jetons à la liste de devises de WooCommerce et cette liste n'est pas fiable. Il ne fonctionne qu'avec une base USD, envoie la clé d'API dans un en-tête Bearer, signale le code d'erreur propre à l'API pour toute réponse non 2xx (mauvaise clé, restriction du forfait, limite de débit) et rejette les prix nuls ou non numériques. Le prix USD par jeton renvoyé est inversé en jetons pour 1 USD.

PN_WP_CRON_WOOCS conserve le début, la prochaine exécution, l'intervalle et la dernière exécution par hook dans une seule option et est vérifié depuis init, admin_init et rest_api_init. Comme il est appelé à chaque requête, attach() doit être idempotent : avec un intervalle inchangé, elle laisse next intact, et lors d'un changement d'intervalle elle recalcule next à partir de la dernière exécution, plafonné à maintenant plus un intervalle. Les trois hooks sont enregistrés avec 0 argument accepté, car rest_api_init transmet l'objet WP_REST_Server, qui atterrirait sinon dans le paramètre $reset et relancerait le calendrier à chaque requête REST.

process() avance la prochaine exécution avant d'appeler le hook, intercepte et journalise les exceptions qu'il lève, et exécute chaque hook au plus une fois par requête. Le calendrier mis à jour est enregistré dans l'option une fois les hooks exécutés.

rate_auto_update() récupère chaque devise dans son propre bloc try et ne remplace un taux que par un nombre positif, si bien qu'une devise ou une source en échec n'arrête pas les autres et n'écrit jamais zéro ni un texte d'erreur comme taux. get_rate() fait passer chaque taux numérique par ExchangeRateLimiter, qui le borne à un plancher et un plafond facultatifs par devise. Après l'enregistrement, l'action woocs_sheduler_rates_updated permet à d'autre code de réagir.

Tous les taux sont stockés en unités pour 1 base, si bien qu'une nouvelle base rend tous les nombres faux d'un coup. save_etalon() enregistre l'indicateur de la nouvelle base, change default_currency en mémoire et appelle get_rate() pour chaque autre devise avant de répondre à l'écran d'administration, de sorte que le formulaire est rempli à nouveau avec des valeurs cohérentes.

La majoration est stockée à côté du taux sous forme de montant fixe ou de pourcentage et appliquée dans un filtre woocs_currency_data_manipulation à la priorité 1, si bien que chaque consommateur de get_currencies() voit le taux majoré. get_currencies(true) ignore les filtres lorsque la valeur brute est nécessaire.

Au paiement et sur la page de remerciement, le taux, la devise de base et un marqueur « modifié manuellement » sont écrits avec $order->update_meta_data(), ce qui fonctionne aussi bien avec HPOS qu'avec le stockage en posts. Si la devise courante ne figure pas dans la liste, le taux de base est utilisé. Les clés meta sont masquées dans l'affichage des lignes. Un administrateur peut corriger le taux enregistré depuis l'écran de la commande, et les lignes d'analyse des produits de la commande sont resynchronisées.

Le recalcul convertit les totaux de la commande, les sous-totaux et totaux des lignes, les tableaux de taxes par taux, les lignes de livraison et leurs taxes, les lignes de taxes et les remboursements. Avec HPOS, il passe par les setters CRUD, convertit aussi les lignes de frais et de coupons, et recalcule les taxes. Avec le stockage historique, il met à jour directement les post meta et les meta des lignes de commande, y compris la remise du panier de la commande.

Si un site définit woocs_order_recalculated_custom(), elle est appelée avant l'enregistrement avec la commande, les deux devises et l'ancien taux, pour les montants qui doivent garder une valeur fixe par devise. Une action groupée recalcule toutes les commandes dans la devise de base.

La devise courante appartient à celui qui a déclenché la requête : un administrateur qui termine une commande, une tâche cron, ou un client qui navigue dans une autre devise. FOX bascule sur la devise de la commande dans wc_get_template pour les templates d'e-mails, sur la notification de commande terminée et lors du renvoi d'un e-mail, pour le rendu des factures PDF, sur les listes et vues de commandes de Mon compte, dans l'aperçu de commande de l'administration, et par ligne de la liste des commandes HPOS via le filtre du nom de l'acheteur.

WooCommerce Analytics copie tels quels les montants des commandes dans ses propres tables de recherche, si bien que le chiffre d'affaires mélangerait les devises. WOOCS_analytics se branche sur woocommerce_analytics_update_product, _tax et _coupon, lit la ligne que WooCommerce vient d'écrire, divise chaque montant par le taux enregistré de la commande (ou le taux courant s'il n'y en a pas) et arrondit aux décimales de la base. Les anciens rapports WooCommerce sont adaptés de la même façon en reconvertissant chaque commande.

wp-admin s'exécute normalement dans la devise de base. Pour les actions AJAX de l'éditeur de commande (ajouter une ligne, enregistrer les lignes, recalculer les taxes), la devise courante est réglée sur celle de la commande, pour les utilisateurs qui peuvent modifier les commandes. Lorsqu'un produit ayant un prix fixe dans cette devise est ajouté manuellement, le sous-total et le total de la ligne sont fixés à partir du prix fixe et les totaux de la commande sont recalculés. Lorsqu'un coupon est ajouté dans l'éditeur, la devise courante est basculée sur celle de la commande.

Les systèmes de caisse et d'ERP synchronisent les prix via l'API REST de WooCommerce, et une requête peut porter la session d'un visiteur qui a sélectionné une autre devise. La variable serveur SCRIPT_URI utilisée par la garde REST générale existe sur Apache mais pas sur nginx ; la route est donc aussi analysée depuis REQUEST_URI avec rest_get_url_prefix(), ou depuis ?rest_route=, et l'extension retourne avant la création de son objet pour toute route wc/vN. La Store API et le namespace propre à FOX ne sont pas concernés.

woocs_validate_currency() répond avec la devise de la boutique lorsque l'objet de l'extension n'existe pas dans la requête. Édition premium.

La livraison asynchrone passe par Action Scheduler : la devise de base est activée à la priorité 1 de woocommerce_deliver_webhook_async et désactivée à 999. La livraison synchrone est plus délicate : depuis WooCommerce 4.4, les webhooks sont mis en file et livrés à l'arrêt (shutdown) ; FOX active donc la devise de base dans le filtre woocommerce_webhook_deliver_async seulement lorsqu'il est appelé à l'arrêt avec un WC_Webhook et async=false, et la désactive dans woocommerce_webhook_payload, juste après build_payload().

La livraison peut s'exécuter dans une requête qui porte les cookies d'un visiteur, donc la devise de ce visiteur. L'indicateur de conversion et current_currency sont tous deux basculés, car les prix fixes par devise lisent directement current_currency. Édition premium.

Les robots d'exploration peuvent arriver avec une devise dans l'URL. Les user agents de robots connus sont remis à la devise de base dans wp_head, sauf si l'administrateur le désactive. Indépendamment, structured_data_product_offer() fixe priceCurrency à la devise de base et divise les entrées price, lowPrice, highPrice et priceSpecification par le taux, de sorte que le balisage des produits reste cohérent avec la devise de la boutique.

L'export CSV des produits remet la devise à zéro avant sa requête, si bien que les prix exportés sont des valeurs de base qui peuvent être réimportées. Le chargement des variations dans l'éditeur de produit et chaque page wp-admin hors AJAX s'exécutent dans la devise de base. L'extension ne se charge pas pour les actions AJAX de l'éditeur en masse BEAR, pour le chargement des lignes de commande, pour les requêtes REST dont l'URL contient /refunds ou paypal (PayPal Payments), ni pour les remboursements en administration sauf si une extension connue en a besoin, car ces requêtes écrivent des montants stockés.

woocs/v3 expose la liste des devises, le prix d'un produit et un lot de prix de produits. Le callback ne règle la devise demandée que si elle existe dans la boutique, calcule les prix avec la même priorité que le convertisseur principal (fixe, pays, rôle, puis taux), renvoie des valeurs brutes par variation avec min et max ou du HTML, et restaure la devise précédente.

La devise de base de la boutique était AUD. Pendant la requête d'import, GeoIP avait basculé la devise courante sur USD, et l'importateur écrivait la devise courante sur chaque commande. Un appel à $WOOCS->reset_currency(), protégé par class_exists('WOOCS'), a été ajouté à deux endroits du code de commande de l'importateur, si bien que les commandes sont écrites dans la devise de base. C'est un correctif appliqué à l'importateur tiers, à réappliquer après chaque mise à jour de cette extension. Le client a confirmé que cela fonctionnait.