FOX

Nella modalità in cui il cliente paga nella valuta selezionata, raw_woocommerce_price() è collegata a woocommerce_product_get_price, ai getter del prezzo regolare e in offerta e ai getter delle varianti. Eseguirla a 9999 la pone dopo gli altri plugin che modificano il prezzo base. Nella modalità di sola visualizzazione si usa solo il filtro raw_woocommerce_price, così gli importi salvati di carrello e ordine restano nella valuta base.

Casi limite gestiti nel convertitore: i prezzi vuoti passano intatti, un genitore variabile interrogato con display=false viene saltato per evitare di convertire due volte min/max, e il getter del prezzo in offerta restituisce una stringa vuota quando non è salvato alcun prezzo in offerta. Senza questo, un prezzo in offerta vuoto convertito diventa 0 e WooCommerce mostra un prezzo barrato.

WooCommerce mette in cache gli array di prezzi calcolati di un prodotto variabile in un transient con chiave l'hash degli input di prezzo. Se la valuta non fa parte di quell'hash, i prezzi convertiti del primo visitatore vengono serviti a tutti. woocommerce_get_variation_prices_hash() aggiunge la valuta corrente.

woocommerce_variation_prices() converte poi ogni voce, applica i prezzi fissi per variante e riordina ogni array con asort(). L'intervallo di prezzo viene letto dal primo e dall'ultimo elemento, e i prezzi fissi per valuta possono cambiare l'ordine delle varianti rispetto alla valuta base.

I prezzi fissi sono salvati come meta del prodotto per campo e valuta (_woocs_regular_price_EUR, _woocs_sale_price_EUR), con -1 che significa 'non impostato, usare il tasso'. Un prezzo fisso nella valuta del visitatore viene usato così com'è. Altrimenti un prezzo per paese sostituisce il prezzo base, e il risultato viene convertito al tasso. I prezzi per paese raggruppano i paesi in blocchi con un prezzo per blocco, e il paese del visitatore proviene dalla geolocalizzazione di WooCommerce salvata nello stato del visitatore.

I prezzi per ruolo sono applicati dopo quel passaggio. Quando è impostato un prezzo per il ruolo dell'utente, sostituisce il prezzo scelto fino a quel momento, incluso un prezzo fisso per valuta, e viene convertito al tasso.

Quando un prezzo in offerta per paese è lasciato vuoto, get_product_geo_data() vi copia il prezzo regolare, altrimenti il prodotto diventerebbe gratuito in quel paese. Quando un campo fisso del prezzo in offerta è vuoto, la ricerca ripiega sul campo fisso del prezzo regolare.

I prezzi fissi sono salvati per campo, ma woocommerce_product_get_price passa solo un numero. get_price_type() confronta il valore in ingresso con i prezzi regolare e in offerta grezzi del prodotto letti nel contesto 'edit'. Se nessuno corrisponde, tiene una mappa statica del primo prezzo visto per ogni prodotto nella richiesta e considera prezzo regolare un valore successivo e più grande.

È un'euristica, perciò si passano tipi di campo espliciti ovunque il chiamante li conosca. I prezzi per ruolo usano una propria copia della stessa logica.

L'elenco opzionale dei prezzi sotto un prodotto è costruito dentro woocommerce_price_html(). Per ogni valuta si cambia la valuta corrente, il valore viene formattato con i decimali e i separatori di quella valuta, e al termine viene ripristinata la valuta originale.

L'intervallo di un prodotto variabile non può essere calcolato come min/max base per il tasso, perché le singole varianti possono avere prezzi fissi. _get_min_max_variation_prices() ricalcola il prezzo di ogni variante per la valuta di destinazione e scarta i valori zero. I prodotti raggruppati iterano i loro figli e gestiscono allo stesso modo i figli variabili.

woocs_skip_conversion viene controllato per primo nel convertitore: un'integrazione che ha già fissato il prezzo di un articolo nella valuta attiva restituisce true e l'importo passa intatto. Il flag di richiesta woocs_block_price_hook disattiva la conversione per una sezione di codice, usato per esempio mentre si costruiscono i payload dei webhook.

Per la direzione opposta, woocs_convert_price e woocs_back_convert_price permettono ai plugin di terze parti di convertire i propri importi nella valuta base, e convert_from_to_currency() converte tra due valute qualsiasi del negozio passando dalla base: value / rate_from * rate_to.

WooCommerce legge il numero di decimali da una sola opzione. FOX risponde a quell'opzione con l'impostazione della valuta corrente, e il convertitore arrotonda con number_format() alla stessa precisione, così il valore salvato nel carrello e quello mostrato coincidono.

