I have magento 1.9 installed. After placing an order while logged in, the shopping cart is not being emptied. If I place an order as "guest" though, the cart is emptied.
Is this an option somewhere, or just default behaviour? I would expect the cart to get emptied wether logged in or not.
UPDATE
This happens with persistent shopping cart both enabled and disabled.
I had a very similar problem with a controller that made orders programatically. What it came down to is that the quote is still active when it reaches the point that it should be cleared. take a look at my question and the answer I marked as correct.
Programatically clear the cart of a logged-in user
By setting the quote inactive ( $quote->setIsActive(0)->save() ) I was able to get it to clear.
I'm not sure about the following. I describe what I observe. I didn't debug it, because it went away after raising the memory_limit to 256MB (and there are still a lot of open tickets here :-()
We had the problem, that a memory_limit fatal error occured, this errors was "catched" by
\Varien_Db_Adapter_Pdo_Mysql::__destruct
public function __destruct()
{
if ($this->_transactionLevel > 0) {
trigger_error('Some transactions have not been committed or rolled back', E_USER_ERROR);
}
}
and because the transactionLevel > 0 the error was triggered, this error can be catched(?)... whatever...
It ended here in one of the ifs I think:
public function successAction()
{
$session = $this->getOnepage()->getCheckout();
if (!$session->getLastSuccessQuoteId()) {
$this->_redirect('checkout/cart');
return;
}
$lastQuoteId = $session->getLastQuoteId();
$lastOrderId = $session->getLastOrderId();
$lastRecurringProfiles = $session->getLastRecurringProfileIds();
if (!$lastQuoteId || (!$lastOrderId && empty($lastRecurringProfiles))) {
$this->_redirect('checkout/cart');
return;
}
In the end the order was written, the mail was send, but the cart was not cleared.
Turn on debug mode, then you see hopefully the
trigger_error('Some transactions have not been committed or rolled back', E_USER_ERROR);
And as I said, in our case, this was triggered by a low memory_limit.
I finally got the time to debug this issue.
It traced the issue back to the MultiSafepay payment plugin, which is provided by the MultiSafepay payment provider. I contacted them and they helped me find the cause of the issue.
I am using the gateways checkout mode and this mode has an option under [Sales][MultiSafepay - Gateways][Settings][Cart remains active when the customer returns to the webshop or cancels an order], which does what it says. In my case this option is set to true, setting this option to false did not fix the problem.
Finally I discovered that another part of this plugin has a similar option under [Sales][Payment Methods][MultiSafepay][keep cart] which was set to true also. Even though this part of the plugin was disabled (by setting enabled option to false), this option still affected the behaviour.
So, after setting both the following options to no, the problem went away.
[Sales][MultiSafepay - Fast Checkout][Settings][Cart remains active when the customer returns to the webshop or cancels an order] = no
and [Sales][Payment Methods][MultiSafepay][keep cart] = no
After changing both these values and clearing the cache, I still had a problem with a few users. But after clearing all carts with DELETE FROM sales_flat_quote WHERE is_active = 1;, the problem was gone.
UPDATE
MultiSafepay technical support has let me know that they've been able to reproduce this bug and are working on a fix. The current version of the plugin (which has this bug) is 2.1.1 and this will be fixed in a feature release.