1) I have checked, and I have first noticed you do not have our required add-on plugin for WooCommerce, which is called "WPML Multilingual & Multicurrency for WooCommerce". Please make a backup and install it.
Also I see you do not have products translated or its taxonomy, so WPML should not have that much affect.
2) I am having troubles checking when all plugins active / server crashes, so I am checking with only WPML plugins, and WooCommerce. Could be there is some issue with other plugins you are using, but you said issue happens also with only WPML plugins and Wocommerce, so I have continued to check like that, in minimal.
I can see some small impact when using WPML, but not that much that it causes performance issue. Maybe I am checking it wrong.
Please confirm my steps to check are okay or advise different, and I will re-check again and then compare to without WPML and escalate to our 2nd tier if I see any large impact.
Thank you for your update and the video. Allow me to clarify a few critical points:
Installed plugins
Please note that all plugins currently active on our production site are absolutely necessary for the proper operation of our e-shop. Disabling them permanently is not an option, as each one provides critical functionality for daily business operations.
Therefore, any performance testing must take into account this reality — the site cannot run in a “minimal” setup.
Testing environment vs. live reality
The tests you are performing in your local environment are not representative of the real-world workload. In production, where all required plugins and WPML are active, backend operations such as adding or updating products trigger slow queries lasting 10–15 seconds.
This situation is effectively non-functional for our team. The delays are too severe for product management to be feasible.
Logs already provided
You already have the full MySQL report (.rar) with slow query samples and EXPLAIN outputs collected by our sysadmins directly from the live server.
I kindly insist that you carefully review those logs, as they clearly show queries involving WPML (icl_translations) and WooCommerce joins that are responsible for the delays.
Next step
At this stage, we kindly need:
A technical review of the slow queries in the logs we provided.
Concrete recommendations (indexes, query adjustments, or confirmation if this is a known WPML limitation).
General advice such as “disable plugins” or “switch themes” is not actionable for us, since the site cannot operate in such a stripped-down mode.
This is a business-critical e-commerce site. The backend must be fast and reliable, and we depend on WPML support to help us achieve that. Please confirm that you will escalate this case with the logs we provided so we can move forward with a concrete solution.
I fully understand your situation, and we’re glad to help. As mentioned earlier, there are several steps we need to go through in order to confirm where the issue is coming from — whether it’s related to WPML itself, another compatible/incompatible plugin, or even custom code.
That’s why I first suggested some specific tests, which you confirmed you tried. However, from your latest reply, it seems the issue occurs while all other plugins are still enabled.
Just to clarify: I’m not advising you to keep your site running with plugins disabled. This step is only for debugging purposes, so we can isolate the source of the problem. I advise you try them on your staging site.
Simply checking SQL logs isn’t sufficient here, as I explained in my previous replies. It can be affected and caused by many things, some of which can be not compatible plugins that can cause issue with WPML.
So, could you please confirm if you tested the issue with only WPML plugins and WooCommerce active, while all other plugins disabled? This is a crucial step for us to know how to proceed with debugging and to reach a solution faster. Also please confirm you have installed required plugin.
With all due respect, I need to be absolutely clear at this stage.
It is not realistic to suggest that the performance issue can only be debugged with all other plugins disabled. This is a real e-commerce site, not a demo. Every plugin currently active (shipping, payments, caching, SEO, etc.) is essential for the daily operation of the shop. There is no such thing as a functional WooCommerce shop running “only WPML and WooCommerce.”
Yes — if I disable everything and leave only WPML, then of course the site looks “fine.” But that is not the real production environment. The backend slowdown happens in the real environment, where the shop must function with all required plugins active. Any suggestion otherwise is meaningless.
More importantly:
I have already provided you with server-level MySQL slow query logs and EXPLAIN outputs from our sysadmins.
These logs conclusively show WPML (icl_translations) joins as part of the 10–15 second queries.
These are not assumptions or guesses. They are measured facts from production.
Therefore, continuing to insist on repeating “disable plugins and retest” is just scripted support and does not address the actual issue.
We know exactly where the problem lies — WPML query structure in combination with WooCommerce data. What we need now is senior WPML engineering review, not more basic troubleshooting steps.
Please escalate this case immediately to your 2nd tier or senior engineers. They need to:
Review the provided slow query logs and EXPLAIN data.
Confirm if this is a known WPML performance limitation.
Provide specific technical recommendations (indexes, query changes, or patch/timeline for fix).
This is a business-critical shop. The backend is currently unusable for product management. We cannot lose more time going in circles with generic suggestions.
Just to clarify, I didn’t ask you to use your website in that condition. As I mentioned before, this was simply one step in the debugging process to help us better understand why the issue is happening and try pinpoint cause of it.
I would then check which plugin might be causing the problem with WPML and confirm whether it’s related to WPML or compatibility issue. From there, we could plan the next steps more effectively.
1) I’ll share the SQL logs with our 2nd-tier team. Please note that while the logs show the queries being made (and they are standard WPML queries), they don’t necessarily explain why performance is slow. That’s why I was trying to investigate together with your help.
I’m escalating this now and will keep you updated as soon as I have any news. It may take some time.
2) You need to use shared mentioned add-on plugin for WooCommerce as it is required for WPML to work correctly.
Thank you for escalating this case to the 2nd-tier team. Please confirm once they have reviewed the SQL logs and provide us with their feedback.
In the meantime, I will install the “WPML Multilingual & Multicurrency for WooCommerce” add-on to ensure that the environment is fully aligned with WPML’s requirements.
I appreciate your support so far and I look forward to receiving the 2nd-tier analysis with specific recommendations to address the backend performance issues.
Our 2nd tier checked your logs, but can not tell much from solely them as they can be called from different things.
They suggested next:
Make a backup and if possible test on staging site.
1) Install Query monitor plugin, and check for slow query that are reported. It should provide more info about each query and what function calls them, or if any specific page that it happens. You can also use LOOM to record video to provide us this report so we can clearly see what are slow query, what calls them and where.
2) Remove wpml_notices key from options table
3) Disable Rank Math for a moment and check if that helps.
Thank you for the feedback from your 2nd-tier team. I will address your points and also share new data:
In the shared Google Drive folder (where you already have access), I have just uploaded a fresh file:
slow-queries-last-3-days.txt
This contains the slow query logs collected directly from MySQL over the last three days. These logs provide a very detailed and precise view of which queries are slow and how they behave under real production load.
Before even opening this ticket with WPML support, we had already confirmed that disabling Rank Math does not solve the issue. The performance problem remains exactly the same.
I will prepare a staging environment as requested, but I honestly do not understand why Query Monitor is needed when I am already providing more detailed raw MySQL slow query logs from the server itself. Query Monitor may help correlate queries with WordPress functions, but the logs I sent are far more complete and accurate, especially the latest one that covers 3 full days of backend activity.
I will also remove the wpml_notices key from the options table as suggested, although this does not appear to be related to the 10–15 second queries that were captured.
To summarize:
You now have both comprehensive server-level logs and confirmation that the issue persists even without Rank Math.
The slow queries clearly involve WPML joins (icl_translations and related tables).
I will still cooperate with your request to provide staging tests, but I kindly ask that your senior engineers carefully review the new log file I just uploaded, since it contains the most reliable data so far.
Thank you — I’ll share these detailed logs with our 2nd tier team and get back to you.
As mentioned, these are regular WPML queries. What we need to determine is why they are slow — for example, which function is triggering them, whether they occur on specific pages, or other related factors. Just looking at the SQL query itself doesn’t give us enough information.
Once the staging site is ready, please let us know. That will make it much easier for us to investigate and identify the issue directly, which will be far more efficient than trying to guess based only on SQL logs.
Thank you for your reply and for sharing the logs with your 2nd-tier team.
I understand your point that the SQL queries themselves are standard WPML queries, and the need is to identify what triggers them and under which conditions they become slow.
To assist with that, we are in the process of preparing a full working staging environment that mirrors the live site as closely as possible. Once it is ready, I will share the access details with you so that you can perform a more detailed investigation directly in a controlled environment.
In the meantime, thank you for your continued support and for keeping this case open until we can provide the staging setup.
Drazen...
I have prepared a full staging environment that is an exact replica of the live site:
hidden link
Before sharing the login credentials and sensitive details, could you please enable the Private Reply option in this ticket? That way, I can securely provide the necessary access.
Once enabled, I’ll share everything required so you can proceed with the in-depth investigation.
