Home›Support›English Support›[Resolved] Huge icl_sitepress_settings option (20MB+) caused by ACF repeater field paths – how to clean / pre...
[Resolved] Huge icl_sitepress_settings option (20MB+) caused by ACF repeater field paths – how to clean / pre...
This thread is resolved. Here is a description of the problem and solution.
Problem: You are experiencing a performance issue on your WordPress site using WPML and ACF (Flexible Content + Repeaters), where the option
icl_sitepress_settings
has grown to an unusually large size, primarily due to massive duplication in translation-management custom fields and terms.
Solution: 1) Update the ACF and ACFML plugins to their latest versions to ensure optimal performance and compatibility. 2) Review all ACF field groups to ensure they are properly configured. Remove unused fields or groups, ensure field names are unique within each group, and adjust translation preferences to 'Same fields across languages' where applicable. 3) Consider using a GitHub plugin to clean up the
icl_sitepress_settings
option in the database. This can be tested on a staging copy of your site. However, please be aware that we are not the authors of this plugin and cannot guarantee its behavior.
If these steps do not resolve your issue or if the solution seems outdated or irrelevant to your specific case, we highly recommend checking related known issues at https://wpml.org/known-issues/, verifying the version of the permanent fix, and confirming that you have installed the latest versions of themes and plugins. If necessary, please do not hesitate to open a new support ticket at WPML support forum for further assistance.
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.
We are currently investigating a performance issue on a production WordPress site using WPML + ACF (Flexible Content + Repeaters), and we found that the option icl_sitepress_settings has grown to an unusually large size.
Current state
1) Option name: icl_sitepress_settings
2) Autoload: no
3) Serialized size: ~20 MB (20,426,475 bytes)
The majority of the size comes from:
- translation-management.custom_fields_translation
- translation-management.custom_term_fields_translation
Our findings:
In the current database dump:
- custom_fields_translation: 76,865 entries
- custom_term_fields_translation: 75,791 entries
However, after normalizing repeater indexes (e.g. replacing numeric indexes with #), these collapse to approximately:
custom_fields_translation: ~4,347 unique patterns
custom_term_fields_translation: ~3,995 unique patterns
Example:
Stored keys look like:
glob_content_0_glob_content-col_1_..._glob_teaserbox-title
glob_content_0_glob_content-col_1_..._glob_teaserbox-headline
Normalized form:
glob_content_#_glob_content-col_#_..._glob_teaserbox-title
This suggests that ACF repeater / flexible content indexes are being stored as separate entries, causing massive duplication.
Practical impact:
- WPML repeatedly reads and unserializes this large option
- We see measurable overhead in admin requests
- There are indications that parts of this data may even affect frontend calls
Additionally, this option has grown by more than 10MB over ~2 years and continues to grow with each edit in the builder.
Questions:
MAIN one: Is this expected behavior with ACF repeaters / flexible content + WPML?
Also:
1) Is there a supported way to clean or rebuild:
- translation-management.custom_fields_translation
- translation-management.custom_term_fields_translation
so that indexed paths do not accumulate as thousands of entries?
2) Is there a way to normalize or deduplicate these entries (e.g. treat indexed paths as one pattern)?
3) Can this data be safely reset or regenerated without breaking existing translations?
4) Are there any recommended settings (ACFML / WPML) to prevent this growth going forward?
5) Is there any way to cache or avoid loading the full structure on every request?
Additional context
We are also seeing heavy queries related to WPML (e.g. COUNT DISTINCT on post IDs), and we suspect this large structure contributes to overall performance degradation.
We would really appreciate your guidance on:
- safe cleanup strategy
- long-term prevention
- whether this might be a known limitation or issue
What you’re observing is currently expected behavior. The icl_sitepress_settings option stores configuration data, including preferences for custom fields, and its size can grow over time as new custom fields are added to the site.
That said, we understand your concern regarding performance and scalability. A development ticket has already been created to explore improvements in this area. While it is not yet scheduled, I’ve added your case as an additional vote to help increase its priority.
At the moment, there is no supported or safe method to reduce the size of this option manually, nor is there any tool that can do so. However, you can review available maintenance and optimization actions under WPML → Support → Troubleshooting, which may help in related scenarios.
Please rest assured that performance optimization is an ongoing focus for our development team, and improvements are continuously being evaluated and implemented where possible.
Thank you for your reply and for clarifying that this is currently expected behavior.
However, after further investigation on our side, we believe there might be an important distinction that we would really appreciate your help clarifying.
From what we see in the data, this does not look like stable configuration (as typically expected for something like icl_sitepress_settings). Instead, it appears that the entries are being generated dynamically from actual content structure...
Specifically, we are seeing keys like: glob_content_0_glob_content-col_0_..._glob_teaserbox-title
These strongly suggest that:
- ACF stores nested meta keys with concrete repeater/flexible-content row indexes
- WPML detects these concrete keys during post save/update
- WPML registers them into translation-management.custom_fields_translation
- Over time, this registry grows with content edits, not just with field configuration changes
This would mean that:
👉 the option is growing as a result of content updates, not only configuration changes
👉 and is being rebuilt/serialized repeatedly on each update
This raises a few important questions we would really appreciate your input on:
1) Are entries like glob_content_0_glob_content-col_0_... expected to be stored in WPML settings, or do they indicate that WPML is discovering fields from actual post content (including repeater indexes)?
2) Are these entries generated from:
- ACF field group configuration
or
- actual saved post content (including repeater row indexes)?
3) Can these indexed keys accumulate over time on every post update when repeater row indexes change?
4) Is this registry expected to grow continuously with content edits?
5) Is there any supported way to rebuild, clean or reinitialize translation-management.custom_fields_translation so that obsolete indexed entries are removed?
6) Should these entries ideally be stored as concrete indexed keys, or should they be normalized (e.g. # instead of numeric indexes)?
7) Is there a recommended way (e.g. via WPML → Support → Troubleshooting) to: inspect how these entries are generated or identify which actions are adding new ones?
If this requires deeper investigation, do you offer any advanced or paid support options where we could work together to analyze this in detail? Our main goal here is to reduce the performance impact of WPML on our site, and currently this growing structure seems to be one of the major contributors.
At the moment, we are missing clarity on whether this is expected long-term behavior and what safe mitigation strategies exist..
Any additional technical insight from your side would be extremely valuable for us.
Thank you again for your support and for pushing improvements in this area 🙏
Could I kindly ask you to prepare a reproducible case on your staging site where this (unexpected) behavior can be observed? Ideally, it would demonstrate that the entries are being generated dynamically from the actual content structure rather than from direct changes to custom fields (or other manipulations with the custom fields).
In the meantime, I’ll try to address your points based on what I know so far:
1. This is currently expected behavior, as the data is designed to be stored in WPML settings.
2. Without testing this specifically, it’s likely that both scenarios are valid — especially if new repeating fields are added to posts, and the content is saved.
3–4. These would require a review of a concrete example to provide an accurate assessment.
5. At the moment, there is no supported or safe method to reduce or clean this data. While our development team is exploring improvements in this area, this may be addressed in future releases.
Someone mentioned in the support ticket the following: hidden link
However, I cannot confirm its safety or compatibility, so it would need to be used at your own discretion.
6. Ideally, the data should remain stored as designed. That said, if you have normalized indexes, tested the setup, and confirmed that everything works correctly, it may be acceptable to keep it as is.
7. There is no related control available in the WPML UI. If needed, you may trace the behavior through step-by-step debugging to identify how and where this data is being stored in the code.
At this time, WPML does not offer advanced or paid support. If a custom solution or deeper debugging is required, it would need to be implemented on your side.
As mentioned earlier, this behavior is expected, as WPML stores configuration data (including custom field preferences) in this way. Our development team is aware of similar cases and has already created internal tickets to explore possible improvements.
As a follow-up to our previous investigation, we have prepared a dedicated staging environment where the issue can be reproduced and analyzed in detail:
We can consistently reproduce the issue with the following steps:
Create a new page hidden link
Add ACF Repeater / Flexible Content blocks
Fill them with some test content (example of our configuration): hidden link
📈 Observed behavior:
After saving the page, the size of the icl_sitepress_settings option increases noticeably. You can verify this by running the following query before and after the changes:
SELECT option_name, LENGTH(option_value) AS bytes_size
FROM wp_options
WHERE option_name LIKE 'icl_sitepress_settings%';
Reference: hidden link
⚠️ Critical issue
The most concerning part: When we delete the page or remove the repeater blocks,
The size of icl_sitepress_settings does NOT decrease
This strongly suggests that:
- Data is continuously generated and stored but never cleaned up
- Resulting in significant accumulation over time
🚨 Impact
This leads to:
- Extremely large icl_sitepress_settings option (~20MB in our case)
- Increasing memory usage
- Noticeable performance degradation, especially in backend/admin
We would really appreciate if you could:
- Reproduce this directly on the staging environment
- Advise on a safe and long-term solution
I have escalated your case to our second-tier support team and received their feedback. Their recommendations are as follows:
1) Update the plugins (ACF and ACFML) to their latest versions.
2) Review all field groups to ensure they are properly configured:
- Remove any fields or groups that are no longer in use
- Ensure field names are unique within each group
- Most of your groups are in Expert mode; some fields might have the wrong translation preference. Use the “Same fields across languages” option as a baseline to help verify correct translation preferences
- We also noticed some “group” type that do not contain anything inside
3) Consider cleaning up the option in the database by using the GitHub plugin I shared earlier; it could be a useful tool for testing this on a staging copy of the site.
However, please note that we are not the authors of this plugin and cannot guarantee its behavior
As mentioned earlier, our development team is aware of similar cases and has already created internal tickets to further investigate and improve this area.
Thank you for the detailed feedback and for escalating the case - really appreciate it.
I have a few follow-up questions, especially regarding point 2, to make sure we fully understand your recommendations and apply them correctly:
1. "Ensure field names are unique within each group"
Could you please clarify what exactly you mean by this? Do you refer to avoiding duplicate field keys, field names, or something else? If possible, could you point to a concrete example on our staging environment where this rule is currently violated?
2. Expert mode vs "Same fields across languages". You mentioned that most of our groups are in Expert mode and that some fields might have incorrect translation preferences.
Could you please elaborate on:
- What are the risks of using Expert mode in our case?
- What is the key difference in behavior compared to "Same fields across languages"?
- In which scenarios would Expert mode lead to issues like the one we are experiencing (e.g. large icl_sitepress_settings)?
If possible, an example based on our current configuration would be very helpful 🙂
3. Empty "group" fields. You mentioned that some "group" type fields do not contain anything inside.
Could you please share a specific example from our staging site? Whether such empty groups can contribute to the issue (e.g. data bloat in icl_sitepress_settings) or are just a general cleanup recommendation?
Also, regarding database cleanup:
Before testing the suggested GitHub plugin, we would like to better understand which exact data structures in icl_sitepress_settings are considered problematic, so we can evaluate the impact more safely...
Thanks again for your support - looking forward to your clarification.
1. For example, the field group "Footer" is set for that Option Page. You have two fields "Spalte 1/2 links" and "Spalte 1/2 rechts" and they both have the exact same sub-fields with the same field names. You can't have fields with the same name in the same field group.
>> 1. For example, the field group "Footer" is set for that Option Page. You have two fields "Spalte 1/2 links" and "Spalte 1/2 rechts" and they both have the exact same sub-fields with the same field names. You can't have fields with the same name in the same field group.
We understand that field names should be unique, but since ACF allows identical sub-field names within different parent fields, could you clarify whether this is a strict limitation of WPML/ACFML?
In our case, these fields are already widely used across the project, and renaming them would lead to data loss or require a complex data migration. Is there any safe workaround or recommended approach that would allow us to keep the current structure without renaming fields?
While ACF itself technically allows duplicate field names, using identical field names can lead to issues when combined with WPML and ACF Multilingual. In such cases, duplicate field names can cause fields not to appear for translation or to be handled as expected.
