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.

Hi, Amit here, I am the WPML Support Manager, please make sure you are using the latest WPML 4.3.14 before reporting an issue, thanks!

Please look at our updated list of Known Issues and you can also use our support search to find helpful information and of course review our documentation before opening a ticket.

If you do need to open a ticket please make sure to provide us with all the needed information as described in this page

This topic contains 41 replies, has 2 voices.

Last updated by fernandoG-11 9 hours, 24 minutes ago.

Assigned support staff: Alejandro.

Author Posts
March 29, 2020 at 11:52 pm #5790199


Hello, I have been waiting for a response on two escalated tickets:

Staff have not responded to either one of them in some time. Can you let me know an estimated wait time please?

March 30, 2020 at 7:22 am #5791443


Languages: English (English ) Spanish (Español ) Italian (Italiano )

Timezone: Europe/Rome (GMT+02:00)


We are still waiting on an answer about the ticket related to the transifex related question.

About the ACF question instead, i just saw that the version that was newly released ( 1.6.x )is supposed to fix the problem, you then mention the following:

" The inserted content still appears in blank content spaces, and the translation pairs in the backend are all set to untranslated status, and jumled in some (but not all) cases"

Could you please let me know what you mean by this? because the initial issue was that the content appear as untranslated everytime, so, could you please update to version 1.6.1 and then try to create a clone of the page that is giving you this issue and replicate the problem there if possible.

I'm asking you this because it is possible that this problem is happening only on one page (maybe there is database content missing or corrupted).

At the same time i ask you to please post here both the results and if possible list the steps here so i can try to replicate the issue on a local environment.


April 3, 2020 at 5:57 am #5828907


Hi Alejandro, thanks for the update on Transifex!

From your characterisation of the ACFML problem I think you have not fully understood the problem - it's a complicated issue to explain, it makes much more sense when you see it!

Basically the issue is not only that the fields appear untranslated in the backend, but also that translations are shifted down on the live page without any confirmation of the change. So modifying the English source page causes all translated pages to shift content around and display translations in the wrong place, as well as untranslating and shifting around existing confirmed transactions in the backend. I already set up a demonstration of the problem on your infrastructure, do you have access to this? Can you try updating to ACFML 1.6.1 there and see it for yourself?

hidden link
hidden link

It doesn't load for me anymore, hope you guys didn't delete my work before resolving the bug...

Do you want to continue working on this ticket or switch back to the original ticket?

April 3, 2020 at 10:39 am #5830815


Languages: English (English ) Spanish (Español ) Italian (Italiano )

Timezone: Europe/Rome (GMT+02:00)

Hi fernando, that link you sent is an old sandbox, they got deleted after 7 days of inactivity but we only use them so we can replicate the issue.

I believe that there is work to be done on your site in order for this to work correctly.

I read the old ticket, so no problem, we can continue over here.

Would you please allow me access to your site and just set the custom fields that you mentioned on your other ticket in a test page, so i can check its configuration.

If possible just clone the field group and assign them to a post/page, that way all the changes will not affect your actual live/staging sites and will allow me to test them.

The problem with this fix is that it will prevent the issue from returning but maybe the configuration needs to be set correctly and as you mention, this is not an easy task (plus we made a few changes to make the entire more secure from now on). i'm willing to give it a try if you give me access and kindly do whay i suggest above.

I enabled the fields for the credentials so you can add them there without privacy or security issues.


April 6, 2020 at 3:54 pm #5850571


Languages: English (English ) Spanish (Español ) Italian (Italiano )

Timezone: Europe/Rome (GMT+02:00)

Ok, you can check this video to know what you should do: hidden link

Now, the problem here is that the site seems to not be configured correctly, as i suspected.

So i suggest you follow these steps (also mentioned in the video and explained in detail)

1) Delete the field groups in all the other languages
2) Correctly set up the different fields inside each field group as explained here:

(CheatSheet: Elements that will have different content through the languages should be set to TRANSLATE. Elements that will be the same or that are part of the "Layout" type of ACF, should be set to COPY)

3) Go to WPML > Settings > Post type translation > set "Field Groups" to "Not translatable"
4) Check your options page and make sure the options are setup correctly and then mass-edit and mass press "update" button in the pages that contain the ACF

5) If step 4 doesn't work, then find the pages that had issues and try to add a character to the title + save the page (to force an update on the translation) and retranslate the page

That should do it. It's quite a bit of work since you have a complex configuration there, so please backup your site first and maybe create separate backups for each step mentioned above. i know it could take some time but you'd be greatly decreasing the chance of losing anything important.