JPY e TWD sono codificati nel codice come valute senza centesimi, l'amministratore può aggiungerne altre, e il filtro woocs_precision_on_calc permette a un sito di sovrascrivere la precisione per valuta.

Le tariffe di spedizione sono calcolate nella valuta base e convertite più tardi in woocommerce_package_rates. Se fossero prima arrotondate ai decimali della valuta del visitatore (per esempio 0 per JPY), il valore base perderebbe precisione prima della conversione. woocs_fix_decimals() restituisce i decimali base quando add_rate è nello stack delle chiamate.

Lo stesso vale per gli array dei prezzi delle varianti: woocs_fix_variation_decimal() li formatta con i decimali base prima che il convertitore li elabori.

I separatori decimali e delle migliaia sono filtrati per valuta (sei schemi in get_decimal_sep() e get_thousand_sep()). Nell'editor degli ordini in wp-admin, i campi di input di WooCommerce, la loro validazione JS e wc_format_decimal() presuppongono tutti il separatore del negozio, perciò un separatore decimale a virgola lì cambierebbe gli importi salvati. I separatori per valuta sono quindi disattivati nell'editor degli ordini.

woocs_is_admin_order_edit_context() riconosce per nome le azioni AJAX dell'editor degli ordini, le altre chiamate AJAX dal referer (pagina wc-orders, post type shop_order, ID del post dell'ordine) e le schermate HPOS e legacy. La parte relativa alla richiesta è messa in cache in una variabile statica; il controllo della schermata viene rivalutato perché get_current_screen() è vuota all'inizio della richiesta. Gli importi dei rimborsi digitati con la virgola vengono normalizzati prima che WooCommerce li validi.

apply_conversion() gira su woocommerce_paypal_args e riformatta ogni campo amount_* e tax_cart con 0 decimali quando la valuta corrente non ha centesimi. enable_custom_currency() estende la whitelist delle valute PayPal di WooCommerce, così il gateway resta disponibile quando il visitatore paga in una valuta diversa da quella base.

Un tasso come monete per USD può essere molto inferiore a 0.0001, e la conversione float-stringa di PHP dà una notazione con esponente che il modulo di amministrazione e l'e-mail dei tassi non possono usare. rate_to_string() calcola il numero di decimali dal log10 del valore, lo limita a 20 e rimuove gli zeri finali.

WOOCS_STORAGE espone set_val/get_val/is_isset e commuta sul backend configurato. L'archiviazione in transient usa come chiave l'hash dell'IP del client, con preferenza per CF-Connecting-IP dietro Cloudflare perché Cloudflare sovrascrive qualsiasi valore fornito dal client. Sono supportati anche Memcached e Redis.

WOOCS_SESSION riutilizza la tabella woocommerce_sessions con un cookie firmato HMAC, legge tramite l'object cache e scrive allo shutdown solo quando i dati sono cambiati.

Con l'archiviazione in transient e la modalità cache attive, front.js crea una sola volta un ID casuale (crypto.randomUUID quando disponibile) e lo invia con ogni richiesta. Il server lo sanifica con sanitize_key() e ne calcola l'hash per la chiave del transient, così gli utenti di un NAT d'ufficio o di un operatore mobile ottengono contenitori separati. L'ID è generato in minuscolo di proposito: sanitize_key() converte in minuscolo, e un ID con maiuscole e minuscole darebbe l'hash di un contenitore diverso.

In questa modalità il transient vive 30 giorni invece di 1, perché la chiave è stabile per browser. Se localStorage è bloccato il codice ripiega in silenzio sulla chiave IP.

Le richieste jQuery ricevono la chiave tramite un gestore ajaxSend, ma WooCommerce Blocks, la Store API e PayPal Payments usano fetch() e partono prima del DOM ready. Il wrapper è installato al livello superiore. La chiave va in un header X-WOOCS-SK, non in un argomento della query, perché un argomento di query per visitatore spezzerebbe la cache di pagina per visitatore. Le chiamate cross-origin sono lasciate stare, dato che un header personalizzato innesca un preflight CORS che può rompere gli SDK di pagamento.

Lato PHP, le richieste wp-json verso le route cart, store e batch mantengono il plugin caricato così che il carrello e il checkout a blocchi vengano renderizzati nella valuta del visitatore.

