Duplicated orders

Hi,

Indeed, it looks like there is something really wrong.
This indicates that either:
- you must have made some kind of migration of the database, and the primary key on the order_id of the hikashop_order table has been removed, allowing orders to be created without an order_id or with the same order_id as an existing one. The "check database" button of the HikaShop configuration page will detect the problem and try to fix it if possible.
- you've changed the "order number format" setting of the HikaShop configuration page in a way which makes it non unique and potentially empty in some cases:
www.hikashop.com/support/documentation/5...nfig.html#main_order

What did you configure in the "order number format" setting ?

Hi,

For the duplicated orders, I think it's normal. It's probably the user going back and forth between your checkout and the payment gateway for one reason or another.
That's because each time the user clicks on "finish" at the end of the checkout, the order corresponding to the cart is created.
And if the user goes back to the checkout from the payment gateway (after clicking on the cancel button of the payment gateway), the user will see the checkout again with his cart, he can potentially change things, and then click on "finish" again. So we need to create a new order as things might have changed in the meantime.

For the order without a number, I can only think that the order number has been erased, either via PHPMyAdmin, or via a mass action after it was created with the order number properly set.

Hi,

Even in the case of COD it can be possible, but not in the way I described.
Suppose that you have someone with several carts with the same content in their carts. It often happens when the merchant is configuring its own website:
- add a product to the cart
- then login
- the cart is linked to the user
- then logout (or the user session expires after some time)
- the cart is seen as empty
- add the same product to the cart
- then login
- the new cart is linked to the user too
- rinse and repeat to get many carts linked to the user.

Then, on the checkout:
- user clicks on finish with COD payment
- order is created
- cart is cleared
- next cart is used as current cart
- user thinks the cart is not cleared
- user clicks on finish with COD payment again
- order is created
- cart is cleared
- next cart is used as current cart
- etc

This won't happen if the "enable multi carts" setting is turned off in the HikaShop configuration:
www.hikashop.com/support/documentation/5...g.html#features_main
Also, increasing a bit the user session duration in the Joomla configuration is usually a good idea because by default it's quite low and thus the scenario above can happen even for normal users quite often.
So please check these.

Regarding the order number, there is no mechanism I know which can remove the order number of an order in HikaShop or any plugin we provide unless you purposefully configure something to do this. I also don't see a way for the order number to not be added to an order created through the normal checkout process or the interface in the backend of HikaShop. So, I don't know how this happen.
I would recommend checking the "history" of the order. You should see if the order has been modified via the interface at some point.
Also, you can use the action log plugin on the "order" data:
www.hikashop.com/marketplace/product/161-action-log.html
That way, next time it happens for an order, you can check the logs for that order. Maybe that will tell you something more about what is causing this.

Hi,

Mmm. I don't know what to say more without looking into things directly.
Could you provide a backend super admin access via our contact form ?
www.hikashop.com/support/contact-us.html

Hi,

Normally, the MySQL query changing the status of an order should be almost instantaneous. However, if the hikashop_order is locked, then MySQL needs to wait for the table to be unlocked before being able to run the query.
So I don't think that the problem is inherent to the Stripe plugin. I think it's more of a problem with the database setup not having enough max connections compared to your website traffic or something like that.
Here is a page talking about this:
fromdual.com/myisam-locking-and-who-is-the-evil
There are a few things that can be done, like increasing the max_connections of MySQL, or making sure the performance_schema is on.
Another thing you can do is to change the engine of your tables to InnoDB instead of MyISAM. Based on what is said on the URL above, it could be the best solution.
These can be done via your PHPMyAdmin.

Hi,

MySQL has some information about table locks in their own documentation:
dev.mysql.com/doc/refman/8.4/en/table-locking.html
As it says there, the root of the problem is not really the creation of orders.
It's another process which locks the hikashop_order table because it needs to have an intensive process on it.
For example, suppose you've configured a mass action to export the data of all the orders every minutes. This could lead to the table getting permanently locked. Same if it would be done with a custom PHP script or some kind of ERP integration. Or some kind of backup tool.
Normally, the log of the MySQL server should provide information about this.
I would recommend checking with your hosting support.
They should be able to tell you what is locking the table and creating the problem for the new orders saving process.