<note>I suspect there is a high chance of information getting lost between the languages because the configuration was very mixed up so try to create a cheatsheet for yourself where you can just re-add all the information in all the languages without too much hassle if you do lose information</note>


April 8, 2020 at 12:40 am #5861381


Wow, thanks for the detailed video! Top quality support there 🙂

The reason I started duplicating the field groups was because the repeaters were not being rendered in the frontend, I would simply get a blank content area until I duplicated the field group for that language I was trying to display. I got a response from Itamar relating to the menu which actually recommended duplicating these field groups for each language - before I try your 5 step cleanup process, can you clarify for me in which cases the duplicate is actually required? I think that is where I went wrong, duplicating too many field groups to workaround the display problem when in fact I should have been following the method you recommend in your video.

Here is Itamar's response recommending duplicating field groups:

Thanks again, looking forward to giving this a try and hopefully simplifying our setup!

April 8, 2020 at 5:58 am #5862671


Hi Alejandro,

I followed your steps closely on our testing site and had decent success. The issue with the content disappearing occured again, however this time I was able to resolve it on simple pages (like Providers & Tools, let's take Greek as an example) with the following steps:

1. Delete non-English duplicate field groups
2. Configure English field groups according to your instructions
3. Change WPML Field Groups setting to "Not translatable"
4. Edit all pages in English
----> Page does not display in Greek
5. Update Greek translation
----> Page does not display in Greek
6. Edit page in English by changing the title
----> Page does not display in Greek
7. Edit page in English, then change language to Greek in top bar and click "Update"
----> Page displays correctly

This process is annoying but manageable if it only needs to be done once. However, it does not work on a page template which contains custom post types, such as the "Downloads" page. This content now does not display even if I follow the procedure above.

In addition, the top and footer menu is now also not rendered in any language except English. Itamar recommended fixing this by duplicating field groups (see my previous message) and modifying the translations in the "Options" section, how should I handle this now?

Thanks and cheers!

April 8, 2020 at 8:55 am #5864025


Languages: English (English ) Spanish (Español ) Italian (Italiano )

Timezone: Europe/Rome (GMT+02:00)

Hi there, i read Itamar's request and i understand what he means, however, what he mentiones actually changed exactly because it created way more issues than it solved.

Right now i don't think that you need to duplicate the Field group, however, i'd like to take a look at how you created your header and footer before i can give you a proper answer.

Would you kindly give me a hint on where to find the Footer and the header on both the options of your theme (or pages) and what is the download NOT showing specifically? (or well, how is it supposed to work)

I'll then take a look at it, investigate and let you know how it goes.

April 8, 2020 at 11:07 pm #5870137


Sure, happy to provide details. We can see both problems on the downloads page, taking Italian as an example. You can see what it should look like on the live site: hidden link (downloads-good.png) This screenshot of the live site is currently built from the configuration based on Itamar's instructions, i.e. with language duplicates of the field groups.

The staging-www2019 website is now configured according to your instructions, with properly configured field groups and no duplicates. You can see this example at hidden link (downloads-bad.png) Note that the repeaters from the custom posts do not render, and my workaround posted in my previous message also does not work.

The menu is managed using the ACF "Options" menu item in WordPress, i.e. hidden link

Previously I duplicated the "Global Naviation" field group, then managed a separate Options page for each language by changing the language in the top bar. Changes to the English menu did not propagate to other languages. This was tedious and annoying, so I'm really hoping we can get this working without duplicates!

The menu for the header is rendered in linex 94-138 of header.php, with line 95 doing the important part of fetching the rows, where things are likely going wrong. The footer is rendered in lines 23-44 of footer.php, with line 23 fetching the data.

April 10, 2020 at 12:41 pm #5884009


Languages: English (English ) Spanish (Español ) Italian (Italiano )

Timezone: Europe/Rome (GMT+02:00)

Hi there. sorry for the delay on this. i'm trying to not only check this page but write and remember the rest of the configuration so i can give you a better answer.

I'll come back as soon as i have all the info i need. if i make any test, i'll put everything back as it was before and i'll try to not do anything that could affect the front-end for longer than 1 minute.

April 12, 2020 at 3:49 am #5891093


You can go ahead and make a mess on that server, don't worry about the front end. This server is cloned from our actual build server, and I can easily clone it again if we break something.

April 13, 2020 at 1:12 pm #5896489


Languages: English (English ) Spanish (Español ) Italian (Italiano )

Timezone: Europe/Rome (GMT+02:00)

You can check this video now: hidden link

The problem was that you had a few repeaters that had its system custom field set as "do not translate".

I also noticed by checking the code on the template that the "options" page had nothing to do with this situation, it was only the system field issue of the repeaters. they should be set to "copy" when things like this happen (fields that don't appear in the translations) and usually only needs to be checked for system fields, so the rest can be left untouched.

I hav already fixed it for 2 of the wallets, and if the same repeaters are used in the other wallets, then you just need to update them by adding a small change in the title or body (anywhere except on custom fields) and then update all its translations.

That should do it.


April 14, 2020 at 12:34 am #5899405


Hi Alejandro, thanks again for another detailed video!

Regarding the system fields, I don't entirely understand what these do or why WPML does not just set this to "Copy" automatically. But I will attempt to correct these where I see it not set to Copy. I was also not aware that we need to wait for the green bar to appear at the top of the Multilingual Content Setup, since the "Update" button is far down the page you could improve the UX by adding a spinner and the status confirmation in the same location as the button. It's not obvious that the status confirmation will appear in a different location to the action button.

For the other issues, I've recorded a video for you this time, and I will walk through the issues here in text as well: hidden link

Relating to translating the Options field, this is used to create the header and footer menu. Note that the top menu does not appear if the custom fields are not duplicated for each language. I marked this in my screenshots sent on April 8, and discussed with Itamar here:

In your video at 8:30 you confirmed a few translations which actually relate to the initial bug I was trying to fix in this thread before Jamal stopped responding:

I think this behaviour changed in ACFML 1.6.x, so now changing the order of repeater fields does not shift the translations around in the frontend. However, the problem remains in the backend. The translations appear in the wrong location and are marked untranslated, even though the translation is complete. If I add a repeater in the middle of an existing repeater, the translation is shifted down and data is lost.

Like you mentioned at the end of the video, the website template was designed by an agency, and they did not consider which translation plugin would be used (or anything else relating to translation). So WPML was added later by me once we received the template, and ACFML was added even later. Itamar also gave me some conflicting information previously before ACFML was updated, and we have messed around a lot with ACFML config, so all of this has contributed to the messy and complex configuration. I really hope we can get this resolved now that the plugin code seems to have been patched for all the issues I was experiencing 🙂

Cheers and thanks again for the support!

April 14, 2020 at 11:56 am #5903785


Languages: English (English ) Spanish (Español ) Italian (Italiano )

Timezone: Europe/Rome (GMT+02:00)

It seems this is a new bug and i already sent it to our ACF compatibility developer for a check and a fix.

He provided me a workaround in the meantime, so you don't have to stop working on your site.

- Use the global options Field group not as an options page but assigned to a new page that you would create.

- Configure there the same options you have setup in the options page and then translate the page

Then assign that page to the header using this code:


get_field( ' some field name', 'options')

to this:

get_field( ' some field name',  apply_filters( 'wpml_object_id', XX, 'page_page' ) )

Where "XX" is the original page ID.

Try it and let me know if it works.

April 14, 2020 at 11:58 pm #5908465


Hi Alejandro, ok, let's work through the Options field translations before we deal with the field re-ordering issue.

I have created a new page called "Menu" (ID: 47431) and modified the "Global Navigation" field group location rule to also use the field group on that page. I recreated the menu and translated it to German. Only the text fields appeared, the `nav_item_list` did not appear since this is set to field type "Relational". Since this specifies the actual content and order of the pages in the menu, this seems correct since it should apply the menu content and order from the English menu to translated menus. The content of the translated menus should fetch page titles from the respective translated page title fields using `get_the_title($navpost->ID)`.

I could not figure out how to change the header and footer theme templates since we do not use `get_field()` like you provided in your example, and `get_sub_field()` cannot accept a `$post_id` like you use in your example. I also couldn't figure out how the `wpml_object_id` filter works on ACF subfields (i.e. repeater child fields). The code to create the menu is on lines 95-120 of header.php, as follows:

<div class="navbar-container">
	<?php while( have_rows('navigation_main',$homeid) ): the_row();
		$navposts = get_sub_field('nav_item_list');
	<div class="navbar-item">
		<div class="link">
			<a href="<?php echo get_permalink($navposts[0])?>">
				<?php echo get_sub_field('nav_item_title'); ?>
			<p class="tagline d-lg-none">
				<?php echo get_sub_field('nav_tagline'); ?>
		<?php if (count($navposts)>1){?>
			<div class="dropdown">
				$idx = 0;
				foreach( $navposts as $navpost):?>
					<div class="link <?php echo ($idx==0?'first d-lg-none':'') ?>">
						<a href="<?php echo get_the_permalink($navpost->ID) ?>"><?php echo get_the_title($navpost->ID)?></a>
				<?php $idx++; endforeach; ?>
		<?php }?>
	<?php endwhile; ?>
	<div class="navbar-item lang">
		<!--WPML language selector code omitted-->

How should I modify this to work using your workaround?