woocommerce_price_html() avvolge ogni prezzo in uno span con l'ID del prodotto e un ID di ridisegno univoco. In una pagina in cache front.js raccoglie i marcatori e li invia a woocs_get_products_price_html; il JSON delle varianti nel modulo add-to-cart e gli shortcode di prezzo personalizzati vengono aggiornati allo stesso modo. Uno stile di preloader può nascondere i prezzi obsoleti finché non arriva la risposta.

Il server restituisce una risposta vuota quando la valuta in cui la pagina in cache è stata renderizzata coincide già con quella salvata del visitatore, così quella visualizzazione di pagina non costa alcun rendering. Renderizza get_price_html() solo per i prodotti pubblicati e visibili.

WooCommerce salva i frammenti del carrello in sessionStorage con chiave l'hash del carrello, e l'hash dipende solo dal contenuto del carrello. FOX filtra woocommerce_cart_hash in md5(carrello + valuta), così un cambio invalida i frammenti salvati e la spedizione viene ricalcolata.

Quando la valuta arriva nell'URL su una pagina in cache, front.js la rispecchia prima nel contenitore della chiave del browser e solo dopo attiva wc_fragment_refresh, altrimenti l'aggiornamento leggerebbe un contenitore vuoto e ripiegherebbe sulla valuta base.

set_currency() salva solo le valute abilitate, e il valore salvato viene ricontrollato a ogni richiesta, così una valuta rimossa dall'amministratore ripiega sulla base. get_woocommerce_currency() non restituisce mai a WooCommerce un codice sconosciuto, perché WooCommerce lo scriverebbe sull'ordine.

Le valute marcate come private non possono essere selezionate tramite ?currency= o l'interruttore AJAX. Il valore di richiesta woocs_in_order_currency accetta una valuta privata solo per gli utenti con edit_shop_orders.

woocommerce_package_rates() moltiplica costo e ogni voce di imposta per il tasso e arrotonda ai decimali della valuta. Un costo fisso flat-rate per valuta è salvato nell'opzione delle impostazioni dell'istanza del metodo di spedizione. Quando si usa un costo fisso, scalare la vecchia imposta sarebbe sbagliato, perciò l'imposta viene ricalcolata con WC_Tax::calc_shipping_tax().

Un costo flat-rate come '[cost] * 0.1' riceve il costo del carrello nella valuta del visitatore, e la tariffa di spedizione risultante viene poi convertita di nuovo in woocommerce_package_rates. woocommerce_fix_shipping_calc() divide prima l'argomento del costo per il tasso, così la conversione avviene una volta sola.

Il metodo di spedizione gratuita confronta il subtotale mostrato con min_amount. Quando il cliente paga nella valuta selezionata, il subtotale del carrello è in quella valuta, perciò il controllo è reimplementato: il subtotale viene riconvertito con il tasso corrente, anche lo sconto e l'imposta sullo sconto vengono riconvertiti, le impostazioni ignore_discounts e di visualizzazione delle imposte sono rispettate, e i requisiti coupon/either/both sono valutati come in WooCommerce.

Se è impostato un minimo fisso per valuta, anche questo viene riconvertito, così entrambi i lati del confronto sono nella valuta base.

woocommerce_coupon_loaded() converte l'importo del coupon (non per i tipi percent e percent_product) e la spesa minima e massima, poi li riscrive con i setter del coupon, così tutta la validazione di WooCommerce gira in una sola valuta. Gli importi e i limiti fissi dei coupon per valuta, salvati come meta del coupon, sovrascrivono i valori convertiti.

Nella modalità di sola visualizzazione la valuta viene riportata alla base nella pagina di checkout, su checkout_process, nel checkout a blocchi e negli aggiornamenti della revisione dell'ordine. Nella modalità di pagamento nella valuta selezionata la richiesta di checkout legge esplicitamente la valuta salvata, e facoltativamente la valuta viene forzata dal paese del visitatore. Un ordine in sospeso pagato più tardi dal suo link di pagamento viene portato sulla valuta propria dell'ordine.

I gateway di pagamento possono essere nascosti o mostrati per valuta, dato che molti gateway supportano solo alcune valute.

RateProvider::getRate() costruisce l'URL, recupera con un timeout e delega a parseResponse(). I feed delle banche centrali sono quotati rispetto alla propria valuta, perciò i parser calcolano i tassi incrociati: la BCE è basata su EUR, e il feed della Banca di Russia porta anche un Nominal (tasso per 10 o 100 unità) da dividere.

get_rate_provider() associa il nome della fonte configurata a un file di classe. I siti possono aggiungere le proprie fonti tramite i filtri woocs_add_custom_rate e woocs_add_aggregator_processor.

