Magento's default behavior seems to be to update a shipping quote for every single modification to a shopping cart. I find this very undesirable because it can cause the shopping experience to become unnecessarily slow while Magento waits from quotes from all carriers.

Magento also seems to be very loose on what it calls a "Quote", with there being Sales Quotes and Checkout Quotes. So, even though I have very little experience working with Magento Events, I am having a hard time figuring out where to even start.

How do I stop Magento from getting a shipping quote for every item added or removed from the cart? Just a point in the right direction would be a big help.

  • There is only one quote: sales_quote the complete logic of the checkout is based on the sales_quote. The cart doesn't exist, it is only a wrapper for the quote. What shipping quotes you are talking about? IF magento does this (what I don't know), it only looks things in the database up, this should be fast. Aug 20 '13 at 12:19
  • I'm talking about when it retrieves UPS shipping cost
    – andyjv
    Aug 20 '13 at 12:50
  • UPS is a extension? Then it is somewhere there in. Aug 20 '13 at 14:47
  • I think this does happen when the client already visited the checkout and provided an address and shipping method. The shipping costs are then displayed in the cart but I'm not sure if it's updated. 'Preventing' something like this would require quite some core editing I imagine, might not be the best way to go. Optimising your database, or perhaps upgrading your hosting might be a better solution. (But that's my honest opinion)
    – Sander Mangel
    Aug 20 '13 at 21:37
  • You're right, it happens after the customer has already provided an address. The problem is that if UPS takes a long time to return a quote, it will cause Magento to hang.
    – andyjv
    Aug 21 '13 at 1:16

I had a similar issue, where shipping lookups were done via australia post (using the fontis australia module located here:


If you dig a bit further, you'd most likely find that the lookup also happens via checkout, which is unnecessary, as the quote has not changed.

I implemented a fix (which was merged into the fontis module) a while back, which does a simple cache of the lookup in the session, and re-uses that on subsequent requests.

from: https://github.com/fontis/fontis_australia/blob/master/app/code/community/Fontis/Australia/Model/Shipping/Carrier/Australiapost.php

                 * Lucas van Staden @ doghouse media 
                 * Add a drc call cache to session. (valid for 1 hour)
                 * The call to drc is made at least 3-4 times, using the same data (ugh)
                 *  - Add to cart (sometimes * 2)
                 *  - Checkout * 2
                 * Create a lookup cache based on FromPostcode->ToPostcode combination, and re-use cached data
                 * The end result will kill lookups in checkout process, as it was actually done at cart, which will speed checkout up.

            $drcCache = Mage::getSingleton('checkout/session')->getDrcCache();
            if(!$drcCache) {
                $drcCache = array();
            } else {
                // wrap it in a try block, s it is used durng checkout.
                // prevents any mistake from stopping checkout as a new lookup will be done.
                try {
                    $time = time();
                            && array_key_exists($fromPostCode, $drcCache) 
                            && array_key_exists($toPostCode, $drcCache[$fromPostCode])
                            && $time - $drcCache[$fromPostCode][$toPostCode]['timestamp'] < 3600) {
                        if ($this->getConfigFlag('debug')) {
                            Mage::log('Using cached drc lookup for ' . $fromPostCode . '/' . $toPostCode, null, 'fontis_australia.log');
                        return $drcCache[$fromPostCode][$toPostCode]['result'];
                } catch (Exception $e) {

You would most likely need to implement something similar (at the cart level) in the provider module you are using. The fix above was to solve the lookups causing checkout to take very long, when the provider was busy.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.