[Assigned] wp_installer_settings is autoload and large
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.
<b>Background of the issue: </b>
I am trying to figure out why wp_installer_settings is loaded with autoload and has a large size.
<b>Symptoms: </b>
I expected to see no autoload for installer settings, but instead, I got a 105736 database entry.
<b>Questions: </b>
Why is wp_installer_settings loaded with autoload?
How can I reduce the size of the wp_installer_settings entry?
extra note:
so much is being loaded on auto_load just from WPML, that is over 50% of the total database load:
1 wp_installer_settings yes 105736
3 icl_sitepress_settings yes 34717
4 icl_st_settings yes 20869
7 wcml_currency_switcher_template_objects auto 11020
13 wpml_shortcode_list yes 7599
14 wpml_language_switcher_template_objects auto 7343
16 WPML(ST-MO) yes 5575
20 otgs_active_components yes 3967
- Go to WPML > Support > Troubleshooting > Clean up and click to run next:
- Clear the cache in WPML
- Remove ghost entries
- Fix element_type collation
- Set language information
- Fix post type assignment
- Clean up strings and optimize
this seems quite high risk- as this is an experimental function.
Also, it does not mention our biggest autoload issue, the wp_installer_settings yes 105736.
Question remains why WPML is so sloppy with their autoload functions, and requires constant maintenance and corrections. We had the seem issue a couple of months ago that required us to perform a lot of manual work.
Can you clarify per line what the function of this is, and whether we could delete or turn autoload of for these items. We would like to better understand why there are so many entries in the first place.
But the question remains why this plugin creates SO MANY, and LARGE autoload tables. This is def not best practice, and this is not the first time it has happened. If the plugin you mentioned is designed for that, why is this not standard practice within WPML?
Furthermore, the thread you mentioned does not talk about our 4 largest database entries:
1 wp_installer_settings yes 105736
3 icl_sitepress_settings yes 34717
4 icl_st_settings yes 20869
7 wcml_currency_switcher_template_objects auto 11020
Your concerns and point that you are raising are 100% valid, just to make sure this is clear --- what we are suggesting is simply a workaround/fix provided by our team to help you resolve this situation.
Our team is actively working on this issue and there is an open development ticket which is why the Errata status is set to Open.
wp_installer_settings --> Holds data related to the installer plugin along with license key, update settings, etc. (this is probably the one that if you had to delete one I'd say you can go ahead and delete [it will re populate] but then you will need to re register the site --- also please do not delete anything without having a backup in place. )
icl_sitepress_settings --> main configuration data such as the default language, language URL format chosen, active languages, custom post type preferences, etc.
icl_st_settings --> Translation engine preference (deepl, azure, etc) , admin text settings, anything related to String Translation and strings.
wcml_currency_switcher_template_objects --> data related to WCML, serialized data about the currency switcher, etc.
When you say the team is still actively working on this; should I somply wait for you to have a better solution? Or what time frame are we talking about?
What would be your recommended step-by-step instructions to proceed?
There is an active development ticket, there is no ETA at the moment and I'd suggest following the workaround in the Errata documentation rather than waiting as even when a solution is introduced to prevent this behavior completely you would still have to optimize these fields and fix them to reduce their size.
In total there were less than 50 jobs to be deleted. So overall this has not had the desired effect, and we still have a major autoload for no apparent reason. Can you provide a real solution to my question that will actually address the issue? Perhaps discuss with the tech-team. I still have over 50% of the autoload being loaded by a single plugin (WPML), which is unacceptable.
Thank you for attempting the solution, I hope you understand why I persisted as I have personally worked on more than just one case with similar issues.
I will share your results with our team, is it possible to take a closer look at the backend?
We can create a staging site that way the live production is not affected, that will allow our team to review the database fields and give you a solution that resolve this.
----------------------
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.
due to legal and privacy reasons we cannot provide you with access to our database, and in fact I believe this is an illegal request as it directly conflicts with EU regulation. Removing that data in the staging environment might be an in between, but the issue with that is that the data itself might be causing part of this bloat in the WPML database.
Even if we did proceed with that it would be an incredible cumbersome process to set-up and arrange, while WPML simply has their technicalities not in order.. If you say this is not the first case, it sounds like a structural issue.
Based on the number of database entries, the size of them, and the obsessive use of autoload it makes me wonder how professional and optimized your paid plugin is in the first place.
I would appreciate a more suited and less invasive solution.
Following further internal discussions, it's essential that we obtain a sample of the site for our development team to review. Without this, we’re unable to accurately determine the root cause of the issue you're experiencing.
As previously mentioned, the errata workaround has effectively resolved all other reported cases related to large autoload sizes. If it hasn't addressed the issue in your case, it likely points to a different underlying cause.
Additionally, based on the feedback we've received, the current autoload size appears to fall within a normal range.
We appreciate your cooperation in helping us investigate this further.
the fact that you consider the current autoload size within a normal range says a lot. I once again repeat that your autoload files are bigger than every single autoload combined from every other plugin that is running... So you are loading more than woocommerce and wordpress itself, and all of the plugins combined. When you call this 'normal range', it seems that your quality standards are not very high.
Even ChatGPT is surprised about the size of these things and gives strong recomendations to fix this, f.e:
wp_installer_settings ❌ 2/10 Too big to autoload; mostly used in admin area
Furthermore from ChatGPT:
We're seeing autoload entries from WPML such as:
wp_installer_settings – 105 KB
icl_sitepress_settings – 34 KB
icl_st_settings – 20 KB
Others in the 5–11 KB range
This means over 180 KB is being autoloaded from WPML alone on every page request, regardless of whether WPML is actively used on that page. This affects front-end performance and backend memory usage, especially on high-traffic sites.
➤ Industry Best Practices Say Otherwise:
Most performance and database optimization guidelines recommend:
Keeping individual autoloaded options under 5–10 KB
Avoiding autoloading settings that are only needed in admin contexts (like installer or UI template settings)
For example:
Pantheon flags autoload bloat over 1 MB as critical, and recommends auditing any individual option over 10–15 KB.
Tools like Query Monitor and wp-cli’s option list --autoload=on are commonly used to detect and flag large autoload entries — which WPML’s options trigger immediately.
➤ Why This Matters:
This isn’t a case of theoretical optimization — large autoload sizes directly contribute to:
Increased memory usage per request
Slower object cache and DB fetch times
Compounded performance issues in WooCommerce stores, which already have heavy query loads
Other major multilingual plugins (e.g., TranslatePress or Polylang) don’t autoload UI template data or plugin installer metadata in this way.
➤ Our Ask:
Rather than broadly categorizing this as “within a normal range,” we ask that WPML:
Specify what WPML considers normal in terms of autoload size — per option and in total
Provide guidance or safe filters/hooks to disable autoload on non-essential entries (e.g., wp_installer_settings, currency switcher templates)
Consider adding a diagnostic tool or admin UI to review WPML's autoload footprint per site
Manage Cookie Consent
We use cookies to optimize our website and services. Your consent allows us to process data such as browsing behavior. Not consenting may affect some features.
Functional
Always active
Required for our website to operate and communicate correctly.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
We use these to analyze the statistics of our site. Collected information is completely anonymous.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
These cookies track your browsing to provide ads relevant to you.
