ACFML does not re-map nested flexible content values after structural change in original language

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
9:00 – 13:00	9:00 – 13:00	9:00 – 13:00	9:00 – 13:00	9:00 – 13:00	-	-
14:00 – 18:00	14:00 – 18:00	14:00 – 18:00	14:00 – 18:00	14:00 – 18:00	-	-

Supporter timezone: Asia/Yerevan (GMT+04:00)

Tagged: Known issue

This topic contains 11 replies, has 0 voices.

Last updated by Christopher Amirian 1 week, 3 days ago.

Assisted by: Christopher Amirian.

Author	Posts
July 2, 2026 at 8:26 pm #18138449
Philip	Hi WPML support, We found an ACFML/WPML synchronization issue with nested ACF flexible content fields. Setup: Original language: DE Translations: EN, FR, IT Page content uses a nested ACF structure: - glob_content - glob_content-col - glob_content-col-content-left Inside glob_content-col-content-left, we use flexible content layouts such as: - glob_space - glob_content-page-text Steps to reproduce: - Open the original DE page. In the flexible content field glob_content-col-content-left, insert a new space block before an existing text block. - Save/update the original page. - Check the translated versions on the frontend. Expected result: The translated content should remain intact, and the translated text value should be remapped to the new flexible-content row index. Actual result: The translated layout structure is updated correctly, but the translated WYSIWYG/text value is not moved to the new expected row index. For example, after inserting a new space block, the translated structure becomes: - space - space - text - space But the translated text value remains stored under the old meta keys instead of the new expected key. So in practice: - the new layout map is correct - the frontend reads the new expected row index - but the text value is still stored under the old row index As a result, the translated text disappears on the frontend... What we observed in postmeta: After save, the expected translated field is something like: glob_content_0_glob_content-col_0_glob_content-col-content-left_2_glob_content-page-text But the actual translated text value remains under older keys like: ...left_0_glob_content-page-text ...left_1_glob_content-page-text In some cases the new row only gets the field reference meta (_...) but not the actual translated value. Important detail: This happens specifically inside a nested flexible content branch: glob_content -> glob_content-col -> glob_content-col-content-left It looks like ACFML updates the flexible-content row structure, but does not correctly remap the translated row values for this nested branch. We implemented a narrow theme-side workaround for now, but this appears to be a plugin-level synchronization issue. Can you please confirm whether this is a known issue with nested flexible content / repeater synchronization, and whether there is an official fix or recommended approach? We use: WordPress 6.9.4 PHP 8.3.31 WPML Multilingual CMS 4.9.5 WPML String Translation 3.5.3 WPML Media Translation 3.1.2 WPML SEO 2.2.5 Advanced Custom Fields Multilingual 2.2.4 Thank you!
July 3, 2026 at 7:45 am #18139108
Lucas Vidal de Andrade WPML Supporter since 11/2023 Languages: English (English ) Spanish (Español ) German (Deutsch ) Portuguese (Brazil) (Português ) Timezone: Europe/Vienna (GMT+02:00)	Hello there, Thank you for contacting WPML support. While you are waiting for one of my colleagues to take this ticket and work on it, let me provide you with first debugging steps or if I can perhaps help with the issue quickly. It seems you are referring to a know issue: https://wpml.org/errata/advanced-custom-fields-multilingual-reordering-repeater-fields-makes-the-translations-unsynchronised/ Try making a small change to the post's main content and saving, when editing the order of the ACF fields. That should solve it. If that does not help, one of my colleagues will soon come to continue support.
July 3, 2026 at 8:49 am #18139249
Philip	Hi Lucas, Thank you for your answer. I tested the workaround from the errata, but it did not solve the issue. What I did: - added a new Space block before an existing Text block in the original DE page - made an additional small change in the main content - saved the page again Result: translated pages still lose the translated text on the frontend. From our debugging, the problem seems to be in a nested ACF structure: - glob_content - glob_content-col - glob_content-col-content-left After saving the original page, the translated flexible-content layout is updated correctly, but the translated text value is not moved to the new row index... The old translated text remains in the previous meta keys, while the frontend reads the new index, so the text appears missing. So this looks more specific than the errata and seems related to nested flexible content inside repeater/clone structures. Please let me know.
July 6, 2026 at 9:34 am #18142770
Christopher Amirian WPML Supporter since 07/2020 Languages: English (English ) Timezone: Asia/Yerevan (GMT+04:00)	Hi, Thank you for the report. To be able to report this, we will need to replicate the issue. I created a clean installation of WordPress, WPML, and ACF Pro. You can access the admin here: hidden link Would you please add a field group with that nesting flexible content and test it on a post? Also, if you could record your screen with a site such as loom.com it will help me to understand what to do with the post to see the inconsistency. As soon as I have the info, I will quickly report this to our second tier support for further investigation. Thanks.
July 6, 2026 at 10:25 am #18142966
Philip	Hi Christopher, Thank you for your reply. I have prepared a detailed video that demonstrates the issue step by step and shows exactly what is happening. I believe it explains the problem much better than a written description. Here it is: hidden link Reproducing this on your own environment would likely be quite time-consuming because of the amount of setup and the specific content structure required. Would the video be sufficient for you to understand and investigate the issue? If not, I can also try to prepare a copy of our website and provide you with access for review. However, this will take some time to prepare, so I would be very happy if the video is enough for your investigation. I'll wait for your feedback. Thank you!
July 7, 2026 at 11:46 am #18145053
Christopher Amirian Supporter	Hi, Thank you for the video. I see that you use the Classic Translation Editor and I really need to know if the same thing happens on our installation or not. That will reveal many points that is not possible by just going on your installation. I will be happy to try to replicate the issue. Am I correct to assume that I need to add a Flexible content and then another flexible content nested to that? Or what do you suggest that I add to test. I will be happy to try to do it myself here: hidden link If you can give me the items that I need to add to test. Thanks.
July 7, 2026 at 1:44 pm #18145509
Philip	Hi Christopher, Yes, the issue happens with a nested ACF structure. The structure is: - Flexible Content: `glob_content` - inside it: `glob_content-col` - inside the left column: `glob_content-col-content-left` Inside `glob_content-col-content-left` we have blocks like: - `space` - `text` Steps to reproduce: 1. Open the original page in the default language 2. Inside the left nested flexible content, create this order: - Space - Text - Space 3. Create translations and add translated text 4. Go back to the original language 5. Insert a new `Space` block before the existing `Text` block 6. Save the original page 7. Check the translated pages on the frontend Expected result: - the translated text should remain attached to the `Text` block Actual result: - the translated layout updates, but the translated text is not re-mapped to the new nested row index - because of that, translated text disappears on the frontend in secondary languages Important: This is not only about reordering existing rows. It also happens when adding a new nested block before an already translated `Text` block in the original language. Thank you.
July 8, 2026 at 12:25 pm #18147137
Christopher Amirian Supporter	Thank you, I'd appreciate it if you could give me the URL/User/Pass of your WordPress dashboard after you make sure that you have a backup of your website. It is absolutely important that you give us a guarantee that you have a backup so if something happens you will have a point of restore. Make sure you set the next reply as private. I want to make sure I create the scenario as similar as possinle, also that will help me to know what is the translation option for the fields. Thank.
July 12, 2026 at 9:59 am #18153495
Christopher Amirian Supporter	Hello, and thank you for the login information. The issue seems to be happening only on the Classic Translation Editor. It works ok on the Advanced Translation Editor. I will report this to the second tier support. For the time being, the only workaround would be to use the Advanced Translation Editor. Thanks.
July 16, 2026 at 7:21 am #18161045
Christopher Amirian Supporter	Hello, We have confirmed that the issue occurs when using the Classic Translation Editor, and it has now been reported to our developers. However, the issue does not occur when using the Advanced Translation Editor. For now, we recommend using the Advanced Translation Editor to continue your work, as we do not have an estimated time of arrival (ETA) for a fix in the Classic Translation Editor. Thank you.
July 27, 2026 at 12:44 pm #18179347
Philip	Hi Christopher, Thank you very much for the update and for confirming the issue. We really appreciate you reporting it to your development team. I just wanted to ask whether you still need access to our staging environment, or if everything required for the investigation has already been collected. Our primary translation workflow actually relies on the Advanced Translation Editor, so we would still be very grateful if this issue could be fixed, as we'd like to avoid unexpected problems in the future. Do you have any rough estimate of when a fix might be available? Thank you again for your support!
July 27, 2026 at 2:48 pm #18179637
Christopher Amirian Supporter	Hi, Thanks, no need for the staging environment as the issue is already reported. Just to make sure we are on the same page, the Advanced Translation Editor works ok. The Classic Translation Editor has a lower priority for sure, I do not have any ETA for a fix that I can share. Thanks.