La fonte Pulse Verity restituisce un prezzo in USD per qualsiasi simbolo, quindi a un codice fiat verrebbe silenziosamente assegnato il prezzo di un token non correlato. Il provider controlla prima un elenco ISO 4217 scritto nel codice, perché i plugin di pagamento crypto aggiungono monete all'elenco valute di WooCommerce e quell'elenco non è affidabile. Funziona solo con base USD, invia la chiave API come header Bearer, riporta il codice di errore proprio dell'API per qualsiasi risposta non 2xx (chiave errata, restrizione del piano, limite di frequenza) e rifiuta prezzi zero o non numerici. Il prezzo in USD per moneta restituito viene invertito in monete per 1 USD.

PN_WP_CRON_WOOCS conserva inizio, prossima esecuzione, intervallo e ultima esecuzione per hook in una sola opzione ed è controllato da init, admin_init e rest_api_init. Poiché viene chiamato a ogni richiesta, attach() deve essere idempotente: con un intervallo invariato lascia next intatto, e a un cambio di intervallo ricalcola next dall'ultima esecuzione, limitato a ora più un intervallo. I tre hook sono registrati con 0 argomenti accettati, perché rest_api_init passa l'oggetto WP_REST_Server, che altrimenti finirebbe nel parametro $reset e riavvierebbe la pianificazione a ogni richiesta REST.

process() sposta avanti la prossima esecuzione prima di chiamare l'hook, intercetta e registra le eccezioni da esso sollevate, ed esegue ogni hook al massimo una volta per richiesta. La pianificazione aggiornata viene salvata nell'opzione dopo l'esecuzione degli hook.

rate_auto_update() recupera ogni valuta nel proprio blocco try e sostituisce un tasso solo con un numero positivo, così una valuta o una fonte che fallisce non ferma le altre e non scrive mai zero né un testo di errore come tasso. get_rate() fa passare ogni tasso numerico per ExchangeRateLimiter, che lo limita a un minimo e un massimo opzionali per valuta. Dopo il salvataggio, l'azione woocs_sheduler_rates_updated permette ad altro codice di reagire.

Tutti i tassi sono salvati come unità per 1 base, perciò una nuova base rende sbagliati tutti i numeri in una volta. save_etalon() salva il flag della nuova base, cambia default_currency in memoria e chiama get_rate() per ogni altra valuta prima di rispondere alla schermata di amministrazione, così il modulo viene riempito di nuovo con valori coerenti.

Il ricarico è salvato accanto al tasso come importo fisso o percentuale e applicato in un filtro woocs_currency_data_manipulation con priorità 1, così ogni consumatore di get_currencies() vede il tasso con il ricarico. get_currencies(true) salta i filtri quando serve il valore grezzo.

Al checkout e nella pagina di ringraziamento il tasso, la valuta base e un marcatore 'changed manually' vengono scritti con $order->update_meta_data(), che funziona sia con HPOS sia con l'archiviazione dei post. Se la valuta corrente non è nell'elenco, si usa il tasso base. Le chiavi meta sono nascoste dalla visualizzazione degli articoli. Un amministratore può correggere il tasso salvato dalla schermata dell'ordine, e le righe analytics dei prodotti dell'ordine vengono risincronizzate.

Il ricalcolo converte totali dell'ordine, subtotali e totali delle righe, array delle imposte per aliquota, righe di spedizione e relative imposte, righe di imposta e rimborsi. Con HPOS passa dai setter CRUD, converte anche le righe di costo aggiuntivo e le righe coupon, e ricalcola le imposte. Con l'archiviazione legacy aggiorna direttamente i meta del post e i meta degli articoli dell'ordine, incluso lo sconto carrello dell'ordine.

Se un sito definisce woocs_order_recalculated_custom(), questa viene chiamata prima del salvataggio con l'ordine, entrambe le valute e il vecchio tasso, per gli importi che devono mantenere un valore fisso per valuta. Un'azione di massa ricalcola tutti gli ordini nella valuta base.

La valuta corrente appartiene a chi ha innescato la richiesta: un amministratore che completa un ordine, un job cron o un cliente che naviga in un'altra valuta. FOX passa alla valuta dell'ordine in wc_get_template per i template delle e-mail, nella notifica di completamento e nel reinvio dell'e-mail, per il rendering delle fatture PDF, negli elenchi e nelle viste degli ordini di My Account, nell'anteprima dell'ordine in amministrazione e per ogni riga dell'elenco ordini HPOS tramite il filtro sul nome dell'acquirente.

