Home›Support›English Support›[Waiting for user feedback] We are experiencing a performance issue related to WPML.
[Waiting for user feedback] We are experiencing a performance issue related to WPML.
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.
Our wait time is higher than usual, please make sure you are meeting the minimum requirement - https://wpml.org/home/minimum-requirements before you report issues, and if you can take a look at current Known Issues - https://wpml.org/known-issues/. Thank you.
Background of the issue:
We are trying to optimize the database performance and noticed that the wpml-scanning-files-hashing option in the wp_options table has an extremely large size (over 1MB). Since this data is set to autoload, it significantly impacts the site's performance. Our SQL query returned the following results: SELECT option_name, LENGTH(option_value) FROM wp_options WHERE option_name = 'wpml-scanning-files-hashing'; Result : wpml-scanning-files-hashing | 1061337 bytes. We have checked the Kinsta guide on reducing autoloaded data: hidden link. However, we couldn't find specific information regarding wpml-scanning-files-hashing in WPML's documentation.
Symptoms:
The wpml-scanning-files-hashing option in the wp_options table has an extremely large size, impacting site performance.
Questions:
What is this option storing exactly?
Can this data be safely deleted or reset?
Is there a way to prevent it from growing too large?
Would disabling autoload for this option affect WPML functionality?
Could you provide guidance on how to handle this issue without affecting WPML’s functionality?
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Rome (GMT+02:00)
Hello,
I'm going to help you get started while a supporter takes your case.
We started to roll out our performance fixes from WPML 4.7.2 so could you try updating to that version (After a site backup or on a staging site) and check if you notice some changes?
There will be more coming soon as well. let's try that first and see how it goes before we move onto more specific things like the questions you asked.
Thank you for your response. We checked and indeed, there was an issue—we were not seeing the notification for a new version of WPML. We will plan an update to version 4.7.2 soon, but in the meantime, we would still like to get some clarification regarding our questions:
- What exactly is stored in the wpml-scanning-files-hashing option?
- Can this data be safely deleted or reset without breaking WPML functionality?
- What causes this option to grow so large, and is there a way to limit its size?
- Would disabling autoload for this option (UPDATE wp_options SET autoload='no' WHERE option_name='wpml-scanning-files-hashing';) cause any issues with WPML?
Even if the update might resolve the problem, having these answers will help us understand WPML’s behavior better and prevent similar issues in the future.
I'm consulting our second-tier supporter about your questions regarding the wpml-scanning-files-hashing option and will get back to you. Meanwhile, please proceed with updating WPML.
Thank you for your detailed report regarding the wpml-scanning-files-hashing option. We’ve reviewed this with our second-tier support team, and here’s what we can share:
This option stores hashes of files related to your active themes and plugins. WPML uses it to detect changes during the Theme and Plugin Localization scan, so it only re-scans when a file has been modified.
In your case, the large size (over 1MB) may indicate that the site has a large number of themes or plugins, or perhaps certain themes/plugins include a significant number of files, which increases the data stored in this option.
It is generally safe to delete or reset this option. WPML will regenerate it during the next scan under WPML → Theme and Plugin Localization. However, some or all of the data may be repopulated depending on your site's structure.
Disabling autoload for this option (i.e., setting autoload='no') should not cause any issues. WPML will still function as expected. That said, it's possible the option may revert back to autoload after a new scan, which is similar to what happens when the option is deleted.
If you'd like us to take a deeper look, especially to understand why the size has grown so much, we’d need access to your site and approval to grab a copy. Otherwise, please allow me to take a copy of your site. I must install a plugin like Duplicator or All In One Migration for this. Please let me know if you agree.
If you need further help with this, please share the access details to your site with me. I'm enabling a private message for the following reply. Privacy and Security Policy
We have strict policies regarding privacy and access to your information. Please see: https://wpml.org/purchase/support-policy/privacy-and-security-when-providing-debug-information-for-support/ **IMPORTANT**
- - Please backup the site files and database before providing us access. --
-- If you have a staging site where the problem can be reproduced, it is better to share access to the staging site.--
Thanks a lot for the detailed explanation — that was super helpful!
We'll go ahead and run some tests on our side based on your recommendations. Once we’ve completed our checks and received approval from our client, we’ll get back to you with access so you can investigate further if needed.
Thanks again for the support, and talk to you soon! 🙂
I wanted to install the All In One Migration or the Duplicator plugin to take a copy of your site and esclate this issue to our second-tier supporters. However, your hosting provider has banned those plugins. Please see the attached screenshots.
Could you please provide us with a package of your site (files + DB)?
You can upload it to a service like Google Drive or Dropbox and share the link with me.
For this, I'll enable private messages for the following reply.
