Wrong totals calculation on cart page

[ansgarbecker]

With @danslo's HHVM totals fix, I get a wrong totals calculation in the cart view in our Magento 1.9.2.4. More precisely said: The grand total has too times the VAT and/or the shipping cost.

When I remove the following code from config.cml, I get the correct grand totals calculation back in the cart view:

        <!-- Fix for incorrect sorting in the calculation of the discount -->
        <sales>
            <quote>
                <totals>
                    <msrp>
                        <before>grand_total</before>
                    </msrp>
                    <shipping>
                        <after>subtotal,freeshipping,tax_subtotal,msrp</after>
                    </shipping>
                </totals>
            </quote>
        </sales>

This faulty calculation might also occur due to our own number of third party extension we already installed. I haven't tested it on an otherwise blank Magento. But as the calculation has no problems without that code, I assume it's buggy.

The original author of the fix says on https://github.com/danslo/Rubic_FixTotalSorting :

This bug has been solved, and proper behavior can be enabled by passing -vEval.EnableZendSorting=1 to HHVM. This module is no longer necessary and only exists for historical purposes.

[peterjaap]

So, basic takeaway is; don't use Rubic_FixTotalSorting with PHP7.

[durzel]

I'm using this change with 1.9.2.4 without any issues with calculations?

HHVM is a different platform, if you're not running Magento under HHVM then the vEval.EnableZendSorting fix doesn't apply and you would need to use this fix as is. At least that's my understanding of it.

[danslo]

The issue isn't particularly with the module, it's the fact that PHP (as a language, not the respective implementations) don't impose strict sorting orders.

See for example uasort:

Note:
If two members compare as equal, their relative order in the sorted array is undefined.

Both PHP7 and HHVM will handle sorting differently, due to implementing faster sorting algo's. The module above only fixes the order on clean Magento installations; any 3rd party extension that adds a total collector may (or may not) screw up the ordering again.

In HHVM you can use EnableZendSorting to fall back to PHP5 style sort ordering (for the undefined behavior). I don't think there's such a thing in PHP7 though. This isn't a bad thing, because you shouldn't rely on undefined behavior anyway.

It would require a fix in Magento core to solve this problem for good.

[durzel]

Thanks @danslo 👍

[icurdinj]

So, the takeaway here would be: this XML fix is still good for PHP 7 and Magento Core, but, if there are 3rd party extensions adding stuff to calculation, test extensively.
Am I correct?

[ansgarbecker]

Yes, most probably. I did not test that XML snippet on a fresh Magento installation. But I guess @danslo did so, and I guess he didn't get the above mentioned calculation bug.

Probably it makes sense to add some warning in the documentation about possible side effects with 3rd party extensions, and that this may break the cart's totals calculation. That way the user probably spends less time in finding a fix.

[icurdinj]

Made a Wiki for extension, included relevant information there.

[seansan]

we are seeing 1 cent difference between order grandtotal and quote grandtotal (and not using HHVM). SO in this case one would have to add the above XML? (if this would be at all the fix ;) thx