frankyn
|
same problem
size: 126680
|
roy-edvardE
|
We are an award-winning agency, and we have the same problem on all WPML sites. Can someone from WPML please provide us with an update?
Unless this is fixed ASAP, we will terminate all licenses, and move all of our clients on to a different solution. We are horrified to see that this ticket has not been flagged as critical, as it should!
UPDATE 26/06/25: We have created a separate support ticket for this issue, and will update this post as soon as we get any viable feedback.
|
peterL-60
|
I updated WPML today to the latest version hoping to find that this has been resolved. But the wp_installer_settings is still there and still a huge performance issue on our site.
Additionally I am now seeing an almost equally sized autoloaded item called "_icl_cache". This has made performance issues even worse on our site.
Looking inside of _icl_cache it is full of metadata for every single possible language and flag information a person could potentially use in WPML. Not just the 9 languages supported by our site.
So just like wp_installer_settings it is questionable if this data should even be getting stored in wp_options to begin with. And it is clear that it should not be autoloaded data which WordPress is forced to query and load for every. single. request. on the site.
I don't feel like WPML fully understands or takes seriously the implications of autoloaded data. I've had issues going back almost 5 years now when I first implemented WPML with autoloaded data causing performance issues. One was quickly resolved, the other 3 remain.
|
peterL-60
|
Instead of fixing the 'wp_installer_settings' autoload issue. Now we have that + '_icl_cache'. Doubling the problem. What the heck!?
|
JP
|
Hi,
I tried the following on my staging site:
I made a full backup of the dbase, I deactivated WPML, then deleted the wp_installer_settings string in the database completely.
Then I reactivated WPML again with the license key.
This process took 4 minutes in total.
Now the big autoload is gone and have a good performance improvement of the site.
I see no negative side effects on the site and on using WPML after 4 weeks now.
In future I will update the plugin via FTP and not via the plugin dashboard. This will also prevent the string to grow in size as long the WPML developers do not have an 'auto clean function" for this string during an update.
if these steps are not advised to do for reasons I am not aware of, please let me know.
JP
|
charikleiaK
|
Hello,
Same here, top 3 autoload options by size are from WPML.
And they account for more than 30% of the size of all the autoload options together.
Any updates?
|
mantasS-3
|
Same problem. Waiting for update
|
andreasS-58
|
As an agency, we're experiencing the same issue with many WPML sites.
The autoload caused by WPML is clearly affecting performance.
Something like this can't go unaddressed for so many months. C'mon...
|
caterinag-2
|
same on my small website and performances are drastically compromised
|
Adam
|
Same problem with "wp_installer_settings" at 129612. Is it safe to just turn the autoload setting in the database from "on" to "off" for now?
|
johnS-29
|
I found this after going into the WP site health page and getting a "CRITICAL ISSUE: Autoload option could affect performance."
Well, I went down the rabbit hole and came up to this support forum, with a wp_installer_settings size of 128,772.
I would say that if WordPress itself says it's a critical issue, the developers need to put this as a priority #1 to fix.
|
sanderK-17
|
Same problem here:
wp_installer_settings 128676
icl_st_settings 29358
icl_sitepress_settings 29049
wpml_strings_need_links_fixed 18289
|
Paolo
|
I can confirm, after logging the content of the option, the whole WPML changelog is saved in a wordpress option. This is an insane and unacceptable level of incompetence.
|
