HIKASHOP ESSENTIAL 60€The basic version. With the main features for a little shop.
HIKAMARKETAdd-on Create a multivendor platform. Enable many vendors on your website.
HIKASERIALAdd-on Sale e-tickets, vouchers, gift certificates, serial numbers and more!
MARKETPLACEPlugins, modules and other kinds of integrations for HikaShop
-- HikaShop version -- : 5.1.6
-- Joomla version -- : 4
-- PHP version -- : 8.2
There is something seriously wrong with the orders.
There are duplicate orders and some do not even have an order number.
Credit card payments are not processed in these cases. There are no errors in the payment log for this period.
Only error I have
PHP Warning: Undefined array key "HTTP_USER_AGENT" in public_html/administrator/components/com_hikashop/classes/file.php on line 538
Please Log in or Create an account to join the conversation.
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
Please Log in or Create an account to join the conversation.
The database has not changed for years. Primary key is there.
Database check shows no errors and everything is ok.
The order number format has never been changed.
Please Log in or Create an account to join the conversation.
What did you configure in the "order number format" setting ?
Please Log in or Create an account to join the conversation.
Order number format
{id size="5"}{date format="y"}Please Log in or Create an account to join the conversation.
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.
Please Log in or Create an account to join the conversation.
For four customers to do the same thing one after the other is a bit unusual or almost impossible.
In the case of credit cards, this would be theoretically possible. In the case of COD (on delivery), however, it is not, since the customer cannot return to the checkout after the purchase is complete.
Only I have access to the database and in this case I would know about the deletion. Massaction is not set up to do this either.
Please Log in or Create an account to join the conversation.
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.
Please Log in or Create an account to join the conversation.
Enable multicarts was always turned off.
Login is not possible, only guest checkout is used.
Session lifetime is 100 min.
For order without a number, the history is empty.
Please Log in or Create an account to join the conversation.
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
Please Log in or Create an account to join the conversation.
Sent to contact.
After checking, I noticed that some tables in the database were blocked. Some process during the purchase causes the tables to be locked, thus preventing all further purchases.
I also noticed that the "stripe payment plugin" takes a lot of time (minutes) to change the status from created to confirmed. Could this be the cause?
GPT says:
HikaShop should create an order with the initial status created → and only after a successful Stripe webhook (e.g. payment_intent.succeeded) should it update to confirmed.
You are already doing this, but it is important:
that there are no active transactions or long-running UPDATEs left in onPaymentNotification() (or similar Stripe plugin method),
that after receiving the webhook, it only quickly updates the order status and does a commit().
If onPaymentNotification() calls slow operations (sending emails, API calls, logging…), execute them after commit().
Please Log in or Create an account to join the conversation.
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.
Please Log in or Create an account to join the conversation.
max_connections - 300
performance_schema - OFF
All tables was allready InnoDB.
Please Log in or Create an account to join the conversation.
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.
Please Log in or Create an account to join the conversation.
Again table locks and trouble with status change . Hosting support sent me this log.
1000379 localhost Execute 11592 Sending data UPDATE sjifs_acym_user AS user JOIN sjifs_hikashop_user AS hika_user1_0 ON user.email = hika_user1_ 0.000
1020684 localhost Execute 24 Updating UPDATE `sjifs_hikashop_order` SET `order_status`='ready',`order_modified`='1754048832' WHERE `order_ 0.000
1000379 localhost Execute 11592 Sending data UPDATE sjifs_acym_user AS user JOIN sjifs_hikashop_user AS hika_user1_0 ON user.email = hika_user1_ 0.000
1020684 localhost Execute 24 Updating UPDATE `sjifs_hikashop_order` SET `order_status`='ready',`order_modified`='1754048832' WHERE `order_ 0.000
1000379 localhost Execute 11592 Sending data UPDATE sjifs_acym_user AS user JOIN sjifs_hikashop_user AS hika_user1_0 ON user.email = hika_user1_ 0.000
1020684 localhost Execute 24 Updating UPDATE `sjifs_hikashop_order` SET `order_status`='ready',`order_modified`='1754048832' WHERE `order_ 0.000
1000379 localhost Execute 11592 Sending data UPDATE sjifs_acym_user AS user JOIN sjifs_hikashop_user AS hika_user1_0 ON user.email = hika_user1_ 0.000
1020684 localhost Execute 24 Updating UPDATE `sjifs_hikashop_order` SET `order_status`='ready',`order_modified`='1754048832' WHERE `order_ 0.000
1000379 localhost Execute 11592 Sending data UPDATE sjifs_acym_user AS user JOIN sjifs_hikashop_user AS hika_user1_0 ON user.email = hika_user1_ 0.000
1020684 localhost Execute 24 Updating UPDATE `sjifs_hikashop_order` SET `order_status`='ready',`order_modified`='1754048832' WHERE `order_ 0.000
1000379 localhost Execute 11592 Sending data UPDATE sjifs_acym_user AS user JOIN sjifs_hikashop_user AS hika_user1_0 ON user.email = hika_user1_ 0.000
1020684 localhost Execute 25 Updating UPDATE `sjifs_hikashop_order` SET `order_status`='ready',`order_modified`='1754048832' WHERE `order_ 0.000
1000379 localhost Execute 11592 Sending data UPDATE sjifs_acym_user AS user JOIN sjifs_hikashop_user AS hika_user1_0 ON user.email = hika_user1_ 0.000
1020684 localhost Execute 25 Updating UPDATE `sjifs_hikashop_order` SET `order_status`='ready',`order_modified`='1754048832' WHERE `order_ 0.000
1000379 localhost Execute 11592 Sending data UPDATE sjifs_acym_user AS user JOIN sjifs_hikashop_user AS hika_user1_0 ON user.email = hika_user1_ 0.000
1020684 localhost Execute 25 Updating UPDATE `sjifs_hikashop_order` SET `order_status`='ready',`order_modified`='1754048832' WHERE `order_ 0.000
1000379 localhost Execute 11593 Sending data UPDATE sjifs_acym_user AS user JOIN sjifs_hikashop_user AS hika_user1_0 ON user.email = hika_user1_ 0.000
1020684 localhost Execute 25 Updating UPDATE `sjifs_hikashop_order` SET `order_status`='ready',`order_modified`='1754048832' WHERE `order_ 0.000
1000379 localhost Execute 11593 Sending data UPDATE sjifs_acym_user AS user JOIN sjifs_hikashop_user AS hika_user1_0 ON user.email = hika_user1_ 0.000
1020684 localhost Execute 25 Updating UPDATE `sjifs_hikashop_order` SET `order_status`='ready',`order_modified`='1754048832' WHERE `order_ 0.000
1000379 localhost Execute 11593 Sending data UPDATE sjifs_acym_user AS user JOIN sjifs_hikashop_user AS hika_user1_0 ON user.email = hika_user1_ 0.000
1020684 localhost Execute 25 Updating UPDATE `sjifs_hikashop_order` SET `order_status`='ready',`order_modified`='1754048832' WHERE `order_ 0.000
1000379 localhost Execute 11593 Sending data UPDATE sjifs_acym_user AS user JOIN sjifs_hikashop_user AS hika_user1_0 ON user.email = hika_user1_ 0.000
1020684 localhost Execute 25 Updating UPDATE `sjifs_hikashop_order` SET `order_status`='ready',`order_modified`='1754048832' WHERE `order_ 0.000
1000379 localhost Execute 11593 Sending data UPDATE sjifs_acym_user AS user JOIN sjifs_hikashop_user AS hika_user1_0 ON user.email = hika_user1_ 0.000
1020684 localhost Execute 25 Updating UPDATE `sjifs_hikashop_order` SET `order_status`='ready',`order_modified`='1754048832' WHERE `order_ 0.000
1000379 localhost Execute 11593 Sending data UPDATE sjifs_acym_user AS user JOIN sjifs_hikashop_user AS hika_user1_0 ON user.email = hika_user1_ 0.000
1020684 localhost Execute 25 Updating UPDATE `sjifs_hikashop_order` SET `order_status`='ready',`order_modified`='1754048832' WHERE `order_ 0.000
1000379 localhost Execute 11593 Sending data UPDATE sjifs_acym_user AS user JOIN sjifs_hikashop_user AS hika_user1_0 ON user.email = hika_user1_ 0.000
On that day I have also some php warnings, but I gues not related:
PHP Warning: Attempt to read property "shipping" on null in /public_html/administrator/components/com_awocoupon/helper/estore/hikashop/class-awocoupon-helper-estore-hikashop-discount.php on line 780
PHP Warning: Undefined array key 0 in /public_html/administrator/components/com_acym/Controllers/Segments/Edition.php on line 222
PHP Warning: foreach() argument must be of type array|object, bool given in public_html/administrator/components/com_hikashop/views/order/tmpl/listing.php on line 325
Any idea?
Please Log in or Create an account to join the conversation.
Hi,
That's interesting.
It's not clear yet what is causing the problem, but I think it's a good starting point to understand what it is.
So, the log sent by your hosting support is a list of MySQL queries.
There is a first query updating the status of one or several orders to "ready".
Then, there is an AcyMailing query synchronizing the users between HikaShop and AcyMailing.
And, it seems that this process is repeating itself.
Also, if you look at the first query, the "order_modified" value is the same with all the repeating order status update queries.
This indicates that the PHP code launching all these order status update queries run all of them in the same second, and thus there's probably some kind of loop.
For example: if you created a published mass action with a trigger "after/before an order is updated" which itself updates the order.
I checked the mass actions on your website and didn't find that though.
But, it could also come from a plugin of one of the groups 'hikashop', 'hikashopshipping', 'hikashoppayment' or 'system' implementing the onBeforeOrderUpdate or onAfterOrderUpdate events of HikaShop, and updating the order status to 'ready' in that event.
So, do you have any recollection of setting something on your website with that "ready" status ?
This is a custom order status (not by default in HikaShop) that was added on your end via the "new" button of the System>Order statuses menu of HikaShop. What are you using it for ?
Also, it is not normal for AcyMailing to synchronize all the users between itself and HikaShop each time HikaShop updates an order status. The alias "hika_user1_0" in the MySQL query indicates that this MySQL comes from something in AcyMailing. I would recommend reporting this to the AcyMailing support so that they can look into it.
Please Log in or Create an account to join the conversation.
Order status ready is used for orders that are waiting for the customer to pick up. These are orders that are paid for via credit card or upon pickup. The status is changed manually by the admin.
I sent a request to their support for acymailing.
Please Log in or Create an account to join the conversation.
Then, it is strange that the order status is being updated like this.
Either, the manual changing of the status to "ready" is triggering the issue for some reason, or there's something else at play.
Did you notice the issue after changing an order to ready ? Do you do that often ?
Or maybe it doesn't happen each time ?
How are you using AcyMailing ? Only to send newsletters once in a while ? Or on a more day to day basis with automatic emails sent every day ? If it's only once in a while, you could try disabling the plugins / add ons between HikaShop and AcyMailing via the Joomla plugins manager and see if that helps the problem not happen anymore. If so, that would indicate that the problem is indeed with the integration between AcyMailing and HikaShop.
Please Log in or Create an account to join the conversation.
The status ready is used maybe a few times a week. The database hangs maybe once a month.
I think the problem with the status is more a result of some other error.
We use Acy on a daily basis. Up to 30,000 emails are sent per day via automation. Most of them are related to customers in one way or another.
Turning off the connection to Acy would represent a huge drop in sales.
Please Log in or Create an account to join the conversation.
Mmm. Then we don't have more clues to move forward.
What I can recommend is to add the code:
if(!empty($order->order_status) && $order->order_status=='ready')
hikashop_writeToLog(debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS));$order->order_id = parent::save($order);Please Log in or Create an account to join the conversation.
