Dies ist das technische Support-Forum für WPML - das mehrsprachige WordPress-Plugin.

Mitlesen können alle, doch nur WPML-Kunden können hier Fragen veröffentlichen. Das WPML-Team beantwortet Anfragen im Forum an 6 Tagen pro Woche, 22 Stunden am Tag.

This topic contains 13 Antworten, has 4 Teilnehmer.

Last updated by timM-28 vor 1 Monat, 4 Wochen.

Assigned support staff: Carlos Rojas.

Autor Beiträge
Juli 31, 2019 um 2:20 pm #4315201

gunnarK-4

I have just taken over development of a web site using WPML in conjunction with a complex ACF setup. The setup includes flexible content layouts, repeaters and clones thereof.

The goal is to make translated pages completely independent from their original language versions: flexible content layout elements should ideally be copied once from the original page when the translated page is created, but after that it should be possible to add, edit and delete layout elements independently for each language version of a page.

I do not intend to translate the backend, so post type 'acf-field-group' is set to 'Not translatable' in WPML settings' 'Post Types Translations'.

The ACF setup looks roughly like this:

Page (field group)
- Sections (repeater)
-- Main Column (clone of flexible content in a different field group)
--- numerous flexible content layouts with a wide range of field types
-- Side Column (clone of flexible content in a different field group)
--- numerous flexible content layouts with a wide range of field types

What I have tried:

- Setting all relevant ACF fields to 'Copy once', except tabs, messages, columns* which I i set to 'Don't translate'. (*I'm using the plugin 'ACF Columns')

Result: None of the cloned fields are copied on creating the initial translation. The 'Copy content' button does nothing. On editing and saving the translation (adding and editing new flexible layout fields), the flexible content layout is copied from the original language version (without content if the fields that did not exist in the initial translation). Content in those newly copied fields can be edited and saved, but fields cannot be added or deleted - the layout of the flexible content stays synchronized to the original language version and cannot be changed.

- Setting all relevant ACF fields to 'Translate' (except tabs, messages, columns, see above)

Result: Same faulty behaviour as with 'Copy once'. In addition I get this warning after creating the initial translation: "WPML will copy _wpml_media_duplicate, _wpml_media_featured, sections_0_blocklist, sections_0_side_style, sections_0_side_background from German, when you save this post."
This is odd, as the mentioned fields - blocklist, side_style - are most definitely set to 'Translate', not 'Copy' in their field groups.

To further inspect this I did the following:

- Install 'WPML Translation Management' plugin to inspect all custom fields in one table (under WPML > Settings > Custom Fields Translation).

Result: I was shocked to discover over 1.700 custom fields in this table (see attached image), all indexed by nested repeater and flexible content fields (e.g 'sections_3_blocklist_2_items_0_content', up to 'sections_5...')! These fields have translation setting values assigned to them that don't reflect the corresponding settings in their field groups, e.g. 'Copy' or 'Don't translate'.

Questions:

- Why are field entries replicated in this way?
- Are they generated when saving a post? If yes, based on which translation settings - current field group values?
- Why don't their respective translation settings reflect the current values in their corresponding field group?

Solution (somewhat):

- Next I changed some of the assumingly relevant values here to 'Copy once' (such as the 'sections_0_blocklist' mentioned in the warning)

Result: This seemed to do the trick of making the layouts independent (editing, saving, deleting elements)! However, content and layouts are still not copied over on creation of a translation.

More questions:

