We will double-check the “Sticky Panel” ACF field group as you suggested.
After removing the block, we also noticed that the Page Translation mode started showing the translatable fields correctly.
However, during testing we created a new field inside an existing ACF field group, filled it with content on the original language, but WPML did not detect this new field inside the Page Translation interface.
Is there any process we need to run (a refresh, rescan, or re-index), or is this a known issue with WPML not detecting newly added ACF fields?
Another thing that concerns us is that in WPML → Settings → Custom Fields Translation, we do not see any ACF field groups related to blocks or option pages.
On our older projects these fields appear there normally, so this behaviour seems unusual.
Finally, we still haven’t received clarification on how WPML is meant to work with global ACF option page fields that should NOT be translated.
Fields such as social links, contact email, phone number, etc. must use the same value across all languages.
At the moment WPML expects each language to store its own copy of these fields, and the “Copy” setting does not seem to work for us.
Could you please advise on the correct setup or expected behaviour for non-translatable global option fields?
Thanks for your reply. I can see your page options here hidden link and are you saying that switching to English language here hidden link should display the same content as the Hebrwe language?
In the ACF field group settings we use Multilingual Setup → Expert, and for specific fields we explicitly set Translation preferences = Copy.
Our understanding is that fields marked as Copy should always reuse the original language value, regardless of which language is currently selected in the admin.
However, this is not what we are seeing.
On the options page – and also inside ACF block field groups – WPML still expects a separate set of values for each language, even though these fields are configured as Copy.
This behaviour contradicts the expected logic of the Copy setting.
Thanks for your patience. I’ve received feedback from our 2nd Tier Support, and here’s what they found.
The issue is caused by how the options page is registered in your file:
/wp-content/themes/wp-rock/inc/acf-setting.php
if ( function_exists( 'acf_add_options_page' ) ) {
acf_add_options_page( array(
'page_title' => 'Theme General Settings', // Title of the options page
'menu_title' => 'Theme Settings', // Text to appear in the menu
'menu_slug' => 'theme-general-settings', // Unique slug for the options page URL
'post_id' => 'theme-general-settings', // Unique identifier for the options page
'capability' => 'edit_posts', // Capability required to access this options page
'redirect' => false, // Do not redirect to the first submenu page
) );
}
To resolve the issue, you simply need to comment out the post_id parameter:
if ( function_exists( 'acf_add_options_page' ) ) {
acf_add_options_page( array(
'page_title' => 'Theme General Settings', // Title of the options page
'menu_title' => 'Theme Settings', // Text to appear in the menu
'menu_slug' => 'theme-general-settings', // Unique slug for the options page URL
//'post_id' => 'theme-general-settings', // Unique identifier for the options page
'capability' => 'edit_posts', // Capability required to access this options page
'redirect' => false, // Do not redirect to the first submenu page
) );
}
Once this is commented out, the problem should be resolved. Please keep this adjustment in place until ACFML 2.2.0 is released.
I’ve now thoroughly tested the setup and can confirm your recommendation was correct.
After removing the custom post_id from acf_add_options_page and switching the Options Page fields to Expert mode with all fields set to Copy, WPML started behaving as expected.
Once I opened the Theme Settings (Options Page) in each language and clicked Update (without changing any values), WPML initialized the options entity for that language. After that:
COPY fields are correctly locked (padlock icon visible)
Values are synced from the default language
get_fields('option') returns the expected data on all languages
Previously, when using a custom post_id, this behavior was not possible and WPML incorrectly expected separate option values per language.
So I can confirm the issue is fully resolved by removing the custom post_id and relying on the default ACF Options Page behavior.
However, we noticed one important limitation that still affects this workflow.
When a field marked as Copy is updated on the default language, the values stored in the database for other languages are not automatically updated. The other languages keep the previous value until the Options Page is manually opened and Update is clicked for each language.
From a data perspective, this means:
COPY fields are locked in the UI and visually indicate they are synced
but their stored values per language remain stale in the database
get_fields('option') on secondary languages continues to return the old value until a manual save is performed
With many languages (e.g. 15–20), this effectively requires manual re-saving the Options Page on every language after each change in the default language, which is not scalable and is functionally equivalent to the original problem we were trying to solve.
Could you please clarify:
whether this behavior is expected for ACF Options Pages with COPY fields, and
if there is an official or recommended way to force COPY fields on Options Pages to be re-synced across all languages automatically when the default language is saved?
Thanks for your reply. Yes, that’s exactly how the Translation Preference: Copy field works. Any changes made on the primary language options page will automatically be copied to the translated options page.
After you commented out the line
// 'post_id' => 'theme-general-settings',
in acf_add_options_page(), the behavior partially matches what you described:
Fields set to Translation Preference: Copy on non-primary languages do become read-only, and the tooltip correctly indicates that values are copied from the original language.
The UI shows the copied values from the primary language as expected.
However, there is an important data-level issue:
For testing, I added var_dump( get_fields('option') ); in footer.php.
On the Hebrew (primary) language, get_fields('option') returns the full array of option values.
On English, get_fields('option') returns bool(false) because no options row actually exists in the database for that language yet.
If I manually open the English options page in the admin and click Update, the data is then created, and get_fields('option') starts returning values.
The problem is what happens next:
If I change any Copy field on the Hebrew (primary) options page:
The English options do not update automatically.
English keeps the previously stored values.
To sync the changes, I must manually open the English options page and click Update again.
You can reproduce this yourself — it’s fully consistent.
So while the UI correctly shows fields as read-only, the actual option values on translated languages are not automatically kept in sync at the database level unless each language’s options page is explicitly updated.
With a multisite setup (10+ sites, each with 10+ languages), this is extremely inconvenient and not really scalable.
Could you please confirm whether this behavior is expected, or if there is a recommended way to ensure that Copy fields on ACF options pages are truly synchronized automatically without requiring manual updates per language?
Thanks for your reply. I can replicate the issue on our sandbox site, as shown in this screen recording hidden link . Please allow me to escalate this further to our 2nd Tier Support for further investigation.
