[Resolved] ACF options pages

Hello,

our developers checked the issue, and find a workaround fix for your case that you can use for now:

- go to wp-content/plugins/acfml/classes/class-wpml-acf-options-page.php

add condition:

			&& $post_id !== $cl

so that the code becomes:

	public function append_language_code_for_option_pages( $post_id ) {
		$cl = acf_get_setting('current_language');

		if ( is_string( $post_id )
			&& $post_id != $cl		//add this here!!!
			&& ! $this->id_starts_with_options( $post_id )
			&& ! $this->id_ends_with_language_code( $post_id, $cl )
			&& ! $this->is_term_id( $post_id )
			&& ! $this->is_taxonomy_name( $post_id )
			&& ! $this->is_block_id( $post_id )
			&& ! $this->id_starts_with_user( $post_id )
		) {
			$dl = acf_get_setting('default_language');

Since you are using a bit different usage case for ACF options and for showing field value, that is not excepted by default by ACF, it could be a custom code case that we cant support or charactirize as a bug from our side.

Our developers are still checking on this. I will let you know when I have more info on this.

Let me know if this fix works for you.

Thanks,
Drazen

Hello Jean-François,

thanks for getting back.

1) I am sharing our developers explanation, if you have any other doubts or questions let me know and I will check it out with them:

Before 1.9 it was possible to translate option pages (by switching language on top menu bar) but only if the options page was registered with standard id 'options' (or without id, then ACF automatically added 'options' id). but if any user wanted to use custom options page id, say 'layout_options' it was not translatable.

I assume the user wanted to make it working on his own and this is why he registered options pages this way.

With 1.9 we've added support for the last case. Now the user doesn't have to register separate option pages for each language: he should register only one with any page id (but not equal to language code*) and translate by switch the top menu bar.

In the code we are checking the last two letters of the page id are equal to the language code and I think here is the conflict: in the case of the options page with id 'en' the last two letters are 'en'.

The client could change this to:

'post_id'    => $lang["language_code"] . '_foo_or_something',

to not have post id ending with language code.

For now, we won't be adding any changes from our side or support this user case-reported issues.

I hope you will understand and this will be helpful for you.

2) Thanks for sharing your solution, I am sure it would be helpful for other users if they encounter the same problem.

Let me check on this with our developers and I will get back to you with an update.

Thanks,
Drazen