Cart cannot be loaded or an order has already been placed using this cart (it's back)

[Masteries]

Looks like the infamous bug is back and in action. I first noticed it after upgrading our shop to 1.6.1.16 and checked the Logs tab and there it was: 

Frontcontroller::init - Cart cannot be loaded or an order has already been placed using this cart

This happens whenever an order is placed using any payment module. However, everything is working fine, orders are getting placed and nothing is missing. Well except for one little thing, when an order is placed using the Check module, the PDF invoice has the "Payment method: Check" text missing and it's probably because of the whole cart_id getting duplicated or whatever it is.

 

To make sure this was not a disease transferred by my old shop, I made a fresh & clean install for PS 1.6.1.16 on a local environment and placed an order using check. Wholia, the same error appeared in the logs. At this point, it's nothing more than an annoyance (fills up the logs table in the database) so it's pretty much harmless (well, other than it has the payment method field missing in the PDF invoice as I said above). 

 

I thought that this whole ordeal was fixed since the creation of this topic: 

 

https://www.prestashop.com/forums/topic/466782-cart-cannot-be-loaded-or-an-order-has-already-been-placed-using-this-cart/

 

..but I guess I was wrong. Just thought I'd raise awareness so the devs can get to fixing this once and for all.

Edited August 23, 2017 by Masteries (see edit history)

[Scully]

The error is caused by a bad redirection after successfull order creation. It's a bug. We have fixed this but I don't have in my mind where it was. Maybe the class PaymentModule.php would be a first step to look in.

[Masteries]

The error is caused by a bad redirection after successfull order creation. It's a bug. We have fixed this but I don't have in my mind where it was. Maybe the class PaymentModule.php would be a first step to look in.

 

If it was fixed, why hasn't the devs implemented it? There have been so many updates up until now. Anyhow, I'm not that knowledgeable in PHP to be able to locate the bug and fix it on my own but thanks for the pointer. Whatever the case may be, I posted this to Forge so let's see how it goes.

[Scully]

To make it more clear: We have fixed it on our own. It wasn't fixed in the prestashop core as per my information. But since we have fixed so many little and bigger things, I haven't the piece of code available or right in my mind and our own fixed-bugs-and-whish-list is some 300 items long.

 

To help out: Open your browser with developer tools, usually hit F12 to do so. Choos network display. Place an order. At the final step you should note some 30x redirected URL which holds the order number as a parameter.

Edited August 23, 2017 by Scully (see edit history)

[Masteries]

To make it more clear: We have fixed it on our own. It wasn't fixed in the prestashop core as per my information. But since we have fixed so many little and bigger things, I haven't the piece of code available or right in my mind and our own fixed-bugs-and-whish-list is some 300 items long.

 

To help out: Open your browser with developer tools, usually hit F12 to do so. Choos network display. Place an order. At the final step you should note some 30x redirected URL which holds the order number as a parameter.

 

I see, but I didn't see redirects other than requests having the order confirmation URL as referrer (not sure, I'm guessing "initiator" means referrer (https://prnt.sc/gc5vpp). Or perhaps I'm wrong and this actually means each request is executing the order confirmation URL. In any case, I linked your answer in the Forge, looks like they managed to reproduce the issue & they're on it.

 

----

 

For anyone interested in updates, here's the Forge post:

 

http://forge.prestashop.com/browse/PSCSX-9270

Edited August 23, 2017 by Masteries (see edit history)