{"id":11868,"date":"2026-09-19T04:06:18","date_gmt":"2026-09-18T20:06:18","guid":{"rendered":"https:\/\/aeosub.com\/mhm-currency-switcher\/"},"modified":"2026-09-19T04:06:18","modified_gmt":"2026-09-18T20:06:18","slug":"mhm-currency-switcher","status":"publish","type":"post","link":"https:\/\/aeosub.com\/zh\/mhm-currency-switcher\/","title":{"rendered":"MHM Currency Switcher"},"content":{"rendered":"
\"MHM<\/div>\n
\n
LethaldiranMX Insight<\/div>\n
\n
\n

MHM Currency Switcher addresses a critical pain point for international WooCommerce stores by decoupling front-end currency display from back-end transactional processing. Its architectural highlight is a dedicated cache compatibility mode that leverages client-side REST requests to dynamically update prices, preventing the common caching issue where one user’s currency selection is served to another. By keeping cart and checkout calculations strictly server-side while offering flexible display options like Elementor widgets and geolocation, it provides a robust framework for localized pricing without sacrificing site performance.<\/p>\n

Best Fit & Operational Role:<\/strong> This plugin is an excellent fit for scaling WooCommerce merchants targeting global markets who rely heavily on page caching layers\u2014such as Varnish, Cloudflare, or server-level Nginx caching\u2014and need to display localized pricing without breaking their cache hit rates. It integrates cleanly into modern WordPress stacks utilizing High-Performance Order Storage (HPOS) and Elementor, solving the operational challenge of displaying real-time exchange rates while maintaining transactional integrity during checkout.<\/p>\n

Potential Limitations & Pitfalls:<\/strong> The primary operational trade-off lies in the cache compatibility mode: because anonymous product and archive pages are initially rendered in the base currency and updated via a client-side REST request, users may experience a brief visual price transition as prices convert on page load. Additionally, relying on an external service (ExchangeRate-API) for automatic rate updates introduces an external dependency that requires monitoring, and disabling the cache compatibility mode altogether can lead to severe caching conflicts on highly optimized hosting environments.<\/p>\n<\/div>\n<\/div><\/div>\n

\n
\n \"MHM <\/p>\n
\n
Plugin Specification<\/div>\n

WordPress.org Official Data<\/small>\n <\/div>\n<\/p><\/div>\n\n\n\n\n\n\n\n
Developer<\/th>\nMHM Development Team<\/a><\/td>\n<\/tr>\n
Version<\/th>\nv2.2.1<\/td>\n<\/tr>\n
Active Installs<\/th>\n10 +<\/td>\n<\/tr>\n
Requires \/ Tested<\/th>\n6.6 \/ 7.1.1<\/td>\n<\/tr>\n
Last Updated<\/th>\n2026-09-18 8:04pm GMT<\/td>\n<\/tr>\n
Official Link<\/th>\nView Details -><\/a><\/td>\n<\/tr>\n<\/table><\/div>\n
Multi-currency support for WooCommerce. Let your customers browse, shop, and checkout in their preferred currency with real-time exchange rates.<\/div>\n

MHM Currency Switcher adds multi-currency support to your WooCommerce store. Customers can browse products, add items to their cart, and complete checkout in their preferred currency with real-time exchange rates.<\/p>\n

Key Features<\/strong><\/p>\n

    \n
  • Add multiple currencies with real-time exchange rates<\/li>\n
  • Cache compatibility mode \u2014 works behind a page cache without serving one visitor’s currency to everybody<\/li>\n
  • Currency switcher via shortcode \u2014 usable in a text widget, nav menu, or Elementor<\/li>\n
  • Product page price display widget with country flags<\/li>\n
  • Navigation menu integration \u2014 add switcher to any WordPress menu<\/li>\n
  • Automatic exchange rate fetching (ExchangeRate-API)<\/li>\n
  • Fee & rounding configuration per currency<\/li>\n
  • Cookie-based currency persistence<\/li>\n
  • WooCommerce HPOS compatible<\/li>\n
  • Elementor widgets included<\/li>\n
  • Every currency WooCommerce offers<\/li>\n
  • Scheduled automatic exchange rate updates<\/li>\n
  • Geolocation-based currency detection<\/li>\n
  • Fixed prices per product<\/li>\n
  • “How to use” tab in the settings screen, naming every way the switcher can be placed<\/li>\n<\/ul>\n

    Cache compatibility mode<\/strong><\/p>\n

    A page cache stores the HTML your server produced for whoever asked first. When
    \nprices are converted on the server, that means the first visitor’s currency is
    \nwhat every later visitor is served. Cache compatibility mode, which is on by
    \ndefault, avoids this: anonymous shop, archive and product pages are rendered in
    \nyour base currency, so the same cached page is correct for everyone, and the
    \nbrowser converts the prices it can see afterwards through a REST request to this
    \nplugin.<\/p>\n

    The split is deliberate. Only displayed<\/em> prices are converted in the browser.
    \nCart, checkout, order totals, order emails and the WooCommerce REST API are
    \nalways calculated on the server in the currency the customer actually chose, so
    \nthe amount charged cannot be altered from the browser.<\/p>\n

    You can switch the mode off under WooCommerce > MHM Currency >
    \nAdvanced<\/strong>, in which case prices are converted on the server as they were before
    \nthis feature existed. Read “Known limits” below before deciding either way \u2014
    \nboth settings have consequences, and they are different ones.<\/p>\n

    Known limits<\/h3>\n

    These are consequences of how cache compatibility mode works, not defects. They
    \nare listed so you can decide with your eyes open.<\/p>\n

    Turning the mode off does not restore the exact 1.0.0 behaviour<\/h4>\n

    Three fixes sit above the setting and stay in place whether it is on or off:
    \nprices are no longer converted on admin screens or in admin AJAX (which used to
    \nwrite a converted price into an order line item), wc\/v3<\/code> REST reads are pinned
    \nto the base currency, and scheduled tasks and WP-CLI no longer convert. Switching
    \nthe mode off restores the 1.0.0 display<\/em> behaviour \u2014 prices converted on the
    \nserver \u2014 and nothing else.<\/p>\n

    Search engines and crawlers see your base prices<\/h4>\n

    With the mode on, the page a crawler fetches has not been through the browser,
    \nso it carries base-currency prices, and so does the machine-readable product data
    \nin it. See the structured data question above; the mismatch is deliberate.<\/p>\n

    Converted prices replace the base ones a moment after the page appears<\/h4>\n

    The page arrives with your base-currency prices already on screen \u2014 nothing is
    \nhidden waiting for JavaScript \u2014 and the browser swaps in the converted ones as
    \nsoon as its request comes back, each price fading over 200ms as it changes. On a
    \nslow connection the base price is readable for longer before the swap. Visitors
    \nwho have asked their system for reduced motion get the swap without the fade.<\/p>\n

    With JavaScript disabled, or the endpoint unreachable, base prices stay<\/h4>\n

    Nothing breaks and no error is shown to the visitor \u2014 the page simply keeps the
    \nbase-currency prices it was rendered with, and the reason is written to the
    \nbrowser console. Cart and checkout are unaffected, because they never depended
    \non the browser in the first place.<\/p>\n

    Variable products make one extra request, and some swatch plugins lose the price<\/h4>\n

    On a cacheable page the plugin forces WooCommerce to fetch variation prices over
    \nAJAX, because the variations JSON WooCommerce would otherwise embed in the page
    \ncarries base-currency prices that its own scripts write straight into the page.
    \nThe cost is one request when a visitor picks a variation, and that
    \n data-product_variations is false<\/code>: third-party colour or size swatch plugins
    \nthat read prices out of that JSON instead of asking WooCommerce may stop showing
    \na price. If you use such a plugin, check a variable product before going live.<\/p>\n

    The mini-cart relies on WooCommerce cart fragments<\/h4>\n

    A mini-cart is rendered on every page, so it cannot be classified per request.
    \nIt is rendered in the base currency and then corrected by WooCommerce’s own cart
    \nfragment refresh, which is a server-side conversion. If cart fragments are
    \ndisabled on your site \u2014 some themes and optimisation plugins dequeue them \u2014 the
    \ncached mini-cart total stays in the base currency while the rest of the page
    \nconverts. The plugin watches for this and says so in the admin when it happens;
    \na site with no mini-cart at all is never warned about it.<\/p>\n

    A cart or checkout on a page WooCommerce does not know about must be excluded from your cache<\/h4>\n

    Page caches exclude cart and checkout automatically because they recognise the
    \npages WooCommerce assigned. If you have put a cart or checkout shortcode or block
    \non some other page, exclude that page yourself. Two things go wrong otherwise:
    \nthe conversion decision flips to “convert” partway through the render, so the
    \nrest of the page is printed already converted and without the markers the browser
    \nlooks for, and blocks-based cart and checkout embed their amounts in the page as
    \nJSON while rendering. Either way the first visitor’s currency is what the cache
    \nthen hands to everyone. Cart contents are personal anyway; such a page should not
    \nbe cached.<\/p>\n

    `?currency=` multiplies your cache entries<\/h4>\n

    A currency can be requested in the URL, and a cache treats every distinct URL as
    \na separate entry, so linking to ?currency=EUR<\/code> and ?currency=GBP<\/code> stores the
    \nsame page more than once. The switcher itself does not produce these URLs \u2014 it
    \nwrites a cookie and leaves the address alone. On a cached page it converts the
    \nprices where they stand; on the cart page, for a logged-in visitor, or with
    \ncache compatibility switched off, it reloads instead. Either way the URL is the
    \none the visitor was already on, so no extra cache entry is created.<\/p>\n

    A ?currency=<\/code> link also applies to that page view only: it deliberately sets no
    \ncookie, so the next page the visitor opens is back in your base currency unless
    \nthey use the switcher. That is not an oversight \u2014 a link that silently pinned a
    \ncurrency could show one currency in the catalogue while the cart, which reads
    \nthe cookie, charged another. If you want a campaign link that sticks, send
    \nvisitors to a page carrying the switcher rather than relying on the parameter.<\/p>\n

    WooCommerce Analytics adds different currencies together<\/h4>\n

    An order is stored in the currency the customer paid in, and WooCommerce
    \nAnalytics reports every order’s figures in your store currency without
    \nconverting them back. A 4.38 USD order is counted as 4.38 in your base
    \ncurrency, so once you take orders in more than one currency the revenue
    \nfigures in Analytics, and the totals in the customer panel on the order
    \nscreen, are sums of unlike amounts. The orders themselves are correct \u2014 each
    \none keeps its own currency, total and the exchange rate it was placed at, and
    \nthis plugin stores that rate on the order. It is the aggregate reports that
    \ncannot be read as money. Nothing in this plugin can fix that from the outside;
    \nif you need accurate multi-currency reporting, export the orders and convert
    \nthem using the rate recorded on each one.<\/p>\n

    Logged-in visitors are converted on the server<\/h4>\n

    Logged-in visitors take the server-side path, which is correct as long as your
    \ncache does what nearly all of them do and never serves cached pages to logged-in
    \nusers. An edge cache or CDN configured to cache without looking at cookies is the
    \nexception, and there a logged-in visitor’s converted page can be stored and
    \nserved on. If you cache at the edge, confirm it varies on the login cookie.<\/p>\n

    External services<\/h3>\n

    This plugin connects to two third-party services to keep currency conversion
    \nrates up to date. What each one is sent, and when, is described separately
    \nbelow because the two are not the same. Both requests are made with PHP’s
    \n WP_Http transport, which in WordPress’s default configuration sends a
    \n User-Agent header of the form WordPress\/{version}; {your site's URL}<\/code> —
    \nso the site’s own address leaves with every request to either service, not
    \njust the data described below. That header is filterable
    \n(http_headers_useragent<\/code>, http_request_args<\/code>), so a site that has changed
    \nit will send something different.<\/p>\n

    ExchangeRate-API<\/strong><\/p>\n

    What it is: a commercial exchange-rate API, used as the primary source of
    \nexchange rates.<\/p>\n

    What is sent, and when: the three-letter base currency code you have
    \nconfigured (for example USD<\/code>), sent as part of the request URL —
    \n https:\/\/api.exchangerate-api.com\/v4\/latest\/{BASE_CURRENCY} — when you
    \npress “Sync rates” in the admin panel, when you run wp mhmcs rates-sync<\/code>
    \nfrom the command line, and on the schedule you configure under automatic
    \nrate updates (hourly, twice daily, or daily). No other data from your site
    \nis included.<\/p>\n

    Terms of service and privacy policy: https:\/\/www.exchangerate-api.com\/terms
    \n(ExchangeRate-API publishes its privacy policy inside that same page rather
    \nthan on a separate one.)<\/p>\n

    European Central Bank (ECB) daily reference rates<\/strong><\/p>\n

    What it is: the ECB’s public daily reference-rate feed, used as the fallback
    \nwhen ExchangeRate-API cannot be reached.<\/p>\n

    What is sent, and when: nothing beyond the User-Agent described above. The
    \nfeed is a fixed, parameter-free address —
    \n https:\/\/www.ecb.europa.eu\/stats\/eurofxref\/eurofxref-daily.xml — so no
    \ncurrency code or other value is sent to the ECB; the same document is
    \nreturned to every requester. It is only requested when ExchangeRate-API’s
    \nrequest has failed. The feed is EUR-based and covers roughly thirty
    \ncurrencies rather than the hundreds ExchangeRate-API carries. If your base
    \ncurrency is outside that set, this source returns nothing at all and your
    \nexisting rates are left unchanged until the next attempt; if only one of
    \nyour configured target currencies is outside that set, the other target
    \ncurrencies still update and the unsupported one is simply left without a
    \nrate from this source.<\/p>\n

    The ECB does not publish a document titled “Terms of Service.” Its terms of
    \nuse are stated on its Disclaimer & Copyright page, which is the closest
    \nequivalent and is linked below.<\/p>\n

    Disclaimer & Copyright (terms of use): https:\/\/www.ecb.europa.eu\/services\/using-our-site\/disclaimer\/html\/index.en.html
    \nPrivacy statement: https:\/\/www.ecb.europa.eu\/services\/data-protection\/privacy-statements\/html\/ecb.privacy_statement_website.en.html<\/p>\n

    The ECB’s reference-rates page separately states that using these rates for
    \ntransaction purposes is strongly discouraged:
    \nhttps:\/\/www.ecb.europa.eu\/stats\/policy_and_exchange_rates\/euro_reference_exchange_rates\/html\/index.en.html
    \nThat page, not the two links above, is the source of that caution. This
    \nplugin uses the feed to convert prices for display and checkout, which is
    \nthe kind of transactional use that notice is about; if that matters for your
    \nshop, review that page before relying on this fallback.<\/p>\n

    Redirecting a source<\/strong><\/p>\n

    If your network blocks the ECB feed, the mhmcs_fallback_rates_url<\/code> filter
    \nreceives the URL, the base currency code and which source is being filtered
    \n— always 'ecb'<\/code>, since ECB is now the only fallback — so the request can
    \nbe pointed elsewhere.<\/p>\n

    Visitor geolocation (through WooCommerce)<\/strong><\/p>\n

    When “Enable geolocation-based currency detection” is on, the plugin asks
    \nWooCommerce which country a visitor is in, through WooCommerce’s own
    \n WC_Geolocation API. Since 2.2.0 that call explicitly switches WooCommerce’s
    \nremote-API fallback OFF, so this plugin makes no third-party request for it:<\/p>\n

      \n
    • Behind CloudFlare — the country is read from the CF-IPCountry<\/code> request
      \nheader. Nothing leaves your server.<\/li>\n
    • Otherwise — WooCommerce’s LOCAL MaxMind database file, if one is installed.
      \nAgain nothing leaves your server.<\/li>\n
    • With neither — detection simply finds nothing, and the visitor keeps the
      \nstore’s base currency until they choose one. No third-party lookup is made.<\/li>\n<\/ul>\n

      Earlier versions called WC_Geolocation::geolocate_ip()<\/code> with its bare defaults,
      \nwhich let WooCommerce fall back to a remote geolocation service and send the
      \nvisitor’s IP address there. That fallback is now disabled, matching what
      \nWooCommerce core itself does on the storefront.<\/p>\n

      The setting is off by default.<\/strong> Resolving a country from an IP address is
      \ndata processing a shop owner should switch on deliberately, so a fresh install
      \nleaves it off and shops that already configured it keep their own choice.<\/p>\n

      To make detection work without CloudFlare, add a free MaxMind GeoLite2 license
      \nkey under WooCommerce > Settings > Integration > MaxMind Geolocation;
      \nWooCommerce then downloads a local database file and answers from it.<\/p>\n

      WooCommerce geolocation documentation:
      \nhttps:\/\/woocommerce.com\/document\/maxmind-geolocation-integration\/<\/p>\n

      Source code<\/h3>\n

      The settings screen is a React application, and what ships inside the plugin is
      \nthe compiled bundle at admin-app\/build\/index.js<\/code>. The readable source it is
      \nbuilt from is not in the package, so here is where to find it and how to
      \nreproduce the build.<\/p>\n

      Full source, including the unminified JavaScript:
      \nhttps:\/\/github.com\/MaxHandMade\/mhm-currency-switcher<\/p>\n

      The source of the bundle is admin-app\/src\/<\/code>. It is compiled with WordPress’s
      \nown build tooling, @wordpress\/scripts, and nothing else:<\/p>\n

      npm install\nnpm run build\n<\/code><\/pre>\n
      That writes admin-app\/build\/index.js<\/code> together with the index.asset.php<\/code>
      \ndependency map the plugin reads when enqueuing the script. No other build step,
      \nminifier or bundler is involved, and no code is generated at install time or at
      \nruntime.<\/p>\n
      Editorial note: This overview combines WordPress.org official plugin metadata with an AI-assisted LethaldiranMX editorial review. Plugin data should be verified on the official WordPress.org listing before installation.<\/div>","protected":false},"excerpt":{"rendered":"
      Multi-currency support for WooCommerce. Let your customers browse, shop, and checkout in their preferred currency with real-time exchange rates.<\/p>","protected":false},"author":1,"featured_media":11869,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[252],"tags":[973,2219,2220,2221,569,555],"class_list":["post-11868","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-trends","tag-currency","tag-currency-switcher","tag-exchange-rate","tag-multi-currency","tag-woocommerce","tag-wordpress-plugin"],"_links":{"self":[{"href":"https:\/\/aeosub.com\/zh\/wp-json\/wp\/v2\/posts\/11868","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/aeosub.com\/zh\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/aeosub.com\/zh\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/aeosub.com\/zh\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/aeosub.com\/zh\/wp-json\/wp\/v2\/comments?post=11868"}],"version-history":[{"count":0,"href":"https:\/\/aeosub.com\/zh\/wp-json\/wp\/v2\/posts\/11868\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/aeosub.com\/zh\/wp-json\/wp\/v2\/media\/11869"}],"wp:attachment":[{"href":"https:\/\/aeosub.com\/zh\/wp-json\/wp\/v2\/media?parent=11868"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/aeosub.com\/zh\/wp-json\/wp\/v2\/categories?post=11868"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/aeosub.com\/zh\/wp-json\/wp\/v2\/tags?post=11868"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}