Home›Support›English Support›[Escalated to WPML Developers team] Lowering amount of autoloaded data in wp_options
[Escalated to WPML Developers team] Lowering amount of autoloaded data in wp_options
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.
WordPress 6.7 has introduced a new issue that impact translations, please update WooCommerce and WPML to the latest versions before you report issues. More about this here - https://wpml.org/errata/php-error-wp-6-7-notice-function-_load_textdomain_just_in_time-was-called/
We've been experiencing intermittent 502 errors when editing translations on multiple sites.
The sites rely heavily on ACF flexible content fields and use WPML to translate all that content. We're hosted on WP Engine and one area they've had us look into was the autoloaded data from the wp_options table. As they require less 0.8mb for their object caching to function properly.
We were able to cut this down significantly for quite a few sites by removing the _WPML_TP_Pickup_Logger option that is no longer used. But we have a few sites that are still significantly over the 0.8mb. The site I've flagged here has 1.25mb in the icl_sitepress_settings option itself and 0.69mb in the wpml-tm-custom-xml option.
It seems the bulk of this for both is likely tied to flagging which ACF fields are translatable. It seems to get pretty hefty because a text field inside of a flexible content field can show any number of times depending on which component in the page it is part of.
These sites are translated initially by copying the page to a translation and then the translations are maintained separately from the original content. So it seems the ACF field indications are only needed on that initial copy, is that correct?
Do you have any suggestions for lowering the amount of data in these options?
Also open for other suggestions on increasing the performance of saving pages using large amounts of ACF flexible content fields.
You asked: "So it seems the ACF field indications are only needed on that initial copy, is that correct?"
I'm not entirely sure what you mean by 'ACF field indications'. I assume that you refer to the translation option for each field. In this case, the translation option would still be considered by ACF Multilingual even after the initial copy. An exception for what I just wrote is the 'Copy once' option. This option will only copy the value of the field the first time you translate the post. And would no longer keep track of the value thereafter. Please refer to our ACF guide here.
You asked: "Do you have any suggestions for lowering the amount of data in these options?
Also open for other suggestions on increasing the performance of saving pages using large amounts of ACF flexible content fields."
Here are my suggestions. Please try them and check if it is helping you to solve this problem.
1. Take a full backup of your site.
2. Update WordPress to its latest version.
3. Update ACF Pro to its latest version.
4. Update our plugins to their latest versions. WPML Multilingual CMS, Advanced Custom Fields Multilingual, Translation Management, String Translation, Media Translation.
5. I can see a plugin called WPML Portuguese lower-UPPER active on your site. I'm not familiar with this plugin. It does not seem to be a plugin we ever released. If you do not need it please remove it to be sure it is not creating any problems.
6. Use WPML's troubleshooting section.
1. Take a backup of the DB of your site.
2. Go to WPML -> Support -> Troubleshooting (link)
3. Once on the troubleshooting screen, press the following buttons and check if it helps. Press each button at a time and wait for the process to complete.
- 'Disable cache for language switcher templates' (if enabled)
- 'Clear language information and repopulate languages' button (if showing)
- 'Synchronize posts taxonomies' for all post types
- 'Clear the cache in WPML'
- 'Remove ghost entries from the translation tables'
- 'Fix element_type collation'
- 'Fix WPML tables collation'
- 'Set language information'
- 'Assign translation status to duplicated content'
- 'Fix terms count'
- 'Fix post type assignment for translations'
- 'Cleanup and optimize string tables'
7. For the problem of saving pages using large amounts of ACF flexible content fields, please check if it is not a Max Input Var issue and, if needed, increase the value of this option. You can read more about it at the following link.
hidden link
--import-
*** If your site is a live site, you might want first to try those procedures in a staging environment or a snapshot of your site on your local server or another server. ***
I'll have to work on getting those tested and updated in a staging environment.
It doesn't seem any of those options will address the root of the issue that the autoloaded data in the wp_options table is so large particularly in icl_sitepress_settings and wpml-tm-custom-xml.
Do you have any suggestions on how to address those two particular items? WP Engine suggests autoloaded data be under 800kb and right now those two options alone are about 1.8mb.
It also seems the 502 errors are more likely to occur when fields have been added to the English page. It seems that WPML may be trying to update all translated versions of that page, but each of these translated pages were originally duplicated from the English page and now are edited independently. Is there a particular setting to check / uncheck to make WPML not attempt to update the translations when the English page is changed?
It seems that the 502s are tied to large amounts of ACF fields then being updated across 9 translations when the English page is saved.
Our second-tier supporter informed me that this issue is known to us and already escalated to our developers and will be fixed in future versions of WPML. I'll add this ticket to our internal documentation, and when the version with the fix is released, I'll update you here.
To make sure that you have the same issue, please try the following.
1. Create a test field group, add some test fields, and assign it to posts post type.
2. Create a post with those custom fields.
3. You would see those fields in the 'Custom fields' section on the post's editing screen. (Scroll down to the Multilingual Content Setup section). And you would also see them in WPML -> Settings -> Custom Fields translation.
4. Delete those test custom fields from the field group.
5. Go back to the post you created in step 2, refresh the screen, or press the Update button. As expected, the fields you just deleted will not be there. But you will still see those fields in the Multilingual Content Setup section and WPML -> Settings -> Custom Fields translation.
So the problem is that WPML's Translation Management is not removing those deleted fields from the icl_sitepress_settings option in the DB. And this is the fix we are waiting for from our developers.
Does this issue also happen on your site?
Regarding the wpml-tm-custom-xml option. There is something that you can do about this issue. This is option is holding the data you inserted in WPML -> Settings -> Custom XML Configuration (tab). So instead of holding this WPML configuration in the DB, you can create a wpml-config.xml file. Please read about creating a wpml-config.xml file here.
I further discussed this issue with our second-tier supporter and one of our developers. It seems that the issue of a big icl_sitepress_settings option is a problem that is specific to hosting services like WPengine that limit the size of autoload data from the wp_options table to 0.8MB. So it is not only the issue I mentioned that deleted ACF fields are not being removed from the icl_sitepress_settings option. In your case, it seems that it can also be because your site relies heavily on ACF flexible content fields. Here is a reference to this issue in another forum ticket.
Unfortunately, we have no workaround that we can share with you to solve this issue. As I mentioned, this issue is escalated to our developers, and when I have news regarding this issue, I'll update you here.
