The issue has currently reappeared in the CZ language version; it is not possible to select the color yellow. Two days ago, it was the color chocolate. Could you please check this? We have not made any changes to the product. hidden link
Since there has been no activity for a while, I’ve converted this conversation into a ticket to avoid the chat being closed and so we can continue here without interruption.
I have some few follow-up questions:
- Could you please let me know what the han-admin.php must-use plugin is used for?
- Do you have any server-side caching enabled on your live website?
- Also, what is the purpose of the Lubive Addons by Hanuliak plugin?
- Does the issue happens after maybe client making an order or similar?
thanks for the follow-up. Please see the answers below:
han-admin.php (MU plugin)
This is our internal must-use plugin used only to visually indicate whether we are currently working on production or staging. It does not affect frontend functionality, orders, WPML, or WooCommerce logic in any way.
Server-side caching
We are using hosting from Hetzner. We did not explicitly enable or configure any server-side caching on our side.
The only related information we found is this documentation from Hetzner regarding cache lifetime: hidden link
Other than that, no custom server cache rules were set by us.
Lubive Addons by Hanuliak plugin
This is a custom plugin responsible for product filters, custom gallery, and variant switchers.
We investigated whether the issue could originate there, but did not find any internal problem. The behavior we observed is that WPML does not return the expected value for the given language, which causes the value not to be displayed.
We tested the same scenario using the default WooCommerce variation switcher, and the behavior was identical.
Relation to orders / stock changes
We did not observe whether the issue changes after an order is placed or when the product stock is reduced. At this point, we cannot confirm a direct connection to stock changes.
Let me know if you need anything more specific from our side.
Thanks for getting back to me and for sharing the additional information.
The behavior we observed is that WPML does not return the expected value for the given language, which causes the value not to be displayed.
This happens after probably stock / attribute sync was not correctly applied from default language to 2nd language. We need to find out what action that is done to default language / translated language is causing this to happens. Since you said it does not happen on staging site then it needs to be connected somehow to your live website and action that are done there.
At this point, we need to identify which action on the live site is causing this state to occur.
What I would suggest next is the following. First, please ask your hosting provider to enable SQL query logging on the server. Second, install and enable the WP Activity Log plugin from https://wordpress.org/plugins/wp-security-audit-log/.
When the issue happens again, please check the server and SQL logs with your hosting provider to see when the change occurred to stock or attribute values. In parallel, review the activity log to identify what actions were performed shortly before the issue appeared. In particular, look for actions affecting variations, attributes, or stock status on either the default language product or its translation. This is also why an order being placed could be a possible trigger.
By correlating the timing in the SQL logs and the activity log, we should be able to identify which action caused the incorrect state. Once we have that information, we can try to reproduce the same steps and investigate why it happens and how to prevent it.
I’m afraid this is the best approach I can suggest for now, as there are currently no clear or consistent steps to reproduce the issue, and it does not occur on the staging site. Monitoring and log analysis should help us narrow this down further.
I hope this makes sense and helps explain our position. Let me know if you have any questions.
We have installed the WP plugin for logging that you recommended.
We tried to enable database logging on our side, but it was unusable after 15 seconds, with a log size of 25MB.
We will try to contact the hosting provider to see if they can enable logging on their side.
Unfortunately, our hosting provider is unable/unwilling to run database logs. Is there another solution to detect this problem on our end?
They asked us where exactly the problem lies, but I'm afraid that even if we take the trouble to describe the problem to them, they won't be able to help us.
Thank you very much for your response on how to proceed.
Roman
