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: Performance
This topic contains 24 replies, has 2 voices.
Last updated by Bobby 3 months, 4 weeks ago.
Assisted by: Bobby.
Author | Posts |
---|---|
June 22, 2024 at 6:24 pm #15786930 | |
georgeC-7 |
Background of the issue: Symptoms: Questions: |
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 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. 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! |
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! |
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. **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/ 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, |
July 1, 2024 at 6:46 am #15865948 | |
georgeC-7 |
Hello Bobby, 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 |
July 2, 2024 at 7:09 am #15873001 | |
georgeC-7 |
Hello Bobby! Thanks for the clear explanation of the steps you've followed. 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 #2 Sync products "gallery images" These helped but did not resolve the performance issue. When running Query Monitor I see the following PHP errors logged. PHP errors 22,000+ deprecated errors preg_match(): Passing null to parameter #2 ($subject) of type string is deprecated This was a known deprecated issue that was resolved in WPML 4.6.5 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. SELECT value 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'); |
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. 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. |