We're experiencing an unusual problem on one of our sites and we believe it has something to do with either the WPML translation plugin or Advanced Custom Fields. We thought the issue was a result of updates to the plugins and conflicts within those updates, but the results we are getting are inconsistent.
First, when we are editing a page in the WordPress admin, we noticed that the ACF field groups are being duplicated and there is one for each language we have translated. But, we’re editing the English version of the page if you look at the URL. See attached screenshots. Right now, the live site is problematic, and our development site does not have this issue. However, we did not notice this issue on the live site when we first updated the plugins. It seemed to surface later this week. It is worth noting that the live site is up-to-date in terms of plugins and WordPress version.
Secondly, if we make a change to a template where this issue is happening and publish, the page goes blank on the front end. We assume that the site doesn’t know which field group to pull, so it does not pull any of the languages.
Any help would be greatly appreciated. Please let us know if you need any further details. Thanks in advance.
Welcome to the WPML support forum. My name is Nicolas and I will be happy to help you today.
Could you please give me more details about the issue. In particular, how did you move from Dev to Prod? Did you export/import the fields? or did you clone/migrate the entire site?
Let's start by making sure that translation preferences are correctly set up for your fields.
First, in "WPML > Settings > Post Types Translation" the translation preference for "acf-field-group" should be "Not translatable".
- Now when you edit in your group in the default language, this is where you determine the translation preference for each field. Here we are talking about the translation of the field value. "ACF > Field groups"
My recommendations are:
- "Copy once" for special fields like "Repeater" and "Flexible"
- "Translate" for all the fields you want to translate such as texts, WYSIWYG etc...
- Use "Copy" if you don't want to translate the field but keep the same value, for example for colors, true/false, images etc...
Important: only set the "repeater" field as "copy once", all subfields should either be set as "translate" or "copy".
- Check also the "Locations rules" conditions for the group field.
The issue seems to happen around plugin and WordPress updates. We systematically carry out the updates on our dev site, then test, and then we follow the same process on our live site. We test for these types of bugs because they have occurred in the past. We do not push the changes because the testing can take some time and we do not want to overwrite any content changes that may have occurred because it is a very dynamic site.
We do however, copy the live environment to the development environment before we make plugin updates to make sure they are in sync before we start. One of our checklist items is to make sure the afc field groups are not displaying this behavior. When we updated our site to the most current state, we do not recall this being a problem.
I see that "acf-field-group" was set to "Translatable"(fallback to default). So if I understand you correctly, if this is set to "Not Translatable", I should not see a multiple instances of the field group when I am editing a post. Is that accurate?
I changed the setting to "Not Translatable", but I am still able to see four instances of several field groups when I edit the posts. Is this because those field groups have to be removed? I'm assuming these groups still need to exist for each language because of what I noticed below.
I also noticed that there seems to be an issue with filtering these languages on the live vs. development sites. See attached screenshots. If you look at the Dev example, the only field group that is showing is the English version by default. If the flag at the top of the screen is changed to another language, we see the other field groups, but there are also options to view all groups. However, on the live site, even if I am editing the English version of the site, I can see ALL field groups with no option to only view the field group that relates to my current language. This is similar to what is happening when I am editing a post or a page on the live site, which makes me think there is a bug in addition to possible field configuration problems.
Lastly, I did notice that several of the "Repeater" and "Flexible Content" fields were set to "Copy" Instead of "Copy Once", with the exception of one being set to "Translate". But what I don't understand is why my problem exists on the live site, and not the development environment. Again, because the dev site is based off of a working copy of the live site.
I hope this all makes sense. Thank you again for all of your support. Please let me know if there is anything that needs more clarification.
When you set your ACF Field Groups (acf-field-group) as "Translatable" you will have the filter options at the top to switch from one language to another.
So you can have Groups in English, Chinese, Japanese...
Now, if after that you switch back to "Not translatable" all fields will be then considered as in "Default language" and the filters will disappear.
That's why you have the same amount of total groups (68) but now you can see them all in English. That's why you have 4 times the "Banner options" group, because you probably translate it in all 4 languages.
You should delete extra groups (from previous translations) and keep only the English ones.
Thank you for the clarification. We went ahead and removed all of the Field Groups that were not English, and we updated the English Field Groups so that the "Repeater" and "Flexible" fields are set to "Copy Once". This seemed to help, however, we lost both our Header and Footer Menus on the translated pages. As far as we can tell, this is the only issue. All of the translations appear to be in tact on their appropriate pages.
We found WP Menus Sync in the Admin and for some reason, it seems to be stuck at about 75% (300 out of about 420 records). Also, when we switch to the translated pages, we are getting a menu with several several child/second-level links exposed. So it appears to be breaking the styles. See attached screenshot.
Aside from the menu problem, we were successfully able to make an update to one of the pages. As I mentioned before, updates were causing the updated pages to go blank.
One thing to add is that our development site is password protected to prevent bot traffic from indexing it. We noticed a few things that indicated the plugin cannot connect to the WPML server on the dev site. Also, in WPML > Support, REST is not enabled in the WordPress section, probably due to this password protection. Not sure if this can contribute to the problems we are having, but we thought it was worth mentioning.
We've rolled back the live site to a version from this morning, prior to all of the updates mentioned above. We did not want to leave the site up with errors in the menus. Could you please let us know the best way to address this problem? Thanks again.
New threads created by Nicolas V. and linked to this one are listed below:
Keeping one issue by forum threat helps to keep the forum clean and organized, it will also help other users with similar problems to find solutions when searching the forum.
