[Resolved] Fix to avoid huge option icl_sitepress_settings
This thread is resolved. Here is a description of the problem and solution.
Problem:
The client noticed a very high level of request made by WPML resulting in lot of data loaded in wp_options from icl_sitepress_settings (337580)
Solution:
The tabel row icl_sitepress_settings on wp_options keeps important information about settings and translations. It is not recommended to delete any values.
Our website is little bit slow: hidden link and we noticed a very high level of request made by WPML resulting in lot of data loaded in wp_options from icl_sitepress_settings (337580) as you can see in the screenshot.
Would you have a solution to reduce this number?
You can check out in the backend and via ftp but please do not make change before telling us because most of the things are set up for a reason and a change could make a few not work anymore.
It is not advisable to delete data from the wp-options table.
Now, you could measure the impact caused by WPML by disabling all additional plugins and using a tool to measure the page load time.
Example: hidden link
Now, the page load time with WPML usually is about 1-2 seconds. Also make sure to compare the page load time to a setup where WPML is disabled.
At last, the performance issue could be related to PHP errors.
enable the wp-debug feature to see if there are any current PHP errors given.
The wp-config.php is located in your WordPress root directory. It’s the same file where the database configuration settings are. You will have to access it by FTP or SFTP in order to edit it.
If you open wp-config.php and that define statement is not there, you can add it right before this line:
/* That's all, stop editing! Happy blogging. */
You will be able to find a complete report inside of your wp-content folder. Look for a debug.log file and provide me the results.
Let me know about the results. In case the debug-log is very long please add it to a web tool like pastebin.com and send me the link.
Kind regards,
Andreas
I could suggest to make a backup of your site and database and go to WPML -> Support -> Troubleshooting. Here use the options to CLEAN UP the DB and furthermore down the option to clear the cache of the string tables.
Thanks for your reply. Unfortunately we do not have a second server with the same environment to make a test and we cannot do it on our live website.
We just checked our error.log available with our ost provider (Kinsta) and there is no No log entries found.
I tried your last option about the CLEAN UP option, I could not use the option "Remove ghost entries from translation tables" as it makes the functionality of the website not working well but I did all the rest.
Results:
- The issue is still there for the interview category posts
- the icl_sitepress_settings is still having 337580 data entries (cf screenshot)
What would be the next step to help resolve this issue knowing our limits?
I would like to take some performance tests on your website.
Hello,
I would like to request temporary access (wp-admin and FTP) to your site to take a better look at the issue. It would be better to a testing site where the issue is replicated.
You will find the needed fields for this below the comment area when you log in to leave your next reply. The information you will enter is private which means only you and I can see and have access to it.
I'll need to replicate your site locally. For this, I’ll need to temporarily install a plugin called “Duplicator” on your site. This will allow me to create a copy of your site and your content. Once the problem is resolved I will delete the local site. Let me know if this is ok with you.
IMPORTANT
Please make a backup of site files and database before providing us access.
If you do not see the wp-admin/FTP fields this means your post & website login details will be made PUBLIC. DO NOT post your website details unless you see the required wp-admin/FTP fields. If you do not, please ask me to enable the private box. The private box looks like this: hidden link
I will try to take a copy of the site using the Duplicator plugin in order to analyze the site performance on my local machine.
In case the performance issues are caused by WPML I will escalate to one of our performance developers. I will reach out back to you with my results about this lately tomorrow. I hope this is fine with you?
I have installed a local copy of your website and proceeded with all available plugin updates. I used the Google chrome Add-on "Page Load time" to measure the time needed to generate the homepage and the backend. hidden link
On my local test, your website has a page load time from up to 2 seconds when using only our WPML plugins, Yoast SEO and the plugins coming with The7 Theme.
This value is expectable when using WPML.
I then activated the additional plugins and the page load time varied between 2-3 seconds.
In case you receive higher values the issues might be related to the hosting plan or the server used.
Now, please take those two points in mind:
1) Your website is showing errors in regards to the plugin WP-Jobsearch. Those errors also are visible when our plugins are disabled, which for I would suggest you to contact the Eyecix Support Team.
2) I further see you are using Loco Translate. Please avoid using various translation plugins at the same time as this might cause compatibility and performance issues.
When activating WP Jobsearch, and Loco Translate the page load time enhances to up to 10 seconds on my test.
Please try solving the error caused by WP-Jobsearch with the respective support team and avoid using Loco Translate or other translation plugins at the same time when using WPML.
Yes but I need loco translate to change the default title of the plug in as I cannot with WPML for the original language.
I also have this tool on google chrome on our current website loads in 3,5s (and WP rocket is deactivated for now because their devs are working on an issue with this plugin). It was also loading in 2s previously with WP rocket, and all other plugins activated. This tool is not accurate with what you experience in real life and far from Gtmetrix results for all websites, that's why we do not use it anymore.
The job board developers are extremely hard to reach and do not make change for the optimisation of the performance, only for the design and user experience.
But on your website, does the tabs related to WPML I was talking about in my first posts decrease, because that was the goal of this ticket? Not to check other plug ins errors 😉
The performance issue on your website is mainly caused due to the following error which is triggered by WP-Jobsearch:
add_submenu_page was called incorrectly. The seventh parameter passed to add_submenu_page() should be an integer representing menu position. Please see Debugging in WordPress for more information. (This message was added in version 5.3.0.)
I would suggest you use a different plugin instead, in case you are not receiving support, but I can not provide this issue to our developers, as it is not WPML related.
Now, in the case of Loco Translate, I have to repeat that we do not advise to use it at the same time when using another translation plugin. What are you referring to with "change the default title of the plugin"? Please provide a link or screenshot to see if we can solve the issue with WPML.
I understood you were concerned about performance issues caused by huge WPML tables, but when I review your site with the plugin Query Monitor, there are indeed some slow queries related to WPML which cause a latency but they are causing a delay of about 0.7 seconds.
I am consulting our team about the option value length mentioned in your first message, and I will get back to you as soon as I received feedback.
thanks for those precious answers. I will let know the devs of the job board plugin.
I followed your advice for now and deleted loco translate. Please review the screenshot, the titles in the red rectangles are examples of what I changed with Loco translate. It is default title added by the plugin. Is there a way to change it with WPML? I asked several time to the devs of the job board but they told me that the only option was using loco translate.
Thanks for following up on the option value length.
What is the link with the high number of entries in icl_sitepress_settings (337580)? Do you have a solution to reduce those entries?
Yes we asked to the developers of the job board to modify their code for our website in order to have a kind of "fall-back" function when a jobs has not been translated, to make it appear on the job search pages (whatever the language). Like we have thanks to WPML with the blog posts. I don't know how they achieve it, but that enable us to show our all our jobs in all languages as our recruiters add their jobs ads in one language. For instance, looking for a bilingual speaker in english, german and french; our recruiter might post the job only in english and might never translate it into another language as the person is looking for should speak english, but we want the job to appear on the french and german job search pages as those king of candidates might look for a job on those pages.
The two french jobs you might see well added are jobs that a recruiter might has post through the french recruiter account, but most of them use the english account to post their jobs: hidden link. It just depend on which language they log in on their account.
Just to be sure, the new m.o file your created, has been created on your version of our website, not on our live version?
As mentioned already icl_sitepress_settings (337580) refers to all options included in WPML, like config, shortcodes, field statuses (translate,copy) and the value is expected. We do not recommend to delete anything here.
Further, it was a good decision to not use LocoTranslate with WPML at the same time as this might bring issues due to translation tasks and site performance. (Same as running two page builders or two AntiVirus clients at the same time)
The new .mo-files created by WPML are custom files that are saved at an own folder. those files do not overwrite the original .mo-files.
Our latest plugin version creates custom -mo-files and keeps the translations saved in those files. Deleting them will lead to loss of translations. The idea here is to lower the number of strings that need to be saved in the database, in order to minimize the DB size and enhance the site performance.
More information here: https://wpml.org/2019/10/wpml-4-3-with-revamped-string-translation/
I hope this answered your question but there is nothing to worry about WPML creating its own .mo-files. It is actually a really great feature.
In regards to the Jobs post type question. Please take note that I checked a translate Job Post Type and the page was translated correctly. If there is an issue due to the fallback option I would kindly like to ask you to open a new ticket with the respective topic and mind this one as resolved.
I hope for your understanding as we trying to keep tickets ordered due to the topic raised and the solution or answer provided.
No, you never mention it. That's why I was keep asking what was this folder and if there were a way to optimise it. But now you explain me, it makes sense. That's was basically all what I wanted to know since the first ticket open 😉
I am still not sure why you "recreated mo-files at WPML -> and then checked the strings on String Translation and they were translated already." What was the goal?
Regarding the jobs posts, I never say there were a problem, I explain you how it works because you asked me, and still not sure what was the goal of knowing that about the job board ? I talked about it because I explained you, that with Loco translate I was changing the default titles of the plug ins in english, that's why I was using it. And I think you were tying to find a solution to see if WPML is able to do like Loco translate, that's mean modifying the plugin templates. In the image added, you will see in the rectangles the titles in job descriptions that we modified previously with loco translate.
I thought I had explained the icl_sitepress_settings option in my first reply but in fact, I just wrote that we can not recommend to delete data from this table option. Sometimes we really do not have the time to read a whole ticket again, as we are handling quite a lot of them. I hope you understand that.
Let me explain again the sense of those custom .mo-files. If you go now to WPML -> Theme and Plugin Localization you will still be able to manually scan Plugins and Themes for new strings. This method will actually save the strings in the database as those strings are getting added to String Translation. We do still recommend this method in case there are an issue with translating specific strings.
We realized that adding all the strings to String Translation lead to huge database tables and many customer complained about high page load times due to slow database queries.
Now, as each theme or plugin comes with its own .mo-files our developers found a way to make WPML create additional custom -mo-files that are updated in real-time and then merged with the default .mo-files on the fly. Now, as for example, if you translate a page with our WPML Translation Editor those strings are saved in these mentioned custom files and this helped us to solve the issues in regards to database size and performance.
Those string, therefore, will no longer needed to be saved in the database and are held in their dedicated WPML custom .mo-files which are saved at /wp-content/languages/wpml/.
About the "Jobs" translation I was understanding somehow that here still was an issue. Sorry, for the misunderstanding 🙂
