[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.
