We also have this, and simply deleting 'wp_installer_settings' does NOT work. It just puts it right back in the database after loading a page on the website.
This ticket was openen on March 28, we are now early September; almost 6 months later.
Based on the many comments in this topic, many users are experiencing this problem and it causing real issues. For every person that comments, there are probably 999 who don't.
Reading back, promises were made that it would be resolved in 'future releases'; but apparently that does not stipulate which of the future releases. Since then we have had two major relases, and this issue has only gotten worse.
Six months to look at serious performance issues, and instead you are focusing on monetizing your AI-translations. When are you gonna look at your core functionality and performance? Can we get a definitive date when will be resolved; as otherwise we will start transitioning into alternative options that take this more serious.
Thank you for your patience while we are working on resolving this issue permanently. I completely understand your concern seeing that we had a major release recently.
We’ve reviewed this internally, raised the priority, and scheduled it for the WPML 4.9 sprint.
We’ll keep the erratum page updated and will post back here once it ships.
WPML 4.9 is what we would consider a major release and it's actively being worked on right now. Unfortunately I cannot share an exact date but typically these type of versions take around 1-2 months due to all the moving parts involved.
Having this issue as well on a client's website, only I am not so concerned by the wp_installer_settings which is 128kb. This is a major webshop with many pages and many ACF fields in repeaters, flexible content layouts, etc. Causing my icl_sitepress_settings to become 994kb (!), the sheer incompetence of placing all this config in a single database row amazes me.
Hoping for a quick fix, for WPMLs sake, since the only reason I haven't already migrated to a more serious plugin is the amount of time it would take to migrate and my client has other features prioritized. Every month ticking by might mean we have taken our business elsewhere...
Update for my previous post on sept 15. In my case my icl_sitepress_settings grew to 994kb because I have a lot of ACF fields and lots of different pages with them. After some more debugging it turns out most of the contents of icl_sitepress_settings was just old translation settings of old ACF fields that had already been deleted. It turns out WPML does not remove keys that are no longer in use, meaning long existing websites will slowly grow to insane sizes.
I wrote my own script to find unused keys and remove them, and now my icl_sitepress_settings is 'only' 384kb, which is still way too large for an autoloaded option, but at least it mitigates it somewhat by removing stuff that is not needed anyway. It is a shame WPML does not offer this themselves in the troubleshooting page that Bobby has referred to. Bobby, in case you read this, feel free to reach out to me and I will gladly give you my script (although it obviously is something you guys should have made yourself in the first place).
Also, in addition to fixing the mistake with wp_installer_settings, please also consider changing your icl_sitepress_settings option to not contain all the config of all custom fields in a single database row. I assume I do not have to why explain this is not a proper way of doing things.
I've been a client for many years, with WPML being the primary reason for our slow server response times, which in turn affect our SEO and, consequently, our revenue.
You keep releasing small updates; first 4.8.1; now months later 4.8.2.
At this rate 4.9 is gonna take up to a year?
Can you please provide an ETA when you actually will resolve the issue that MANY people have been talking and complaining about? It is kind of shocking how many people are asking you about this for months, and how little has been done to resolve these serious performance issues.
4.9 is a major release, we are actively working on this specific issue and integrating it into the 4.9 release.
The releases are not working exactly in the order that you mention, you can see in our changelog that many versions "jump" such as 4.7.6 to 4.8.0 etc.
The moment 4.9 is released we will update you directly here.
As you can imagine performance issues are quite complicated and this is not a simple code fix, our team is working to ensure that these issues are resolved and done properly.
