Skip Navigation

This thread is resolved. Here is a description of the problem and solution.

Problem:
The client reported significant slow performance with the WPML plugin activated, particularly when the String Translation plugin is enabled. The issue persisted despite switching themes and disabling third-party plugins. Profiling indicated that the slowdown was related to the ACF Multilingual plugin, specifically with the handling of WYSIWYG fields in custom post types (CPTs).
Solution:
We identified a specific code snippet causing the issue in the ACF Multilingual plugin. We recommended modifying the code in the

ACFML\Field\FrontendHooks::convertTargetLinks

file. The client should locate the line:

if ( $isWysiwygField && is_string( $value ) ) {

and change it to:

if ( $isWysiwygField && is_string( $value ) && strpos($value, 'http') !== false ) {

This change prevents unnecessary processing unless the field contains a link, which should mitigate the performance issue. We are also working on a more permanent solution to be included in future WPML releases.

If this solution does not resolve your issue, or if it seems outdated, we recommend opening a new support ticket. Additionally, we highly recommend checking related known issues at https://wpml.org/known-issues/, verifying the version of the permanent fix, and confirming that you have installed the latest versions of themes and plugins. For further assistance, please visit our support forum at WPML support forum.

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.

Tagged: 

This topic contains 24 replies, has 2 voices.

Last updated by Bobby 4 months, 4 weeks ago.

Assisted by: Bobby.

Author Posts
June 22, 2024 at 6:24 pm #15786930

georgeC-7

Background of the issue:
We are experiencing significant slow performance when the WPML plugin is activated. This issue has persisted despite following all the recommendations provided in a previous support ticket (link: https://wpml.org/forums/topic/string-translation-slow-website/). We engaged three professional developers to conduct a comprehensive code review of our templates and identify potential conflicts. Unfortunately, they did not find any issues within the theme that could be causing this problem. To further investigate, we consulted with a hosting company specializing in WordPress. They created a staging site and performed a thorough inspection and profiling of our website. Their performance team unanimously agreed that the issues stem from the WPML plugin. Below are the profiling results they provided: [0x00007f2dc1a14eb0] similar_text() /home/porcelan/www/wp-content/plugins/wpml-string-translation/classes/slug-translation/new-match-finder/wpml-st-slug-new-match-finder.php:103 [0x00007f2dc1a14de0] find_the_best_match() /home/porcelan/www/wp-content/plugins/wpml-string-translation/classes/slug-translation/new-match-finder/wpml-st-slug-new-match-finder.php:14 [0x00007f2dc1a14d50] get() /home/porcelan/www/wp-content/plugins/wpml-string-translation/classes/slug-translation/class-wpml-rewrite-rule-filter.php:37 [0x00007f2dc1a14c80] rewrite_rules_filter() /home/porcelan/www/wp-content/plugins/wpml-string-translation/classes/slug-translation/RewriteRules/Hooks.php:52 [0x00007f2dc1a14c10] filter() /home/porcelan/www/wp-content/plugins/sitepress-multilingual-cms/inc/absolute-links/absolute-links.class.php:485 [0x00007f2dc1a14ac0] all_rewrite_rules() /home/porcelan/www/wp-content/plugins/sitepress-multilingual-cms/inc/absolute-links/absolute-links.class.php:445 [0x00007f2dc1a149d0] initialize_rewrite() /home/porcelan/www/wp-content/plugins/sitepress-multilingual-cms/inc/absolute-links/absolute-links.class.php:100 [0x00007f2dc1a144c0] _process_generic_text() /home/porcelan/www/wp-content/plugins/sitepress-multilingual-cms/inc/absolute-links/absolute-links.class.php:656 [0x00007f2dc1a14440] convert_text() /home/porcelan/www/wp-content/plugins/sitepress-multilingual-cms/classes/utilities/class-wpml-translate-link-targets.php:31 [0x00007f2dc1a143c0] convert_text() /home/porcelan/www/wp-includes/class-wp-hook.php:324 [0x00007f2dc1a142e0] apply_filters() /home/porcelan/www/wp-includes/plugin.php:205 [0x00007f2dc1a14200] apply_filters() /home/porcelan/www/wp-content/plugins/acfml/classes/Field/FrontendHooks.php:27 [0x00007f2dc1a14130] convertTargetLinks() /home/porcelan/www/wp-content/plugins/sitepress-multilingual-cms/vendor/wpml/fp/core/functions.php:17 [0x00007f2dc1a140b0] WPMLFP{closure}() /home/porcelan/www/wp-content/plugins/sitepress-multilingual-cms/vendor/wpml/fp/core/Either.php:207 [0x00007f2dc1a13f80] map() /home/porcelan/www/wp-content/plugins/sitepress-multilingual-cms/vendor/wpml/fp/core/Either.php:257 [0x00007f2dc1a13f10] chain() /home/porcelan/www/wp-content/plugins/sitepress-multilingual-cms/vendor/wpml/fp/core/Promise.php:24 [0x00007f2dc1a13e90] resolve() /home/porcelan/www/wp-content/plugins/sitepress-multilingual-cms/vendor/wpml/wp/classes/Hooks.php:50 [0x00007f2dc1a13df0] WPMLLIBWP{closure}() /home/porcelan/www/wp-includes/class-wp-hook.php:324 [0x00007f2dc1a13d10] apply_filters() /home/porcelan/www/wp-includes/plugin.php:205 [0x00007f2dc1a13c10] apply_filters() /home/porcelan/www/wp-content/plugins/advanced-custom-fields-pro/includes/acf-value-functions.php:118

Symptoms:
The primary problem is an additional 5-10 seconds of loading time when the plugin is enabled.

Questions:
What can be done to resolve the significant slow performance when the WPML plugin is activated?
Are there any additional steps or configurations we should consider to improve the loading time?

June 24, 2024 at 10:31 pm #15812166

Bobby
Supporter

Languages: English (English )

Timezone: America/Los_Angeles (GMT-08:00)

Hi there,

Thank you for sharing these findings, I will review them and in the meantime,

may I ask you to please do the following:

1 - Re run this action if you have not yet on the staging site
https://wpml.org/errata/reducing-size-of-icl_translate_job-icl_translate-and-other-wpml-tables/

2 - Can I reproduce the performance issue simply by reloading any page or the dashboard in the backend or do I need to do this with specific pages/posts ?

3 - You mentioned that you see a loading time increase of 10 seconds with WPML activated

a. What are your results when you leave WPML activated but instead switch your theme to a standard theme such as twenty24

b. What are your results when WPML and any 3rd party plugin that is essential to have the site working are activated? (Sometimes certain 3rd party plugins + WPML can have some incompatibility causing this )

June 25, 2024 at 7:29 am #15817368

georgeC-7

Hello Bobby,

Hello,

1. I have re-run the process as per the guide, but unfortunately, it did not resolve the issue.
2. The problem is isolated to the frontend and occurs regardless of the page.
3. The loading time increases significantly when the String Translation plugin is activated.
a. Switching to another theme, such as Storefront, resolves the problem.
b. None of the third-party plugins are causing issues or crashing WPML. I have tested
multiple scenarios without identifying any issues.

While it seems logical to suspect our custom theme as the source of the problem, but after extensive debugging and research by both our team and external developers for the last couple of weeks have not revealed any bugs or issues within the theme. All of them agreed and asked me to create a ticket on WPML.

We have successfully implemented many projects over the past years, with the same tools, same devs, same theme! It's the first time facing this issue.

Thank you.

June 25, 2024 at 6:12 pm #15824138

Bobby
Supporter

Languages: English (English )

Timezone: America/Los_Angeles (GMT-08:00)

Thank you for walking through these steps and confirming them with me.

Given that the issue is resolved when switching from the custom theme to a standard WP theme, it strongly suggests that the theme's code is the root cause. Otherwise, such a significant difference wouldn't be observed.

Based on the information, it is logical to believe this issue is due to a conflict between the theme and WPML's code.

Since you hired a team to test this further, what was their opinion? Did they find any specific issues with the theme?

The shared information was solely on WPML's code which when the theme is not present does not have this issue.

I'd be happy to escalate this to our development team for review, but please note that we cannot support custom themes as per our policy.

June 26, 2024 at 11:19 am #15833011

georgeC-7

Hello Bobby,

Every developer who has taken on this task agrees that the issue originates from the WPML String Translation plugin. FYI, all tests and profiling indicate the plugin as the problem. Please see the attached images and logs from another server, which also confirm that this is not a theme issue but rather a plugin fault.

As the authors of the theme, we have had multiple developers thoroughly inspect the issue and the theme itself. None of us, including myself, have found anything wrong, nor any unusual queries or other issues.

To be honest and clear, using an empty storefront theme doesn’t really convince me that the plugin is functioning correctly. This is why we continue to contact support, as we are not getting anywhere by looking at the same aspects repeatedly.

We kindly request your support or the involvement of tier 2 support to take a closer look at this issue. We are out of options. All we need is to find what is causing this massive delay in loading.

Thanks you for your help!

2024-06-19_783665_plugins.png
2024-06-19_783665_plugins (1).png
2024-06-19_783665_plugins (2).png
June 26, 2024 at 11:21 am #15833061

georgeC-7

And the Slowlog and the reposnse from the server support that run an inspection also on the website!

support-print.png
June 26, 2024 at 8:01 pm #15837027

Bobby
Supporter

Languages: English (English )

Timezone: America/Los_Angeles (GMT-08:00)

Thank you for the above information.

I am happy to investigate this further but I will note again that our support is limited when it comes to custom themes and custom work overall.

I would like to request temporary access (wp-admin and FTP) to your site to test the issue.
(preferably to a test site where the problem has been replicated if possible)

**Before we proceed It is necessary to take FULL BACKUP of your database and your website. Providing us with access, you agree that a backup has been taken **

I often use the Duplicator plugin for this purpose: http://wordpress.org/plugins/duplicator/
You will find the needed fields for this below the comment area when you log in to leave your next reply.
The information you enter is private which means only you and I have access to it.

NOTE: If access to the live site is not possible and the staging site does not exist please provide me with a duplicator package created with the duplicator plugin.

Thank you,
Bobby

July 1, 2024 at 6:46 am #15865948

georgeC-7

Hello Bobby,
Any updates on the issue?

Thank You!

July 1, 2024 at 6:29 pm #15870180

Bobby
Supporter

Languages: English (English )

Timezone: America/Los_Angeles (GMT-08:00)

Hi there,

I believe the issue here might be more related to woocommerce rather than WPML String Translation alone. With WPML String Translation deactivated WooCommerce Multilingual does not work and activating it essentially turns the multilingual part of the WC store 'on'

These are some benchmark reports on loading time with WPML String Tranlsation deactivated:

Front end -- 11.27

Admin dashboard -- 11

Store front end -- 11.8s (Displays product categories)

Here they are with String Translation deactivated:

Front end -- 15.22

Store front end -- 24.95s

WPML + WPML ST + Custom Theme deactivated and switched to Twenty23

Store front end -- 5.5s ----> Most likely because nothing loads, the product categories are being pulled by the custom theme.

same thing with the front end homepage, which does not make this test very reliable.

-------------------------------------------

Unforutnately I cannot proceed with these tests as the server is triggering a 504 Gateway Time-out Error after I deactivated the following plugins from step #2

1. Go to WPML->Settings-> Taxonomies Translation -> Review the taxonomies from Bathtub Components - Type (pa_aksesoyar-mpanieras-typo) and on.

Essentially all the ones that are set to Translatable use translation if available or fallback to default language switch to Translatable switch the setting Translatable only show translated items

This setting is known to increase the resources required and can cause performance issues.

After changing these settings, what are your results?

2. Deactivate the caching plugins for now (Once you turn them back on we recommend using only one caching plugin rather than 2)

WP Super Cache
WP-Optimize - Clean, Compress, Cache
Autoptimize
Redis Object Cache
WP Query Monitor (known to interfere with performance issues)

July 2, 2024 at 7:09 am #15873001

georgeC-7

Hello Bobby!

Thanks for the clear explanation of the steps you've followed.
I tried your suggestion on the translatables but didin't really made a diffrence.

The 504 issue has been resolved on the staging environment. Your expertise in continuing to investigate this matter would be incredibly valuable, as I am unsure of the next steps. I would greatly appreciate your assistance.

Thanks in advance for your support!

July 2, 2024 at 9:26 pm #15878258

Bobby
Supporter

Languages: English (English )

Timezone: America/Los_Angeles (GMT-08:00)

Thank you for updating me !

Doing the following steps on the staging environment I was able to lower the loading time from around 22s to 11s.

1. Go to WPML->Settings->Taxonomies translation-> swt all the theme taxonomies to "translatable"

2. Go to plugins-> deactivate Google tag manager (most likely because we are on a staging server it is having some issues loading properly)

There are a lot of taxonomies that needed to be adjusted, I have share a screencast showing that as Its too many to list here 🙂

hidden link

Let me know your results, please.

July 3, 2024 at 6:57 am #15881031

georgeC-7

Hello Bobby,

This sounds to make a sense!

After making the changes to the settings for translatables, what additional adjustments should I consider? Will there be any alterations to the content, or should I be looking for specific changes on the website?

Thank you so much for your valuable help. I genuinely appreciate it. I have noticed a slight improvement in loading speed; however, it is a minor difference.

Is there anything else we can do to make the website load faster?

With WPML activated, each page still takes around 6-7 seconds to load, which doesn't quite solve our issue. Consequently, the website's usability remains a concern.

July 3, 2024 at 5:58 pm #15886347

Bobby
Supporter

Languages: English (English )

Timezone: America/Los_Angeles (GMT-08:00)

I don't believe there is a major impact when changing this setting, but I would make sure that the taxonomies are fully translated from the WPML->Taxonomies dashboard. (From what I can see they are pretty much all translated)

Regarding the performance.

Yes, I can confirm there is still some issues remaining.

I brought the environment down to as minimal as possible and these are my findings:

1s-2s loading speed with WPML String Translation deactivated

6.5s loading speed with String Translation enabled

I have run the following actions:

#1
Run WPML Troubleshooting action in WPML->Support->Troubleshooting as well as Clean up Invalid Strings from String Translation

#2
Woocommerce->WOoCOmmerce Multilingual->Settings->Troubleshooting-> run actions

Sync products "gallery images"
Sync product stock quantity and status
Sync removed product meta from original products to translations

These helped but did not resolve the performance issue.

When running Query Monitor I see the following PHP errors logged.
22,000 errors seem like a lot and could possibly be causing a slow down.

PHP errors 22,000+ deprecated errors

preg_match(): Passing null to parameter #2 ($subject) of type string is deprecated
wp-content/plugins/wpml-string-translation/classes/slug-translation/custom-types/wpml-st-slug-custom-type.php:69

This was a known deprecated issue that was resolved in WPML 4.6.5
https://wpml.org/errata/php-8-1-preg_match-passing-null-to-parameter-2-subject-of-type-string-is-deprecated/

Are you able to change the PHP version on the staging site? Please change it to a different version, PHP 7.4 if possible just for testing purposes.

There are also some duplicate queries but these are not so significant to add that much load time -- We will however, investigate them further.
Duplicate queries:

SELECT value
FROM wp_icl_strings
WHERE context = 'WP Endpoints' 14 0.0012 WPML_Endpoints_Support->is_registered()
14 calls
Plugin: sitepress-multilingual-cms
14 calls
WPML_Endpoints_Support->add_endpoints_translations()
1 call
apply_filters()
12 calls
WPML_Endpoints_Support->translate_endpoints_in_rewrite_rules()
1 call

I also added the following to prevent the errors from being logged in your wp-config.php in the meantime.

ini_set('display_errors','Off');
ini_set('error_reporting', E_ALL );
define('WP_DEBUG', false);
define('WP_DEBUG_DISPLAY', false);

July 4, 2024 at 7:27 am #15889656

georgeC-7

Hello Bobby,

I hope you're doing well.

We have downgraded the PHP version to 7.4 in hopes that this might assist in resolving the problem.

Your guidance on how to proceed would be greatly appreciated.
Thank you for your assistance.

Best regards

July 5, 2024 at 9:40 pm #15900307

Bobby
Supporter

Languages: English (English )

Timezone: America/Los_Angeles (GMT-08:00)

Thank you, the php erros are removedd but it did not have the effects I expected.

Is it possible to access the database for the staging site?

The next step is to review the icl_ tables to make sure everything is OK.

Using plugins such as phpmyadminer or adminer I keep getting 403 errors.