Skip Navigation

This is the technical support forum for WPML - the multilingual WordPress plugin.

Everyone can read, but only WPML clients can post here. WPML team is replying on the forum 6 days per week, 22 hours per day.

Sun Mon Tue Wed Thu Fri Sat
- 12:00 – 14:00 12:00 – 14:00 12:00 – 14:00 12:00 – 14:00 12:00 – 14:00 -
- 17:00 – 21:00 17:00 – 21:00 17:00 – 21:00 17:00 – 21:00 17:00 – 21:00 -

Supporter timezone: Europe/Vienna (GMT+02:00)

This topic contains 18 replies, has 0 voices.

Last updated by Bigul 1 hour, 11 minutes ago.

Assisted by: Bigul.

Author Posts
June 12, 2025 at 3:56 pm #17130811

Bigul
WPML Supporter since 01/2013

Languages: English (English )

Timezone: Europe/Vienna (GMT+02:00)

Hi Matteo,

Thank you for updating the plugin. We have confirmed that the issue persists even after upgrading to the latest version of the plugins and performing the primary troubleshooting and performance optimization steps. Therefore, escalated the ticket to our second-tier team for further detailed analysis. We will update you as soon as we have more information. Please wait.

--
Thanks!

Bigul

June 19, 2025 at 12:07 pm #17150532

Bigul
WPML Supporter since 01/2013

Languages: English (English )

Timezone: Europe/Vienna (GMT+02:00)

Hi Matteo,

We are still working on this. But unfortunately, the Query Monitor plugin is not working on your staging site. It shows the following error. The result is the same after upgrading to the latest version and deleting and reinstalling it: hidden link

PHP Fatal error:  Uncaught Error: Class "ComposerAutoloaderInit45e5f16aae4f58af47a13e01b04bd02e" not found in /**/wp-content/plugins/query-monitor/vendor/autoload.php:25

So let us know if you have any specific server restrictions or custom setups that might be affecting plugin behavior.

We have a few suggestions to improve your site performance

1) Normally, we recommend this article to improve the site performance: https://wpml.org/tutorials/2022/03/boosting-the-performance-of-your-multilingual-wordpress-site/

2) To reduce backend delays when saving or duplicating products, we recommend the following:

- Avoid duplicating products unless necessary. Instead, create a new translation directly.

- If you do duplicate a product, break the duplication link before making changes.

This helps prevent WPML from trying to sync data across all languages, which can be slow, especially for variable products with many variations.

3) Based on our experience, WP Rocket is not an object caching plugin and doesn’t offer the same level of flexibility as W3 Total Cache (W3TC). If possible, we recommend giving W3TC a try. However, using WP Rocket together with Autoptimize and Redis Object Cache can also deliver similar performance improvements when configured properly. Refer to the following articles for more details.

hidden link

hidden link

hidden link

4) Please visit WooCommerce >> Settings >> Advanced >> Features, and disable the following option. Then check if there is any difference in the results.

Enable compatibility mode (Synchronize orders between High-performance order storage and WordPress posts storage).

5) Also, please go to Products >> All Products, click on Screen Options (top right), and uncheck the *Language* column. This will help to reduce the backend loading time.

Please check the attached images for more details.

--
Thanks!

Bigul

2025-06-19_17h31_14.png
2025-06-19_16h52_13.png
2025-06-19_16h33_16.png
June 19, 2025 at 3:08 pm #17151350

FortunyShop

I solved the Query monitor bug, so you can still test the site.
As for the other points:

1) already visited that page years ago 🙂 tested many different caching and CDN systems, current Cloudflare + WProcket + Redis + Varnish setup looks good for cached content (which is not a problem at all, the problem is still the non-cached content).

2) so what do you suggest to do now with the hundred of products that I may have duplicated in the site during these years?

3) As already stated, the problem is not the cache. Cached content is super fast and there're no need to change that setup. The problem of slow and duplicate queries begins when content is not cached.

4) Done, but still think that the main problem is not this one. Please find a screenshot attached, you can still find many slow and duplicate queries to the database coming from WPML and its plugins.

Can I ask you, do other companies with big ecommerces with WPML have the same problem of slow queries and difficulty working (or browsing the frontend) when cache is not involved?
It's ok to strongly use cache, but we really need performance here too.
It's making us consider what to do in the long term, also considering about changing the whole platform.

Thank you and hope you can help us.

Screenshot 2025-06-19 165816.png
June 19, 2025 at 4:02 pm #17151670

Bigul
WPML Supporter since 01/2013

Languages: English (English )

Timezone: Europe/Vienna (GMT+02:00)

Hello,

Thank you for the feedback. I will check with our team on this.

One more question for better clarity — could you please share more insight on the following? In what situation does this issue typically occur? This will help us understand the context better (non-cached content) and assist you more effectively.

Varnish setup looks good for cached content (which is not a problem at all, the problem is still the non-cached content)

The problem is not the cache. Cached content is super fast, and there's no need to change that setup.

--
Thanks!

Bigul