[Resolved] ACFML issue with nested Post Objects fields
This thread is resolved. Here is a description of the problem and solution.
Problem: You are trying to configure a repeater that includes a Post Object field in Advanced Custom Fields (ACF) and expect the selected entity ID in the main language to be automatically translated in the second language. However, after setting up and translating the entity, the 'Object' field in the repeater still shows the main language page instead of the translated page. Solution: This issue is recognized and has been escalated to our developers for a fix in future versions of ACF Multilingual. As a temporary workaround, we recommend changing the Return Format of the Post Object field from 'Post ID' to 'Post Object'. This adjustment has been tested and works on the front end, though it does not reflect in the editor, which is expected. Please note that this issue is not related to ACF's custom post-type feature.
If this solution does not resolve your issue, or if it seems outdated or irrelevant to your case, please check the related known issues and confirm that you have installed the latest versions of themes and plugins. If the problem persists, we highly recommend opening a new support ticket 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.
I am trying to configure a repeater that includes a Post Object field and have the selected entity ID in the main language be automatically translated in the second language.
Steps to reproduce:
1. declare a new entity type. Let's name it "Entities".
2. create a page in the main language ( EN ) and add a translation to the page in the second language ( DE ). Let's name them "Demo Page EN" and "Demo Page DE"
3. create a new field group in ACF associated with the "Entities" post type. Mark the field group to have same fields across languages. The first field should be a Post Object field with the name "Object top". The second field should be a repeater named "Objects" that contains a Post Object field named "Object".
4. create a new "Entity" post in EN and select the "Demo Page EN" in both "Object top" field and the "Object" field in the repeater.
5. translate the page in DE.
6. after updating the DE entity in the "Object" field in the repeater "Demo Page EN" is selected and in the "Object top" field the "Demo page DE" is selected.
This is expected. However, you should see the correct result on the front end if you do things correctly. We explain this situation in our ACF guide here.
Why is this to be expected? It's an inconsistency in how fields are handled. Top level Post Objects have the translated entity set as a value and nested Post Objects get the same values as on the original language ( ie: not the translated entity ) and can't be edited. This is confusing for editors
The links you provided are not applicable to my issue.
I'm sorry, as I might not have understood what you are trying to achieve. I know now that you need those fields to be unlocked to have the possibility to "translate" them. In your case, "translate" means inserting another object ID value in the field. I also understand that you see that what you call top-level Post Objects have the translated entity set as a value. But nested Post Objects get the same values as on the original language.
It seems that in your case, you need to work with the Advanced Custom Fields Multilingual plugin in the Expert mode. When working in the Expert mode, which is the legacy option, you can control the translation option of each field. And you can use the WordPress editor (not WPML's Translation Editor) for the pages with ACF fields. So, in your case, if you set those fields to "Translate," you should be able to insert the correct value of the nested Post Object fields. Please read about the Expert mode and the field translation options at the following links.
I am trying to use the Post Object field and have WPML automatically translate the entities IDs between languages. But it's not working when Post Object is a subfield of a repeater or flexible content.
I submitted this as a bug report and gave precise steps to reproduce, could you try as follow the steps?
WPML and its add-ons and ACF have many configurations. I'm afraid that following your steps would be in vain if I miss configurations set on your site. Therefore, I would be grateful if you could replicate the issue on a test site I created. I installed WPML on this site and configured it to have English as the default language and German as the second language (the same as on your site.) I also installed the ACF Pro plugin and our add-ons, Strings Translation and Advanced Custom Fields Multilingual, which are necessary when working with WPML and ACF.
Could you please help us replicate the problem on the test site?
You can access it through this link:
hidden link
With this link, you'll be directly logged in.
While replicating the issue on the test site, it would be great if you take a video of what you do and then share it with us. You can use an online service like Loom to take a screencast.
Thank you for taking the time to setup a sandbox environment. I have managed to recreate the issue I have been experiencing.
I created an EN entity: hidden link
and an DE entity: hidden link
I also made a short video of how i use the editor: hidden link
As you can see on the DE entity, in the "Main page" field the "Dummy page DE" is correctly configured. But in the "Pages" repeater the "Page" field is configured with the "Dummy page EN". This is not was I am expecting. I am expecting the "Page" field to be configured with "Dummy page DE".
Hi, and thanks for replicating the issue on the test site.
This is a known issue that has already been escalated to our developers and will be fixed in future versions of ACF Multilingual.
As a workaround, you can switch to Post Object instead of Post ID in the Return Format of the field. Please see the attached screenshot. I tried it on the test site, and it works. Please note that it works on the front end and not on the editor. This is expected and what matters. Please also note that ACF's custom post-type feature has nothing to do with this issue. I set the field group to show on regular posts, but the problem persists.
I'll keep you updated here when the version with the fix is released.