WooCommerce Analytics copia gli importi degli ordini nelle proprie tabelle di lookup così come sono, quindi il fatturato mescolerebbe valute. WOOCS_analytics si aggancia a woocommerce_analytics_update_product, _tax e _coupon, legge la riga appena scritta da WooCommerce, divide ogni importo per il tasso salvato dell'ordine (o per il tasso corrente se non ce n'è uno) e arrotonda ai decimali base. I report legacy di WooCommerce sono adattati allo stesso modo riconvertendo ogni ordine.

wp-admin normalmente gira nella valuta base. Per le azioni AJAX dell'editor degli ordini (aggiungi articolo, salva articoli, ricalcola le imposte) la valuta corrente viene impostata su quella dell'ordine, per gli utenti che possono modificare gli ordini. Quando si aggiunge a mano un prodotto con un prezzo fisso in quella valuta, subtotale e totale dell'articolo sono impostati dal prezzo fisso e i totali dell'ordine vengono ricalcolati. Quando si aggiunge un coupon nell'editor, la valuta corrente passa a quella dell'ordine.

I sistemi POS ed ERP sincronizzano i prezzi tramite la REST API di WooCommerce, e una richiesta può portare la sessione di un visitatore che ha selezionato un'altra valuta. La variabile server SCRIPT_URI usata dalla protezione REST generale esiste su Apache ma non su nginx, perciò la route viene analizzata anche da REQUEST_URI con rest_get_url_prefix(), o da ?rest_route=, e il plugin termina prima che il suo oggetto sia creato per qualsiasi route wc/vN. La Store API e il namespace proprio di FOX non sono interessati.

woocs_validate_currency() risponde con la valuta del negozio quando l'oggetto del plugin non esiste nella richiesta. Edizione premium.

La consegna asincrona passa da Action Scheduler: la valuta base viene attivata con priorità 1 di woocommerce_deliver_webhook_async e disattivata a 999. La consegna sincrona è più difficile: da WooCommerce 4.4 i webhook sono messi in coda e consegnati allo shutdown, perciò FOX attiva la valuta base dentro il filtro woocommerce_webhook_deliver_async solo quando viene chiamato allo shutdown con un WC_Webhook e async=false, e la disattiva in woocommerce_webhook_payload, subito dopo build_payload().

La consegna può avvenire in una richiesta che porta i cookie di un visitatore e quindi la sua valuta. Vengono commutati sia il flag di conversione sia current_currency, perché i prezzi fissi per valuta leggono current_currency direttamente. Edizione premium.

I crawler possono arrivare con una valuta nell'URL. Gli user agent dei bot noti sono riportati alla valuta base in wp_head, a meno che l'amministratore non lo disattivi. In modo indipendente, structured_data_product_offer() imposta priceCurrency sulla base e divide per il tasso le voci price, lowPrice, highPrice e priceSpecification, così il markup dei prodotti resta coerente con la valuta del negozio.

L'esportazione CSV dei prodotti reimposta la valuta prima della sua query, così i prezzi esportati sono valori base che possono essere reimportati. Il caricamento delle varianti nell'editor del prodotto e ogni pagina wp-admin non AJAX girano nella valuta base. Il plugin non si carica per le azioni AJAX dell'editor di massa BEAR, per il caricamento degli articoli dell'ordine, per le richieste REST il cui URL contiene /refunds o paypal (PayPal Payments), e per i rimborsi lato backend a meno che un plugin noto non ne abbia bisogno, perché quelle richieste scrivono importi salvati.

woocs/v3 espone l'elenco delle valute, il prezzo di un prodotto e un lotto di prezzi di prodotti. La callback imposta la valuta richiesta solo se esiste nel negozio, calcola i prezzi con la stessa precedenza del convertitore principale (fisso, paese, ruolo, poi tasso), restituisce valori grezzi per variante con min e max oppure HTML, e ripristina la valuta precedente.

La valuta base dello shop era AUD. Durante la richiesta di importazione GeoIP aveva portato la valuta corrente su USD, e l'importatore scriveva la valuta corrente su ogni ordine. Una chiamata a $WOOCS->reset_currency(), protetta da class_exists('WOOCS'), è stata aggiunta in due punti del codice degli ordini dell'importatore, così gli ordini vengono scritti nella valuta base. È una patch all'importatore di terze parti e va riapplicata dopo ogni aggiornamento di quel plugin. Il cliente ha confermato che ha funzionato.