I have a problem with one of my customer's websites. After a translation of a post (product) is made, the some of the ACF fields are locked for editing, greyed out.
Thanks for the update. I enabled the private box for you so that you can securely share the access. Please make sure to take a full backup of your site including the Database.
I have checked but couldn't be able to locate the fields under "Tab-secties" field. The Field-Type of Tab-secties field is set to "Clone", which means the fields inside this specific field are cloned from somewhere. Can you please let me know where those fields are located? so that I can check the configuration and let you know an update soon.
These fields are located under the "Generic Fields" group that is set to invisible, since this group contains all the fields that are used on multiple locations. Hence the clones.
Hello There,
I hope you're doing fine and apologize for the delay in getting back to you.
Usually, a field will appear disabled if the translation preference for that field is set to "copy". The field value will be synchronized across the languages, and for that reason, that field will be disabled. So, as the first step, I changed the translation preference for the fields and field group to "Translate" but unfortunately, that does solve the issue.
But, I investigated the issue thoroughly and found that the fields appear disabled only in the posts under the product post type. I figured that out by creating a new page(hidden link) and assigning the Fields to that page. On the page, the fields appear correctly in other languages even after completing the translation.
I also noticed several adjustments for the ACF fields inside the custom theme that you're using. So, maybe these adjustments caused the issue for the posts under the product post type? Could you please verify if any modifications have been made to the ACF fields inside the code for the Product post type? If you've adjusted the translation preference of those fields programmatically, then make sure to set the `wpml_cf_preferences` value to 2 or 3.
It is also recommended to check on a default theme like twenty-twentyone. It will help you to understand if the current theme is responsible for the problem or not.
As custom code inspection or support for the custom theme/plugin is outside the scope of our support, we only can instruct you on what to check. I hope you can understand the matter.
Let me know your findings. I will be happy to help you if you need further assistance in this matter.
Thanks for your research and your reply on the matter. I understand reviewing custom code is outside of your scope. The strange thing is, until recently everything used to work without problems, and I haven't made any significant updates recently. It seems the client started having issues after an update of WPML or something.
The custom fields are not declared or manipulated in the code in any way.
The only thing we need really is maintain control over all fields for all languages, and be able to change the information in them as needed. I don't understand why this needs be to synced/disabled by the plugin? It's kinda frustrating WPML makes this so complicated to use.
I restored the settings on some of the flexible content fields that were set to "translate" by you, sincde it breaks the content. As far as I know a flexible content field shouldn't be set to "translate" but to "copy once".
Hello There,
I hope you're doing well. Sorry for the delay in getting back to you.
I completely can understand your frustration. We will try our best to sort things out for you.
The translation preference for the Flexible fields should be set to "Copy Once". I was checking in different scenarios and that's why I changed the preference. Sorry for any inconvenience you had due to this.
Since your site is already live, it would not be a good idea to continue debugging there. Would you kindly create a duplicator package for us so that I can set it up on my development environment and continue the debugging? If you allow me, I can create the duplicator package as well.
Turns out the customer had a disk space problem, causing WPML to behave in a strange matter. After this was solved, I could just uncheck the option "Synchronise flexible content fields" in the original language of the product, and this caused the fields in other languages to became editable.
It seems like the problem is solved now.
Thank you for your time and efforts!
This ticket is now closed. If you're a WPML client and need related help, please open a new support ticket.
