The Foxy forums are on the move!

We're in the process of moving our forums over to a new system, and so these forums are now read-only.
If you have a question about your store in the meantime, please don't hesitate to reach out to us via email.

getting several carts to work on the same page.

PhilippePhilippe Member
Hi,

I have 3 inventories in USA, Europe and Australia and therefore 3 carts that bill respectively in USD, AUD, and EUR - each with its own shipping rules, etc.

So far, I used to have 3 different web sites, but we are regrouping them into a single one (to concentrate traffic and get better SEO ratings, among other reasons). On the buy page for each product, I want to offer the client the option to buy from either inventory - using a buy button from each ("Buy product from US site " , "Buy prodcut from Euro site", etc.

I have tried having the 3 scripts (one for each cart) in the header, and having 3 different forms , one for each button, on the buy page. No joy!

Is there a way to allow this to happen ?

«1
Comments
  • Specifically it seems that only the first cart that I load works in side cart mode; the other ones work only in full page mode. This would happen if a client tried the buy fomr the US, looked at delivery charges, to say, Sri Lanka; then backed to the site and tried to "buy from Europe" to check delivery charges from Europe. That second cart to load does not load in side cart mode, but only in full page
  • fc_adamfc_adam FoxyCart Team
    @Philippe,

    Unfortunately we don't currently support having multiple stores within the same single page - the cookies will clash with each other, leaving you with the kind of experience you're describing. What you'd need to do instead is have the sites broken between different subdomains - for example usa.yourstore.com, eu.yourstore.com, au.yourstore.com, or between subfolders - yourstore.com/usa, yourstore.com/eu, yourstore.com/au.

    You can see some additional information about approaching the different subdomains and folders related to cookies and sessions here: https://wiki.foxycart.com/v/2.0/javascript#sessions_cookies
  • Ok.
    this brings up a conversation we had a least a couple years ago: I have 3 carts because I need to take 3 different currencies - How are you doing with developing multiple currency in a single cart?
  • fc_adamfc_adam FoxyCart Team
    @Philippe,

    We actually launched our multicurrency support late last year - I'm very sorry if we missed notifying you for that feature launch!

    If you're not already, we'd definitely recommend subscribing for updates via our site at http://www.foxycart.com/blog. You can see the announcement post for multicurrency here: http://www.foxycart.com/blog/multi-currency-support-is-here
  • Sounds like what I need. Just to confirm, my situation is:
    - I use stripe (supported)
    - I would have on the same page
    - a form / button that charges a price in USD, sends payment to stripe
    - a form / button that charges a price in AU$ (different, disconnected amount as we have different costs in Australia) ; sends that to stripe who converts on the fly at the then current rate and credit me with USD.

    Based on what currency/ locale the cart was set to I would use a different set of rules for shipping (we set our shipping rates via a java script (right now I am using something like
    if (address.country == "AU") {
    if (state_code == "NSW") {
    for determining shipping fron Australia by state, for example

    I imagine I would have to precede that with a test on locale like:

    if (locale == "AUlocale") .. and then follow with Aussie shipping code;

    then write
    if (locale == "USlocale") and then follow with the US shipping code, etc

    Which brings 3 questions:
    -1- What is the name of the locale variable I need to test on ? "locale" ?
    and
    -2- what is the syntax for the locale itself ? "2letterCountry code_2letterCurenncy code" ?
    -3- is there more sample code than the one in the blog annoucement - particularly using forms?


    Do I still need to apply for using this (per the blog announcement) or is it now open to everyone ?
  • I am restating the message above, as I figured out there is a Wiki, and I have better quetions after reading it....

    Sounds like what I need. Just to confirm, my situation is:
    - I use stripe (supported)
    - I would have on the same page
    - a form / button that charges a price in USD, sends payment to stripe
    - a form / button that charges a price in AU$ (different, disconnected amount as we have different costs in Australia) ; sends that to stripe who converts on the fly at the then current rate and credit me with USD.

    Sounds pretty straightforward . An additional complication: Based on what currency/ locale the cart was set to I would use a different set of rules for shipping (we set our shipping rates via a java script )
    I imagine I would have to have in the script a test on locale like:

    if (locale == "AUlocale") .. and then follow with Aussie shipping code;

    then write in the code

    if (locale == "USlocale") and then follow with the US shipping code, etc

    Which brings 2 questions:
    -1- What is the name of the locale variable I need to test on ? "locale" ?
    and
    -2- what is the syntax for the locale itself ? "2letterLanguagecode_2letterCountry_Code" ?
    (i assume the language code does apply to the admin interface, and not the customer facing cart ?)

    Do you have specifics for the gateway settings we need to adjust for Stripe ?

    Do I still need to apply for using this (per the blog announcement) or is it now open to everyone ?
    (Since this is abit complicated we will need to try first on our test store (i-sailsteststore sub domain) , for which we will create a test stripe account
  • fc_adamfc_adam FoxyCart Team
    @Philippe
    Sounds like what I need. Just to confirm, my situation is:
    You could certainly approach it that way - or alternatively you could set what currency the customer wants to pay in in the session and just display a single add to cart in that currency.
    Based on what currency/ locale the cart was set to I would use a different set of rules for shipping (we set our shipping rates via a java script )
    You may still want to base your shipping rules on the country rather than the locale. For example, someone could be based in the US but want to pay in AUD if they're from Australia and have a payment card from there. Ultimately the shipping country value is going to give you the definite answer on where the shipping will be for. The locale will probably mostly be right, but there is a chance it won't be.
    -1- What is the name of the locale variable I need to test on ? "locale" ?
    and
    You can see the current locale of the cart within FC.json.locale_info.int_curr_symbol. We don't currently store the raw locale variable in a publicly accessible variable, but that variable will have the international currency code for the currently selected locale (eg "USD", "AUD").
    -2- what is the syntax for the locale itself ? "2letterLanguagecode_2letterCountry_Code" ?
    That's right - so en_AU, de_DE. We'll work on getting a list of the possibilities added to our wiki for easier reference for that.
    (i assume the language code does apply to the admin interface, and not the customer facing cart ?)
    The locale currently just modifies the cart currency - it doesn't affect language strings at this time, but multi-lingual checkouts are coming soon.
    Do you have specifics for the gateway settings we need to adjust for Stripe ?
    We don't have any specifics there - but I believe you shouldn't need to make any changes. We pass the currency through to Stripe for the current cart, so they should handle it on their side as needed.
    Do I still need to apply for using this (per the blog announcement) or is it now open to everyone ?
    We do still need to manually enable it for your store(s). If you email us a list of the stores you want it enabled for, we can action that for you.
  • Adam,

    I have moved forward exploring multicurrency and set up forms with locales, currencies, etc - all good, populate the cart with correct pricing and currencies, - until we get to shipping and have hit a further hiccup - to save you re-reading everything,:

    - We have 3 local inventories (Australia, US, Europe)
    - We sell the same product, locally, in the local currency but at different prices, as we have different costs to bear. (for example the Euro price includes VAT and other extra costs of doing business there)
    - The goal is to have 3 (form) buttons on a page where a client can choose to buy from the US store, in USD , at the us price and bear whatever our US shipping costs are - Same for the Euro and AU buttons.


    Here is the difficulty I stumbled into:
    - In the US we use live shipping rates, so the US products, priced in USD, are in categories that are set for shipping at US live shipping rates from our US facility.

    -in AU, we use an obscure shipping company, so no live rates and instead the AU products are in categories set to flat rate, cost per product, zero O$, with a script in the custom footer that sets cusotm flat rates cost of shipping - (we installed that script in the admin panel--> templates --> configuration--> custom footer)

    This set up works great in our separate, live production stores. However in our test store, even though we pass the correct category and would hope would result in calculating prices accordingly , things get mixed up

    One question that comes to mind is , do I need to add to the script something that activates it only when the locale is AU if locale is AU then (script) either () ?

    and if yes, what is the correct syntax ? (I will make sure separately that my order forms set the AU locale for product / categories set for shipping suing the custom AU flat rate script )

    test page here:
    http://www.enus.i-sails.com/testsimple.html



  • fc_adamfc_adam FoxyCart Team
    @Philippe,

    Good question - and yep, you'd want to ensure the shipping snippet only outputs when products are present that it needs to work with.

    If you're setting that up as separate categories for the different currencies, then you could check for the presence of those categories, but you could also check the current cart currency too:

    Where you currently have:
    {% if context == 'cart' or context == 'checkout' %}
    You could make it:
    {% if (context == 'cart' or context == 'checkout') and locale_info.int_curr_symbol == "AUD " %}
  • Adam, Thanks.

    I tried the following, without success -

    - confirmed that product priced in AUD belongs to a category set for flat shipping rate
    - confirm that product priced in USD belongs to a category set for live shipping rates
    - set a compound script with 2 "if" statements, one for each case (AUD or USD currency)


    {% if (context == 'cart' or context == 'checkout') and locale_info.int_curr_symbol == "aud " %}
    flat shipping rate script from our production AU site here -
    {% endif %}

    {% if (context == 'cart' or context == 'checkout') and locale_info.int_curr_symbol == "usd " %}
    live shipping rate script from our production US site here -
    {% endif %}


    When I load a usd-payable product (belongs to a category set for live shipping rates) it works; however, when I load a AUd product (belongs to a category set for flat shipping rates) , the relevant script does not seem to run.


    test page still at

    http://www.enus.i-sails.com/testsimple.html
  • fc_adamfc_adam FoxyCart Team
    @Philippe,

    Ah sorry - I didn't realise your add to cart wasn't also setting the locale. You are setting the price to $190 AUD- but the store locale is still staying in USD, so the price is converting to the comparable USD amount, around $140 USD.

    Are you wanting to actually charge the Australian customers in AUD? If so, you'll need to also include a locale parameter in your add to carts:
    <input type="hidden" name="locale" value="en_AU" />
    That will force the cart to be in AUD, and so adding a $190 AUD product will be displayed as $190 in the cart. That will also remove any products in the cart that aren't in AUD - ensuring that the customer won't be able to order a mixture of USD and AUD products that need different delivery types.
  • Yes, we need to charge AU products in AUD, (at a potentially non-equivalent price to the US price, as we have different costs in Australia)

    However, adding the locale to the form:
    -1- Actually prevents the cart from clearing out the initial locale products when you add products from a different locale - I end up having products from different locales in the cart, all priced in whatever currency was used in the locale of the first product. (The desired behavior would be that if you load an Australian product in the cart, currency be AUD; then if change your mind and decide to buy that product from the Us locale, the Australian product be removed as you load the US product; and USD be the currency - it worked that way before I added the locale input)

    -2- does not fix the problem (ie the flat shipping rate script (that works in our single currency AU production cart) does not work in the multi-currency cart.
  • fc_adamfc_adam FoxyCart Team
    @Philippe,

    If the locale of a product that is added to the cart is different from the current locale of the cart, the cart is cleared before adding the new product into the cart. That should be the behaviour you see, and that's the behaviour I'm seeing on your test store. If I add a US product, and then add an AU product - the US product is cleared out and only the AU product is present.

    You do have a small error with the US locale - it should be en_US - underscore rather than a dash.

    Without the locales, products of different currencies will be added together, and the currency will be converted to the current locale of the cart.
    -2- does not fix the problem (ie the flat shipping rate script (that works in our single currency AU production cart) does not work in the multi-currency cart.
    I think that might relate to your checking for lowercase "aud" in your twig conditional. It should be and locale_info.int_curr_symbol == "AUD ". Maybe give that a try.
  • Great, all sorted out, expect for a small exception.

    We ship from Australia only to AU and NZ. The flat shipping rate script handles only these 2 countries; and in the single currency, Australian carts for now, we have used the country white list excluded other countries.

    In the new context, with this multi currency option, however, we can not use the country white list, as a customer might order , for example, a US product for delivery in the US.

    I tried adding the code below before the end of the asutralia specific, custom flat rate logic, but it does not seem to work - any idea about what is wrong there ?

    if (address.country !== "NZ" && address.country !== "AU") {

    FC.customFlatRates.remove('all');
    FC.customFlatRates.error('We normally do not ship from the Australia store ooutside AU and NZ. Please contact us for a custom shipping quote');

    }


  • fc_adamfc_adam FoxyCart Team
    @Philippe ,

    Looks like you've found a small issue with the flat rates snippet there, which happens when you trigger an error but there aren't any rates that were present. Obviously if you're returning an error there doesn't need to be rates.

    Could you try this code for the flat rates snippet and see if it corrects the issue you're seeing? http://pastie.org/private/h5j6eivfe0kz06okl3u0pw
  • Almost there, I I tried that, and it works for 1 cart load , then stopped working after emptying the cart and reloading. Specifically.....

    I set up my stuff as follows:


    {% if (context == 'cart' or context == 'checkout') and item_count > 0 %}
    {% if locale_info.int_curr_symbol == "AUD" %}
    our production Australia code goes here, with its custom shipping logic ending with:

    if (address.country !== "NZ" && address.country !== "AU") {
    FC.customFlatRates.remove('all');
    FC.customFlatRates.error('We normally do not ship from the Australia store ooutside AU and NZ. Please
    contact us for a custom shipping quote');

    and your new snippet /* Flat Rate Shipping Modification Logic v2.0.9 */ to follow

    {% endif %}

    {% if locale_info.int_curr_symbol == "USD" %}
    our production live shipping rate code here for the US
    {% endif %}

    {% endif %}


    It seems that something does not reset every time - specifically, I have had cases where I messed back and forth between US products (us locale, us currency) and AU products (aU locale, au currency) . The cart empties out every time I change locale, and the currency displayed by the cart is the correct one for the product as specified in the button via the 3 digits appended to the price - this is all good...

    However, with a US product loaded, and the cart set to USD, I can see a FC.customFlatRates.error message (shown above in my pseudo code) that should happen only when {% if locale_info.int_curr_symbol == "AUD" %} is true.
  • PhilippePhilippe Member
    edited May 2016
    Fresh off the press: in addition to the comment above, it seems that after reloading the cart with a new locale, it takes a manual page refresh to cause the footer script to run correctly

    - ie when the cart resets after changing locale, some variable does not get reset, or the configure / footer field in which the script is located does not re-run ---- untill I force a manual page refresh, and then all is good.....
  • PhilippePhilippe Member
    edited May 2016
    To reproduce:
    - go to test page http://www.enus.i-sails.com/testsimple.html
    - buy an AU sail. The new AU sail is in the cart and the currency switches to AUD (from our default of USD) . Flat shipping rates gets calculated correctly, or error message appears correctly if you pick a country other than AU or NZ
    - Go back to shopping cart and load a US product - AU sails gets cleared off of cart, US sail gets loaded, currency switches to US - all good - but no shipping gets calculated under the new locale as the script has not been re-run / reloaded taking into account the new locale of en_US.
    - Refresh the browser window - the script somewhat runs and the correct shipping methods are calculated
  • fc_adamfc_adam FoxyCart Team
    @Philippe,

    Thanks for including the steps! I'll take a look and get back to you as soon as I can.
  • fc_adamfc_adam FoxyCart Team
    @Philippe,

    Thanks for your patience. I can see what's happening here - when you load the AUD cart, it's initialising the flat rate snippet as it should. That snippet adds some functions into the FoxyCart events, replaces the default FoxyCart function to fetch live rates and also adds to some jQuery events so that it works as it needs to. When you close the cart and instead add a US based product, it's also correctly removing the flat rate snippet and instead showing the live rate snippet. Unfortunately though, that process won't clear out the respective events that the flat rate snippet has previously added. As our Sidecart functionality means the page doesn't need to be reloaded at all, that means that those events are persisting. That's also why you see it start working after you refresh the page, as it's clearing out those old events.

    Unfortunately I'm not sure of the best approach here that would get this working as you need. The two options are that the page needs to be refreshed, or you only allow shipping calculations on the checkout by hiding the shipping entry fields on the cart using CSS. While neither are a great solution, would either be acceptable?
  • Thanks for looking into this.

    A preliminary question - can you write a snippet that would reset those Jquery events and be added either to the main snippet; or to the custom logic ? that seems to be the cleanest way to proceed.. :-) ; and I could see other people being interested in the ability to switch from flat rate to live rates.

    Barring this, I like the ability to calculate shipping in the side cart, so I would like to look into the page refresh method. Unfortunately, it is not as simple as inserting location.reload(forceGet); in the script (I tried :-( )

    How would that be done ?
  • fc_adamfc_adam FoxyCart Team
    @Philippe,

    With how the snippets work, unfortunately not easily. They're designed to be run in isolation rather than the possibility of both existing on the same cart.

    For the refresh, you could trigger than on side cart close, like this:
    FC.client.on("sidecart-hide", function(params, next) {
    window.location.hash = '';
    document.location.reload();
    });
  • Thanks, I have installed the code you suggested at the beginning of each code snippet (flat rate and live rates), inside the scripts themselves.

    I get almost the desired behaviour.....

    -1- If I buy a us product or a AU product into an empty cart, the relevant code loads and the correct shipping methods are calculated.

    -2- If I have a US product in the cart, and buy a AU product, the cart is cleared of the US product and switches correctly from live rate to flat rate - all good (it did not do that before...)

    -3-If I have AU product in the cart and go back to the cart and buy a US product, the AU product is, correctly dumped, the US product appears, and we seem to stay stuck with some elements that come from the Australian flat shipping rates. Not good.
    However, if I keep shopping and add a second US product (without doing a manual refresh), then all gets sorted out (as if I had done a manual refresh, ) the correct shipping method loads, etc....ot


    Code looks like this, with the reload snippet you provided located after the tag in each custom shipping snippet



    {% if (context == 'cart' or context == 'checkout') and item_count > 0 %}

    {% if locale_info.int_curr_symbol == "AUD " %}

    FC.client.on("sidecart-hide", function(params, next) {
    window.location.hash = '';
    document.location.reload();
    });

    custom flat rate snippet with our custom logic.
    {% endif %}

    {% if locale_info.int_curr_symbol == "USD " %}

    FC.client.on("sidecart-hide", function(params, next) {
    window.location.hash = '';
    document.location.reload();
    });
    then live shipping rate snippet with our custom logic.
    {% endif %}

    {% endif %}
  • fc_adamfc_adam FoxyCart Team
    @Philippe,

    For the event code - that could just be included once on your own website. It probably shouldn't cause any issues being included in both snippets, not that come to mind anyway.

    Could you clarify what details are remaining when going from AUD to USD? I'm not seeing anything persist in my testing.
  • Here is an example:

    Get an AU product, and try to calculate a (flat shipping) rate for a destination to the USA. You get (correctly) an FC error message that comes from the AU flat shipping rate custom logic and states that we do not ship outside AU\NZ and you should request a custom quote. All is good

    Now, go back to shopping and buy the US product. The US address has persisted, but you still get the same message that comes from the AU flat shipping rate snippet. (You should get a live shipping rate for that Us destination).

    Now go back again to shop for that same US product, and get a second unit. Boom, this time the live shipping rate snippet has worked and delivers the right shipping method

  • fc_adamfc_adam FoxyCart Team
    @Philippe,

    Thanks for clarifying. I was able to replicate with your steps what you're describing.

    It appears that even with a refresh it's still not correctly clearing out the previous set up, as on cart load, it's initially still in AUD before it switches to USD. I hadn't factored that into my thinking.

    The other solution, instead of refreshing the page - is forcing the cart to be only full page and not make use of the Sidecart functionality. It means the customer is redirected away from your page to add the product to their cart instead of it sliding in on the page - but it would ensure that the cart loads with the new locale initially. To do that, you can simply change the cart type on the configuration page of your store's FoxyCart administration.
  • Adam,

    I am rather keen on using the sidecart, this is one your major points.

    I can not believe, that there is no way to either clear the persisting Jquery events causing the problem or to script refresh that has the same effect as a manual page refresh- a manual page refresh does the job, but I can not ask the clients to do that.

    Can you please look into this further / escalate ? Thanks
  • fc_adamfc_adam FoxyCart Team
    @Philippe,

    I had a lightbulb moment overnight - the following could be the final piece of the puzzle to get this working for you right now. Include this on your own website:
    <script>
    var FC = FC || {};
    FC.onLoad = function () {
    FC.client.event('cart-submit').override(function (params, next) {
    if (
    !FC.client.isActionNeeded(params)
    || FC.sidecart.shouldUseFullpageCart()
    || FC.sidecart.bypassSidecart(params)
    ) {
    next();
    return;
    }

    FC.client.request(params.url).done(function () {
    if (!FC.sidecart.is_loading) {
    FC.util.log('Starting sidecart load');
    FC.sidecart.is_loading = true;
    FC.sidecart.show(params);
    }
    FC.json.loading_quantity = false;
    FC.Template('cart').clearOutput();
    FC.cart.render();
    //browsers sometimes do not fire transitionend event
    FC.sidecart.$container.trigger('animationFinish');
    next();
    });
    });
    };
    </script>
    What that script does is overwrites the default add to cart action that displays Sidecart. Normally, we display Sidecart, and then trigger the add to cart to happen. This is why you're still seeing the wrong javascript apply initially - the sidecart is rendering based on the existing cart (which for example is in USD), and then the add to cart happens which changes it to a different currency (like AUD). This script instead forces the add to cart to happen first, and then the Sidecart is displayed and rendered - making it always be based on the most up to date version of the cart. Paired with the reload approach you added before, that should get the Sidecart cleanly displaying the right shipping logic and not including hooks from the other.

    Moving forward, we are working on some new native shipping functionality - part of the long discussed rebuilt shipping functionality - which will also make this a bit cleaner for you. We'll reach out when that goes live so you can make use of it and get rid of the delayed sidecart and reloading approaches here.
  • fc_adamfc_adam FoxyCart Team
    @Philippe, one thing I missed mentioning - is because there is a noticeable delay between clicking the add to cart and the cart displaying, you may want to show some sort of loading animation or UI to give the customer an indication that it's doing something. As an example as to where to place that:
    <script>
    var FC = FC || {};
    FC.onLoad = function () {
    FC.client.event('cart-submit').override(function (params, next) {
    if (
    !FC.client.isActionNeeded(params)
    || FC.sidecart.shouldUseFullpageCart()
    || FC.sidecart.bypassSidecart(params)
    ) {
    next();
    return;
    }

    // Begin loading animation here

    FC.client.request(params.url).done(function () {
    if (!FC.sidecart.is_loading) {
    FC.util.log('Starting sidecart load');
    FC.sidecart.is_loading = true;
    FC.sidecart.show(params);
    }
    FC.json.loading_quantity = false;
    FC.Template('cart').clearOutput();
    FC.cart.render();
    //browsers sometimes do not fire transitionend event
    FC.sidecart.$container.trigger('animationFinish');

    // End loading animation here

    next();
    });
    });
    };
    </script>
  • For any interested reader, manager, etc : Adam is the man.....

    This combined with the page refresh techniques. I am most grateful for the thinking you put in tho this.


    Keep me posted on the future developments you mentioned above, Cheers

    Philippe
Sign In or Register to comment.