Possible WPML TM issue with ACF Flexible Content causing massive custom_fields_translation growth

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.

Sun	Mon	Tue	Wed	Thu	Fri	Sat
-	8:00 – 14:00	8:00 – 14:00	8:00 – 14:00	8:00 – 14:00	8:00 – 14:00	-
-	15:00 – 17:00	15:00 – 17:00	15:00 – 17:00	15:00 – 17:00	15:00 – 17:00	-

Supporter timezone: Europe/Madrid (GMT+02:00)

Tagged: ATE

This topic contains 8 replies, has 0 voices.

Last updated by Paola Mendiburu 1 week ago.

Assisted by: Paola Mendiburu.

Author	Posts
May 19, 2026 at 9:01 am #18044974
Philip	Hello WPML Support Team, We are continuing our investigation regarding the large growth of: * icl_sitepress_settings * translation-management.custom_fields_translation on a large multilingual WordPress installation using: * WPML * ACF Pro * ACFML * Flexible Content * Repeater fields We have now identified a new part of the issue and would appreciate your feedback. When opening certain large ACF-based pages in the WordPress admin editor, after approximately 10 seconds WPML starts a background AJAX process with repeated calls to: /wp-admin/admin-ajax.php Screenshot: hidden link The requests are initiated by app.js Inside the AJAX response preview we can see: ```php WPML\TM\Settings\ProcessNewTranslatableFields ``` The payload contains: ```json progressTotal: 1329 progressDone: 1329 ``` and a large list of: ```json payload.newFields ``` Example field names: ```text glob_content_0_glob_content-col_0_... glob_content_17_glob_content-col_0_... glob_content_4_glob_accordion_... ``` etc. Important observation: The detected field names contain dynamic repeater/flexible content indexes: ```text _0_ _1_ _17_ ``` This appears to mean that WPML TM processes indexed ACF field paths as unique translatable fields. The background process also displays a loading spinner / overlay in the admin bar while processing these fields. We previously discovered that translation-management.custom_fields_translation contained extremely large numbers of entries (~76k+ before normalization). After manually normalizing indexed repeater patterns (replacing numeric indexes with placeholders such as #), the number of unique patterns dropped dramatically to only a few thousand entries. This new observation seems to confirm that WPML TM continuously detects indexed ACF field paths as "new translatable fields" during editor load... 1. Is this expected WPML TM behavior with ACF Flexible Content / Repeater fields? 2. Should indexed field paths be normalized internally by WPML / ACFML before being added to: * custom_fields_translation * icl_sitepress_settings 3. Is there a known issue where opening large ACF pages repeatedly triggers: ProcessNewTranslatableFields with indexed field paths? 4. Could this process explain the continuous growth of: translation-management.custom_fields_translation 5. Is there any recommended configuration or mitigation for large ACF Flexible Content structures? 6. Is there a way to disable or limit this automatic detection process for dynamic indexed fields? The process is triggered simply by opening the page editor. The issue appears correlated with performance degradation and increasing memory usage. Thank you very much for your help and guidance.
May 20, 2026 at 1:01 pm #18048756
Paola Mendiburu WPML Supporter since 11/2020 Languages: English (English ) Spanish (Español ) Italian (Italiano ) Timezone: Europe/Madrid (GMT+02:00)	Hi there! This is Paola and I hope you are well! I would like to request temporary access (wp-admin and FTP) to your site to take a better look at the issue. 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. Privacy and Security Policy We have strict policies regarding privacy and access to your information. Please see: https://wpml.org/purchase/support-policy/privacy-and-security-when-providing-debug-information-for-support/ IMPORTANT - Please make a backup of the 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
June 1, 2026 at 10:23 am #18072891
Philip	Hi Paola, The problem is that this issue does not occur all the time. For example, today we noticed this WPML background process running again: hidden link, and it is significantly affecting our website's performance: hidden link. Could you give us some hints about what might be triggering this process? Is there anything specific we should check or monitor? Thank you!
June 1, 2026 at 12:57 pm #18073296
Philip	P.S. In our case it was processing hundreds of posts.. At the same time we experienced situations where the WPML Translation Editor showed only a small subset of fields available for translation. The missing fields appeared again after opening the original post, clicking "Update", and then reopening the translation job. Could these two behaviors be related? We are wondering whether the translation package used by the Translation Editor could become outdated or incomplete while this background synchronization process is running. Is it expected that a translation job may temporarily contain an incomplete set of fields until this process has finished? Also, could you please explain what exactly triggers the "Updating affected posts for changes in translatable fields" process and how WPML rebuilds translation packages when ACF field structures or translation preferences change?
June 1, 2026 at 1:47 pm #18073420
Paola Mendiburu WPML Supporter since 11/2020 Languages: English (English ) Spanish (Español ) Italian (Italiano ) Timezone: Europe/Madrid (GMT+02:00)	Hi, Yes, that observation could definitely be related. If the missing fields appear after opening the original post, clicking Update, and then reopening the translation job, it usually indicates that those fields were not included in the translation package when the job was originally created. In this situation, what I would recommend is performing a bulk update of the affected content. You can do this from Pages → All Pages (or Posts), select all items, choose Edit from the Bulk Actions dropdown, click Apply, and then simply click Update without changing anything. This forces WordPress and WPML to refresh the content and rebuild the translation packages. After that, please check whether the missing fields are consistently available in the Translation Editor.
June 2, 2026 at 8:20 am #18074662
Philip	Hi Paola, Thank you for your response. Today we noticed repeated errors in the browser console related to WPML: hidden link The request: /wp-json/wpml/v1/wpml-content-stats returns: 403 Forbidden with the response: { "code": "rest_cookie_invalid_nonce", "message": "Die Cookie-Prüfung ist fehlgeschlagen" } The error originates from: wpml-content-stats.js We have a few questions: - What is the purpose of the wpml-content-stats endpoint and what information is WPML collecting through it? - Is this functionality related to the background process we frequently observe: "Updating affected posts for changes in translatable fields..."? - Could repeated failures of this endpoint contribute to slow loading or reduced performance in the page editor? - Is there a WPML setting that allows disabling this content statistics functionality if it is not required? If this endpoint is expected to work, what could cause the repeated "rest_cookie_invalid_nonce" errors and how can they be resolved? Thank you.
June 2, 2026 at 9:48 am #18074960
Paola Mendiburu WPML Supporter since 11/2020 Languages: English (English ) Spanish (Español ) Italian (Italiano ) Timezone: Europe/Madrid (GMT+02:00)	Hi there! I can confirm that the wpml-content-stats endpoint is used to collect content and translation statistics, such as content counts, translation coverage, language information, and translation editor usage. These statistics are used internally by WPML and are not directly related to the translation process itself. From what I can see, this functionality is separate from the background process "Updating affected posts for changes in translatable fields...". The 403 rest_cookie_invalid_nonce error indicates that WordPress is rejecting the REST API request due to a failed nonce validation. This is usually related to session, cache, security plugins, firewall rules, CDN/proxy layers, or REST API restrictions rather than the content statistics functionality itself. As an additional check, could you please make sure that the following domains are whitelisted and not being blocked by any firewall, security plugin, hosting security layer, or CDN? wpml.org cdn.wpml.org api.wpml.org api.toolset.com *.cloudfront.net Please also let me know if you are using Cloudflare, Wordfence, Sucuri, ModSecurity, or any similar security solution.
June 2, 2026 at 12:04 pm #18075430
Philip	Hi Paola, Thank you for the clarification. What confuses us is that the error is occurring on our own local REST endpoint: /wp-json/wpml/v1/wpml-content-stats The response is: rest_cookie_invalid_nonce which seems to indicate a failed WordPress nonce validation rather than a blocked connection to external WPML services... We understand that this functionality is used only for WPML statistics and is not required for translations themselves. Could you please clarify: Is there a way to completely disable the wpml-content-stats functionality if we do not need these statistics? Is this endpoint expected to run every time the page editor is opened? Are there any WPML hooks, constants, filters, or settings available to disable content statistics collection entirely? We are mainly trying to determine whether this functionality is necessary and whether disabling it could reduce the amount of background activity in the admin area...
June 3, 2026 at 2:56 pm #18079193
Paola Mendiburu WPML Supporter since 11/2020 Languages: English (English ) Spanish (Español ) Italian (Italiano ) Timezone: Europe/Madrid (GMT+02:00)	Hi, Thank you for the clarification. You are correct that the rest_cookie_invalid_nonce error is a WordPress nonce validation error occurring on the local WPML REST endpoint and not a failed connection to WPML external services. After reviewing the WPML code, I can confirm that the wpml-content-stats endpoint is used for WPML's internal content statistics collection. It is not required for translating content and it is separate from the translation workflow itself. I could not find any documented WPML setting, constant, hook, or filter that allows disabling this functionality entirely. Regarding performance, the presence of this failed request alone is not sufficient to conclude that it is responsible for editor slowness. To identify the actual bottleneck, I recommend installing Query Monitor and checking which queries, hooks, REST requests, or plugins are consuming the most time while loading the editor. If you can provide a Query Monitor screenshot from the editor page, I will be happy to review it and help identify the source of the slowdown. Or you can give me access to review the performance issue. I have enabled next answer as private so you can add the credentials in a private mode.