- If this is the solution, how can I 'bulk edit' the field entries in the 'Custom Fields Translations' list - I don't want to edit >1.700 entries manually. Changing the original fields in the field groups doesn't seem to affect the iterations here!
- Is there any relevance to the system fields in this context? (Every field seems to have an underscore-prefixed equivalent set to 'Don't translate'.)
- What are recommended translation settings for flexible content and repeater fields to produce the intended behaviour (copy layouts and content once, edit, add, delete independently after that)
- What are recommended translation settings for clones, tabs, messages, and columns if backend and field groups are not translated? (Or do they simply not matter?)

Any assistance in producing the intended behaviour is welcome. Staging site and FTP access can be provided. The backend is unfortunately kept in German, but I can provide assistance via text or voice chat.

August 1, 2019 um 8:29 am #4319731

Bruno Kos
Supporter

Languages: Englisch (English )

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

Hi,

Thank you for contacting WPML support!

By trying to overly simplify things myself, can you tell me if you considered disabling WPML editor for this post or posts and then duplicating these pages, opening them by changing the language switcher and translating them independently?
https://wpml.org/documentation/translating-your-contents/displaying-untranslated-content-on-pages-in-secondary-languages/using-content-duplication/#convert-between-translation-and-duplicate

It would be expected for these fields to be set to "copy once" and if changing translation preferences in the custom field groups, it should work properly and update accordingly on the original page.

For example, if you have a flexible content field type, there may be only one instance within custom fields ( see images).

Regards,
Bruno Kos

August 1, 2019 um 10:25 am #4320547

gunnarK-4

Hi Bruno,

Thank you so much for your reply!

"duplicate pages first, then set to translate" - this is a good workaround which preserves the original layouts. I will suggest this workflow to the editorial team, thank you!

main fields and iterated sub-fields in the 'Custom Fields Translation' list - ok, I've checked the behaviour with two fields I could identify, and the iterated values are indeed updating according to the field group's translation settings. I am still confused by the amount of entries and that many of them are set to 'Don't translate', which should not occur in my current ACF setup. Is it possible that those entries are 'leftovers' from previous ACF configurations? Anyhow, I will observe and test this some more.

flexible content field - I'm still not sure what the 'correct' translation setting is for my Clone, Repeater, Flexible Content fields. I have set them to 'Copy Once' - is this correct for what I'm trying to achieve and the workflow you suggest? In your screenshot you have set the flexible content to 'Don't translate', but I assume this was just to demonstrate the value changing?

August 1, 2019 um 11:41 am #4321201

Bruno Kos
Supporter

Languages: Englisch (English )

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

Hi,

Is it possible that those entries are 'leftovers' from previous ACF configurations?

It is definitely possible. You can check this by trying to find any of these values - custom fields - within ACF field group interface. If they are not there, perhaps they were registered elsewhere, within the theme perhaps.

But I also think ( and am quite sure) that WordPress itself never deletes ACF fields assigned to some post or page, they stay within database until you remove the manually.

In your screenshot you have set the flexible content to 'Don't translate', but I assume this was just to demonstrate the value changing?

This is correct - I simply used it for demonstration purposes and to confirm on my localhost that this is working indeed. Copy-once sounds like something I would use myself.

Regards,
Bruno Kos

August 1, 2019 um 3:58 pm #4323683

gunnarK-4

Hi Bruno,

after more testing unfortunately my issue persists. I have realised that with the WPML translation management plugin I see the relevant ACF fields listed on the bottom of page editing screen as well, which helps to pin down the problem.

As you can see from attached screenshot #1, I have an iterated 'sections_N_blocklist' field for every 'section' I'm adding to the page. ('section' is a repeater, which contains 'main_modules', a clone of 'blocklist', which is a flexible content field from a different field group. All are set to 'Copy once' (screenshot #2 - #4)).

As you can see, 'sections_2_blocklist' is falsely set to 'Copy', while the previous ones are set to 'Copy once'. This seems to result in the faulty behaviour that I cannot add or delete elements in the corresponding blocklist, even after following your duplicate/translate workflow.

- How is bit even possible that the iterated values are different here?
- At what point are those values set/updated?
- And, f I go through the trouble of manually correcting the currently >1.700 acf-fields entries - will this guarantee me correct behaviour, or will the corrected values again be overwritten at some point?

(screenshot order might be reversed)

August 2, 2019 um 6:03 am #4327013

Bruno Kos
Supporter

Languages: Englisch (English )

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

Hi,

I must admit that I am bit confused by this screenshots. So if I see it properly, sections_x_blocklist are flexible fields. However, it is not showing that these indeed are flexible fields on the post page. Let me show you a screenshot how it looks on my installation.

This also brings me to another question - how were you able to add multiple main flexible rows in one page? Because from what I see, if I have a main element to be flexible field, then I cannot add multiple main flexible field rows into the single page, but only the instances within that flexible group, such as rows, etc.

There is one very quick way for you to toggle all 1700 though - it is about using Multilingual Tools Plugin, especially this part:

https://wpml.org/documentation/related-projects/wpml-compatibility-test-tools-plugin/#how-do-i-generate-language-configuration-files-using-multilingual-tools

So when you are on the configuration generator page, within custom fields section, you can toggle them all to "copy once" and in the bottom of the screen, you would have "Save to file" option. This will generate XML configuration file that would overwrite any other setting and which you copy-paste into this then:

https://wpml.org/documentation/support/language-configuration-files/#purpose

And you can put it into WPML -> settings -> custom XML configuration.

And then all the new fields you create (new instances of custom fields that will not be included into this XML file) should have the translation preferences you set on the field page. If you decide to do it this way, make sure you don't choose all of custom fields, because some of these may be related to perhaps WooCommerce (such as wp_attachment_metadata) or maybe theme settings or something else, but these should be listed on the beginning. You can remove them from XML file configuration code after it has been generated.

Regards,
Bruno Kos

August 2, 2019 um 7:11 am #4327319

gunnarK-4

Hi Bruno,

Thank you for pointing me to the Multilingual Tools Plugin, I will give this a shot right away.

As for your question regarding multiple flexible rows, my setup is actually:
'sections' (Repeater) > contains > 'main_modules' (Clone) > which is a clone of > 'blocklist' (Flexible Content).
Since 'blocklist' is contained within the 'sections' repeater, I can add multiple instances.

As for the missing field descriptions, I assume this is due to cloning: e.g. the field 'sections_0_side_style' in my screenshot is a clone as well and misses a description. In the screenshot (page editing screen) it is falsely set to 'Copy' as well.

Could we be onto a WPML bug here, where cloned fields do not inherit properties (description, translation settings) from their original field group instances? Could you perhaps try to reproduce this with your local setup?

August 2, 2019 um 8:02 am #4327855

Bruno Kos
Supporter

Languages: Englisch (English )

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

Hi,

Could we be onto a WPML bug here, where cloned fields do not inherit properties (description, translation settings) from their original field group instances?

How about we try checking this here?

Login: hidden link
Username: demo
Password: 0kxK3NenN1V0

This is a clean sandbox installation where I have installed all the plugins we need. May I suggest you do the following:
- create one field group with that setup ('sections' (Repeater) > contains > 'main_modules' (Clone) > which is a clone of > 'blocklist' (Flexible Content).)
- Configure WPML in the same way it is on your site (languages only, I suspect German is default?), we don't need to bother with any other settings

Try to spend as little as time as possible on this (don't import, but create anew). We don't need your theme or any of the content - we simply want to see how this will behave on a post for example, so we will not be interested in the front end output.

Could you let me know once you get there? Maybe this complex layout is not something ACFML would expect, so I'd like to exclude this possibility.

Regards,
Bruno Kos

August 2, 2019 um 3:24 pm #4331105

gunnarK-4

Hi Bruno,

I have created a minimal setup on your sandbox that resembles our ACF configuration. With this I have been able to recreate the unwanted behaviour 100%.

Steps taken + observations:

- I created a 'Page' field group with a 'Sections' repeater that contains a 'main_modules' clone of a 'blocklist' flexible content (from second field group 'Flexible Content'). All elements set to 'copy once'.

- Next I went to the page editing screen of 'Sample Page' and added flexible content elements. All added elements show up in the custom fields list below, but the cloned flexible content field 'sections_0_blocklist' lacks a description. (screenshot #1)

- Furthermore, if I now change the translation setting of 'blocklist' in the 'Flexible Content' field group (screenshot #2), 'sections_0_blocklist' on the page edit screen does not change setting! The other fields with description seem to carry over setting changes just fine.

- In addition, all fields within the flexible content clone have an empty 'Field's value in original language:' line, both in the duplicate and independent translation state. (screenshot #3)

Based on this and our conversation I assume this is all not correct behaviour and indeed an issue WPML has with cloned flexible content. If you happen to have a public bug tracker and you decide to verify and report this, I would appreciate a link to the bug ticket, so I'll know when this is fixed.

Thank you again!

August 5, 2019 um 12:22 pm #4340467

Carlos Rojas
Supporter

Languages: Englisch (English ) Spanisch (Español )

Timezone: America/Montevideo (GMT-03:00)

Hi,
My name is Carlos and I will be taking this ticket for now long because my colleague Bruno is on vacations.

1.- I have read the ticket and I'm still a little bit confused about the expected behavior because I can see the information of the custom fields in 'Sample Page' page in German are the same that in the translated page. Could you create a quick screencast where you reproduce the issue and point it out in the test site?

2.- I also noticed that the system fields related to the ACF are set to 'Not Translatable'. ACF consists of two custom fields, a regular one and a system field (system fields start with an underscore). I kindly ask you to follow this steps:
- Edit the 'Sample Page' in German -> Scroll down to the Multilingual Section -> Click on 'Show system fields' link -> Set the system fields to the same status as their correspondent regular ACF.

Could you tell me the result of the steps above?

Best regards,
Carlos

August 7, 2019 um 3:50 pm #4356589

gunnarK-4

Hi Carlos,

unfortunately I am on holiday as well until the end of next week, but...

1. 'information of the custom fields' - you mean the translation settings of the ACF fields listed on the page editing screen, correct?
The problem is not that the values differ between english and german, but that changes made to the flexible content fields' translation settings in the field groups are not carried over to the flexible content fields' translation settings displayed on the page editing screen.

2. Frankly, I have no idea what the system fields do (sorry!). Are you suggesting that they have to be set to the same values as the 'non-system' fields?

Thank you!

August 7, 2019 um 7:35 pm #4357793

Carlos Rojas
Supporter

Languages: Englisch (English ) Spanisch (Español )

Timezone: America/Montevideo (GMT-03:00)

Hi,

1.- Thank you for clarifying this for me.

2.- Yes, my suggestion is to set the system fields to the same status ('Copy', 'Translate', etc) as the regular custom fields and double check if the issue disappears.

Best regards,
Carlos

August 19, 2019 um 12:03 pm #4415751

gunnarK-4

Hi guys,

I'm back from holiday, pls excuse the delay.

I have tried Carlos' suggestion to change the system fields' setting on the demo site. (Frankly I have no idea what those system fields are or how they are used by WPML. There seems to be quite some confusion about this - a link to some in-depth docs would be helpful!)

This has not changed the faulty behaviour in any way: If I change the settings of the cloned 'blocklist' flexible content from 'Copy Once' to 'Copy' in the field group, the corresponding values on the WPML Settings and Page Edit screens are not updated! (screenshot #1).

In addition, values of the corresponding system fields are not affected by the changes at all. (Although this is probably expected behaviour)

Oktober 1, 2019 um 4:17 am #4668671

timM-28

We are running into the exact same problem here.

From what I can tell, once the autogenerated field settings from a nested flexible-content/repeater involving a cloned field (e.g. sections_1_blocklist) are created, they will remain set to the same value until manually changed i.e. updating the clone settings in the ACF Field Groups page will have no effect.

It seems that the only workaround is to manually update these and the system settings for each field, but is not a good workaround because a lot of fields are generated when using a complex nested ACF setup, CMS editors can't be expected to change the ACF translation settings for each new field they create while using a nested flexible-content/repeater.

@carlos do you know of any other workaround?