search

BeAPI / acf-options-for-polylang

A WordPress plugin for adding ACF options page support for Polylang.
https://wordpress.org/plugins/acf-options-for-polylang/
Other
166 stars 28 forks source link

Problem with languages with suffixes (ex. de_DE_formal) or single-word (ex. af) #50

Open constip opened 5 years ago

constip commented 5 years ago

We have noticed that Options are not properly retrieved in certain languages and I am confident I have narrowed it down to this line:

$_post_id = preg_replace( '/(_[a-z]{2}_[A-Z]{2})/', '', $post_id ); in classes/main.php#61 BEA\ACF_Options_For_Polylang\Main::get_default_reference

Updating the regex to sprintf( '/(_%s)/', pll_current_language( 'locale' ) ) should do the trick. This properly removes the current language, however it also means that the default can only be reached from the current language which might not be ideal...

constip commented 5 years ago

Alternatively it might be a good idea to prefix the languages. Ex.: options_de_DE becomes options__bea_de_DE. This way it can easily be matched by __bea_.+ without risking wrong matches.

MaximeCulea commented 5 years ago

Hi @constip, thx for the issue.

To answer your both remarks :

  1. I am not sure that the post_id (containing also the lang code) and the potential current language are matching. To be sure, we match everything except lang codes, as in the following regex.
  2. The plugin don't prefix saved options in DB because it is just a "connector" between Polylang and ACF for the options. It is done the same way it could be done in post metas, etc.

Finally, to to be sure, are you facing any bug ?

constip commented 5 years ago

@MaximeCulea yes. The problem is I use the language de_DE_formal (but there would also be the same problem with many other languages, ex. af). Since your regex (the one you have linked again) only matches some languages, the language is not correctly removed. So in my example I get options_formal. This is a problem when getting the defaults and this has messed up my site. That is why I opened this ticket.

I have only tested this with options-pages but my first solution seemed to work there...

saulirajala commented 2 years ago

Hi

I realize this is quite old issue, but especially concerning the latest updates in ACF, this is still relevant.

ACF 5.11.2 introduced the following change: _"get_field() and thefield() functions now are only able to access site options which are ACF fields"

This causes problems with languages that doesn't follow the standard language_COUNTRY -convention in locale. For example in our case Finnish locale is just fi and the regex doesn't work for that. Thus ACF doesn't recognise that get_field() call is for valid acf-field and returns null.

For example we have one site with three languages (fi, sv_SE and enGB). Also we have set the data only in …&lang=all -page. So the fields in …&lang=fi, …&lang=sv and …&lang=en_ -pages are empty. get_field( 'option_name', 'options' ) returns data in _svSE and _enGB languages, but not for fi. We fixed the issue by saving the fi-options with empty values. Thus ACF will save option keys to the database and after that accept that get_field( 'option_name', 'options' ) is valid request for valid acf-field and returns the value.

Even though the fix was quite easy in our case, I think this bug should be fixed in the plugin. It can cause problems in the future, since the regex is so selective for the format of locale. Polylang has the list of different locales, so maybe you can use that one instead of preg_replace( '/(_[a-z]{2}_[A-Z]{2})/', '', $post_id ) 🤔