ACF fields are locked

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.

Sun	Mon	Tue	Wed	Thu	Fri	Sat
-	8:00 – 13:00	9:00 – 13:00	9:00 – 13:00	8:00 – 12:00	8:00 – 12:00	-
-	14:00 – 17:00	14:00 – 18:00	14:00 – 18:00	13:00 – 17:00	13:00 – 17:00	-

Supporter timezone: Europe/Zagreb (GMT+01:00)

Tagged: Compatibility

This topic contains 3 replies, has 0 voices.

Last updated by Bruno Kos 8 hours, 1 minute ago.

Assisted by: Bruno Kos.

Author	Posts
February 16, 2026 at 8:01 am #17824490
kasperG	It seems the ACF short codes are not working properly. They are not pulling the data. hidden link
February 16, 2026 at 10:28 am #17825183
Bruno Kos WPML Supporter since 12/2018 Languages: English (English ) German (Deutsch ) French (Français ) Timezone: Europe/Zagreb (GMT+01:00)	Hi, Before escalating this to our compatibility team, I’d like your help confirming the reproduction steps directly on our sandbox environment. On this sandbox hidden link I have already installed and activated Bricks Builder and Advanced Custom Fields Pro. Could you please check whether the issue can be reproduced there using the following steps, and confirm if these match your setup? 1. Only these plugins are active: * Bricks Builder * Advanced Custom Fields (Pro) * WPML Multilingual CMS (and String Translation) 2. An ACF field is created with: * Field type: Text * Field name: navn_pa_forhandler * Assigned to Pages (or the post type you are using) 3. In WPML → Settings → Custom Fields Translation, the field navn_pa_forhandler is set to Translate. 4. A page is created in the default language, edited with Bricks, a Text element is added, and the field is inserted via Dynamic Data → ACF Field → navn_pa_forhandler. 5. The page is translated using the WPML Translation Editor and viewed on the frontend. Could you please let me know: * Whether these steps are correct for your use case, and * Whether following them on the sandbox reproduces the issue? Once we can confirm this on the sandbox, I’ll escalate it with a clear reproduction case to our compatibility team. Thanks.
February 18, 2026 at 10:56 am #17831888
kasperG	Hi Bruno This a bit too much for me. I lost track of how to proceed. I guess I'll have to figure out another way to solve the issue.
February 19, 2026 at 9:03 am #17835052
Bruno Kos WPML Supporter since 12/2018 Languages: English (English ) German (Deutsch ) French (Français ) Timezone: Europe/Zagreb (GMT+01:00)	I understand - yes, this looks like a quite complex thing to reproduce in sandbox. That being said, I think it would be best if we try to debug this on your site. To help troubleshoot this issue more efficiently, I would like to use a tool called Duplicator (hidden link) to create a temporary diagnostic copy of the website. For this, I will need WordPress credentials as well. I marked your next reply as private so that you can safely add credentials. Using this tool, I will generate a lightweight “package” of the site that contains only the database and essential files. All media files (images, videos, etc.) will be excluded to keep the package small and secure. This package will be used only in a secure local testing environment to reproduce the problem and analyze it in detail. This allows me to test fixes safely without touching or impacting your live website in any way. Your production site will not be modified, slowed down, or affected during this process. You can find more information about this process here: https://wpml.org/faq/checklist-before-opening-a-ticket-in-wpml-support/#get-help-from-support Let me know if this is ok!