Previous Entries Part 1: Introduction Part 2: The Core Process The focus of this series is Magento's process for calculating and displaying cart totals. We have taken a thorough look at the code involved with the core process, but there are a few important points left to cover. Transferring totals to the order What we've seen so far all relates to what's happening when a cart is still in progress, and it makes sense that that's where the truly hard work is done. But at some point (we hope), a cart will become an order. What happens then? There are several relevant points: Frequently, the same database fields we've seen in the quote tables (ex. "gift_cards_amount" and "base_gift_cards_amount") will show up in the order tables as well. Where these fields are present in...

Previous entries Part 1: Introduction In this series, we're looking at Magento's process for calculating and displaying totals for a cart. In our introduction we briefly covered what a "total" or "total collector" is and saw how one is defined in config.xml. Now it's time to take a closer look at the models and data structure involved. The job of a total collector model can be divided into two processes: Calculation and display. You're highly encouraged to open up the Magento codebase and follow along in the referenced code. The collectTotals process As mentioned in the previous article, the calculation of cart totals is kicked off with a call to Mage_Sales_Model_Quote::collectTotals. Before taking a look at code, there are a few things to take note of about the underlying...

In this series, I'll be explaining the process by which Magento handles calculating and displaying totals in the cart (i.e., subtotal, tax, discount, grand total, etc), and how to customize this process for your own purposes. At its core, handling product prices and totals in an online shopping cart seems simple. Multiply the cart quantities by product prices. Add shipping. Add tax. And there you have it. The first time you have reason to modify the way cart totals are calculated and displayed in Magento, however, what you'll find is anything but simple. In fact, your first impulse may be to run far, far away. Why the complexity? Well, the first and most obvious reason is that even straightforward totals calculations aren't as simple as they appear. Is shipping a percentage or a...

We're excited that in a little over a week, a group of folks from Classy Llama, including myself, will be heading over to Santa Clara for ZendCon 2012. ZendCon is the PHP conference where the industry leaders get together to learn more about PHP and talk about what the future holds. Perhaps it is just my nerdy side (although, I'm not sure if there is any other side) but it is always invigorating to see how the PHP community has continued to evolve and improve! So, if you are going to be at ZendCon, come on by and visit our booth. We will be booth #320 -- between the Oracle and New Relic booths. Come by just to say "hi," learn more about Classy Llama, or talk about how Magento and Zend have revolutionized open-source eCommerce. We look forward to it!

For a long time, I've been a proponent of using single-quotes as opposed to double-quotes when assigning string literals (strings containing no variables) to a variable (eg: $var = 'string'; VS $var = "string"). I just did some research to find out how much (if any) impact using single-vs-double quotes had on performance. I took the code from this blog post: http://spindrop.us/2007/03/03/php-double-versus-single-quotes/ modified the MAX constant to 8,000,000 and then ran the test on our Nexcess server. The results were fairly consistent: Time 1: 5.9485120773315 ($c = "test " . $i; ) Time 2: 7.0326972007751 ($c = "test $i"; ) Time 3: 5.9164550304413 ($c = 'test ' . $i; ) It's clear that embedding variables in strings is less efficient, but the difference between normal single-vs-...