Support

Account

Register Login

Home › Forums › Search › Search Results for 'WPML'

Search Results for 'WPML'

reply

  • Just tagging along. I’m also curious on ways to translate ‘select’ Field Type properly.

    edit: I’ve resolved my issue, let’s see if it can help with yours. First let’s see if I understand properly what you want to do. You have a site where posts are a person’s profile. One of the ACF field for the post is their eye color. Your main language is Dutch, second English.

    You want people/user to create a post in Dutch, add a Title/name and Content/description, then select eye color. You want the user to then create the translation in english, translate the name and description, but have the selected eye color sync. You want the labels for the eye color translated.

    Here is how I made it work for me.
    (ps. all ACF group fields created before WPML install are buggy AFAIK, create new ones)

    Create a new ACF group field in dutch with a ‘select’ field for the eye color (eye_color) with such value:
    blue : blauw
    brown : bruin

    Create translation in english using duplicate. Make separate. Keep Field name but edit ‘select’ values to:
    blue : blue
    brown : brown

    Create a new post. add Dutch content. Publish. In ‘Multilingual Content Setup’ set ‘eye_color’ to Copy. Save. Update.

    Create English translation using Duplicate. Make separate. Edit Title/name and Content/description to English text. Eye color label should be in english, and frontend should display correct value in english.
    I use this code to display the label :
    $field = get_field_object('eye_color'); $value = $field['value']; $label = $field['choices'][ $value ]; echo $label;

    Bugs: Editing the eye_color field in the English post doesn’t work. Modifications needs to be done in the original language. If this feature can’t be added, field should greyed out imo.

    Let me know if that helps you.

  • I think there’s an error in andreu’s post and I found 2 sulutions to this case.

    For example, we have a page in English with id 1 and it’s translation to Spanish with id 2. And we have an ACF field group with a rule to match id 1

    Andreu’s first code compares current page ID translated to current language of backend/frontend and the ID. If the user is viewing the translated page (ID=2), the function still returns 2 and the match is 2!=1, but that’s not what we want.

    The first solution is to use WPML function to get ID not for the current language, but for the default language, that the match is set in (note that icl_object_id function is now considered deprecated in WPML):

    global $sitepress;
//get the default language code
$default_lang = $sitepress->get_default_language();

/* icl_object is deprecated in WPML, but I leave it here as an example:
$translated_id = icl_object_id($options['post_id'],'page',true, $default_lang);*/ 

// Proper way to do it now:
$translated_id = apply_filters( 'wpml_object_id', $options['post_id'], 'page', true, $default_lang);//add defualt lang parameter

    The second and better, IMO, solution is to translate the ID to match instead:

    //WPML support to page rule with ACF 5
add_filter( 'acf/location/rule_match/page', 'rule_match_post_wpml', 10, 3 );
function rule_match_post_wpml( $match, $rule, $options ) {

	// vars
	$post_id = $options['post_id'];
	$trans_id =  apply_filters( 'wpml_object_id', $rule['value'], 'page', true);

	// validation
	if( !$post_id ) {
		return false;
	}

	// compare
	if( $rule['operator'] == "==") {

		$match = ( $post_id == $trans_id );  

	} elseif( $rule['operator'] == "!=") {

		$match = ( $post_id != $trans_id );  

	}

	// return
	return $match;
}

  • Ok, I now know why it happened.

    I created my website, with an ACF front-end form.
    For it I created an ACF group.

    I now installed WPML, created a translated page for the form and I copied the group I made before (I didn’t translate it as stated before).

    If I now edit that specific post type in the admin, I have 2 ACF groups, 1 for each language. And I edited in the first one, because the group is so big, I didn’t see there was another one beneath it.

    So now I’m thinking I do need to translate the form(s). Is that correct ?

  • Figured it out. WPGEODIR is really stupidly coded.

    Add this to functions to fix it

    function override_the_stupid_plugin_filters($query) {
    global $wp_query, $wpdb, $geodir_post_type, $table, $dist, $mylat, $mylon, $s, $snear, $s, $s_A, $s_SA;

    // fix woocommerce shop products filtered by language for GD + WPML + Woocommerce
    if (!geodir_is_geodir_page()) {
        return;
    }
    
    //----------------------_START_CUSTOMIZED CODE---------------------------
    $removeFilterNicely = function($filter) {
        if( empty($GLOBALS['wp_filter'][$filter]) || empty($GLOBALS['wp_filter'][$filter]['callbacks']) ) {
            return;
        }
        foreach($GLOBALS['wp_filter'][$filter]['callbacks'] as $priority => $callbacks) {
            foreach($callbacks as $reference => $callback) {
                if( stripos($callback['function'],'ACF') !== FALSE || stripos(get_class($callback['function']), 'ACF') !== FALSE ) {
                    unset($GLOBALS['wp_filter'][$filter]['callbacks'][$priority][$reference]);
                }
            }
        }
    };
    $removeFilterNicely('query');
    $removeFilterNicely('posts_search');
    $removeFilterNicely('posts_fields');
    $removeFilterNicely('posts_join');
    $removeFilterNicely('posts_orderby');
    $removeFilterNicely('posts_where');
    /** remove all pre filters
    remove_all_filters('query');
    remove_all_filters('posts_search');
    remove_all_filters('posts_fields');
    remove_all_filters('posts_join');
    remove_all_filters('posts_orderby');
    remove_all_filters('posts_where');
    **/
    
    //----------------------_END_CUSTOMIZED CODE---------------------------
    
    if ((is_search() && isset($_REQUEST['geodir_search']) && $_REQUEST['geodir_search'] != '')):
        if (isset($_REQUEST['scat']) && $_REQUEST['scat'] == 'all')
            $_REQUEST['scat'] = '';
        //if(isset($_REQUEST['s']) && $_REQUEST['s'] == '+') $_REQUEST['s'] = '';
        if (isset($_REQUEST['sdist'])) {
            ($_REQUEST['sdist'] != '0' && $_REQUEST['sdist'] != '') ? $dist = esc_attr($_REQUEST['sdist']) : $dist = 25000;
        } elseif (get_option('geodir_search_dist') != '') {
            $dist = get_option('geodir_search_dist');
        } else {
            $dist = 25000;
        } //  Distance

        if (isset($_REQUEST['sgeo_lat'])) {
            $mylat = (float) esc_attr($_REQUEST['sgeo_lat']);
        } else {
            $mylat = (float) geodir_get_current_city_lat();
        } //  Latitude

        if (isset($_REQUEST['sgeo_lon'])) {
            $mylon = (float) esc_attr($_REQUEST['sgeo_lon']);
        } else {
            $mylon = (float) geodir_get_current_city_lng();
        } //  Distance

        if (isset($_REQUEST['snear'])) {
            $snear = trim(esc_attr($_REQUEST['snear']));
        }

        if (isset($_REQUEST['s'])) {
            $s = trim(esc_attr(wp_strip_all_tags($_REQUEST['s'])));
        }

        if ($snear == 'NEAR ME') {
            $ip = $_SERVER['REMOTE_ADDR'];
            $addr_details = unserialize(file_get_contents('http://www.geoplugin.net/php.gp?ip=' . $ip));
            $mylat = stripslashes(geodir_utf8_ucfirst($addr_details[geoplugin_latitude]));
            $mylon = stripslashes(geodir_utf8_ucfirst($addr_details[geoplugin_longitude]));
        }
        if (strstr($s, ',')) {
            $s_AA = str_replace(" ", "", $s);
            $s_A = explode(",", $s_AA);
            $s_A = implode('","', $s_A);
            $s_A = '"' . $s_A . '"';
        } else {
            $s_A = '"' . $s . '"';
        }
        if (strstr($s, ' ')) {
            $s_SA = explode(" ", $s);
        } else {
            $s_SA = '';
        }
    endif;
}

  • Thanks for your answer!!

    What I need is to sync the data of an option page between multiple language, using WPML.
    – In a plugin
    – Option page created via php by the plugin (acf_add_options_page, acf_add_local_field,etc)
    – When the user save the form in any language in the admin, I need the same data to be in the form when the user switch language. These are settings shared for all languages.

    Best approach I found was to watch for the save and then resave the data in all languages. Maybe there’s a better way…

    If not, here’s my code to do it. It works fine for all the fields, except one repeater)

    $henri_fields_to_sync = array(
		"henri_google_analytics",
		"henri_remove_accent",
		"henri_disable_update",
		"henri_password_protect",
		"henri_social_icons_group",
	);
	if (  isset( $_SESSION['is_saving_acf_henri'] ) ) {
		unset( $_SESSION['is_saving_acf_henri'] );
	}
	/** Sync acf_field between language */
	function henri_sync_acf_field_language( $fieldValue, $field, $post_id ) {
		if ( ! isset( $_SESSION ) ) {
			session_start();
		}
		global $sitepress;
		if ( !isset( $sitepress ) ) {
			return;
		}
		if ( ! isset( $_SESSION['is_saving_acf_henri'] ) ) {
			$_SESSION['is_saving_acf_henri'] = true;
			$activeLang          = $sitepress->get_ls_languages();
			foreach ( $activeLang as $key => $value ) {
				if ( $key !== ICL_LANGUAGE_CODE ) {
					set_global_option_icl( $post_id['name'], $fieldValue, $key );
				}
			}
			unset( $_SESSION['is_saving_acf_henri'] );
		}
		return $fieldValue;
	}

	foreach ( $henri_fields_to_sync as $henri_field_to_sync ):
		add_filter( 'acf/update_value/name=' . $henri_field_to_sync, 'henri_sync_acf_field_language', 10, 3 );
	endforeach;

    Thanks again for your time!

    stef

  • did you rename the file acf-FIELD_NAME-v5.php to acf-wpml_languages-v5.php ?

  • if anyone is searching for a solution to this issue, i had 2000 posts and found a way.

    just write a php script that loads wp (outside of wp theme folder).
    it should first go through groups of posts if you have to many (say grouping of 50). i did it with a url start stop var ?start=0&stop=100

    you can first load the post, take the title into a var

    then update the post using wp_update_post and the title from the var

    https://codex.wordpress.org/Function_Reference/wp_update_post

    it took about 10 mins to update all 2000 after each load and changing the start stop and because i am force saving the post, the acf default values for some fields were generated and saved.

    plus this was with wpml translated posts as well, so it was about 3800 as some translations were missing.

  • its what im afraid of.

    my only issue is that basically acf is used in combination with wpml, so that is one plugin i cannot disable and i hope this is not the problem.

    my plan of action now is to duplicate the whole site to a dev environment, scale back plugins that are non essential or not involved in anything at the core of the site admin, see what else i can remove, then hope for the best that i find the culprit and i can resolve the issue.

    The last resort is that if i ever change any ACF field value by editing the field, i always have to make sure to track if it disappears, and if it does i go into sql and reset the parent value.

    Strange thing was, it only started happening recently and i cannot for the life of me remember which plugins i updated and when.

    If you ever find the post/problem John, let me know, you would be saving me a lot of effort to check it and see if there is an immediate fix.

  • OK, solved my problem. I don’t know if this is the same as yours, but will write my solution anyways. I am using WPML and ACF.

    When duplicating/translating my field group to the second language, it couldn’t find and match my clonefield settings choise on the other language – even though that the clonefield field group itself was already duplicated/translated to second language – resulting in “Unknown” as setting.

    The clonefield it self is only shown by conditional logic, and when it had “Unknown” as clonefield settings choise, it resulted in a JS bug, as you describe.

    When changing the duplicated/translated field group settings, so that the clonefield now looks at the duplicated/translated clonefield field group, it all works.

    🙂 Rasmus

  • Hi @maidus

    I think the issue is some of the repeater entries in the database is set to copy, but the other are not.

    Repeater field has several entries in the database. It looks like this:

    gallery                      2                 // number of rows
gallery_0_image              6                 // sub field value
gallery_0_description        "some text"       // sub field value
gallery_1_image              7                 // sub field value
gallery_1_description        "some text"       // sub field value

    It’s possible that the first entry (number of rows) is set to copy, so all languages will have the same number of rows. This page should give you more idea about it: https://wpml.org/documentation/plugins-compatibility/translate-sites-built-with-acf/.

    I hope this makes sense 🙂

  • So, after some testing, disabling all other plugins and returning to default WP template It finally did remove that empty line. But, I did have WPML installed before and after disabling it, it did left behind all languages ACF blocks, so I had three repeater blocks. If i did remove empty lines from all three repeaters(EST, RUS, ENG) it did save, but if i removed it from only one language repeater block it did not save and recreated that empty line. So, i think that is related to WPML and ACF compability because default template didn’t have any effect with WPML enabled. I have latest versions from both plugins.

  • Hi @embleme-communication

    WPML has just released an update to fix this.

    The changelog states: Fixed compatibility issue with ACF Pro causing fatal error for translatable field groups

    https://wpml.org/2016/12/wpml-3-6-2-stability-compatibility-improvements/

    Please update to the latest version to fix this.

  • the icl_make_duplicate filter intentionally disables this because of the following bugs (quoted from the source)

    always translate independately to avoid many many bugs!
    – translation post gets a new key (post_name) when origional post is saved
    – local json creates new files due to changed key

    Edit: This bug probably belongs over at WPML as they are the ones setting a new key when the fieldgroup is saved. https://wpml.org/forums/topic/wpml-acf-field-groups-are-not-duplicating-properly/

  • We are having the exact same problem.
    We desactived every plugins but WPMLs and ACF Pro and we are getting that error also.

    If we desactivate WPMLs and only let ACF Pro, the groups & fields saving is going perfectly. (except there’s no translation)

    The website viability is compromised actually because of that bug…
    We would like to have a solution or a workaround to get back on track asap.

    -E

  • OK, done:

    https://wpml.org/forums/topic/wpml-acf-compatibility-issue-in-taxonomy-edit-page/

    Thank you!

  • Hi @permanyer

    I’ve just checked it again using WPML and it seems that WPML is duplicating the last ‘tr’ element on the page and adding it’s meta box (language switcher).

    The problem is that this duplicated tr contains all the ACF classes, so ACF thinks it is a WYSIWYG field. This is why the JS fails.

    Can you please contact WPML and let them know that they should use a clean ‘<tr>’ element to avoid conflicts with 3rd party plugins. ACF is not the only plugin that appends extra form inputs to the category edit page, so it would be in WPML’s best interest to fix the issue from their end.

    I hope this makes sense 🙂

  • OK, yes, sorry

    The theme is ok, but it gets broken when WPML plugin is activated.

  • @raison Just curious, are you using the Advanced Custom Fields Multilingual (ACFML) plugin?

  • I am trying to create my own function as follows, to replace the_sub_field() in the template, but it returns the value twice.

    function the_sub_field_wpml($field)
{
	$the_value = the_sub_field($field);
	
	if($the_value == '' || !$the_value)
	{
	
        //set the current language to EN temporarily
        add_filter('acf/settings/current_language', function(){return 'en';});

        $the_value = the_sub_field($field);

        //set it back to DE
        add_filter('acf/settings/current_language', function(){return 'de';});	
	
	}
	
	
	return $the_value;
}

  • Thanks but I dont think this works… we want to run have_rows() in the current language the user is on, because there could be options added in that language, in which case we want to show them. Only when there are no values in that language do we want to show the english. This is because WPML is not copying the site options so they are all blank.

    So putting the language change before have_rows() wont work, because it will always return the english wont it?

    I was hoping to find some conditional that says if the value does not exist to get the value from the english.

    Thanks

  • This reply has been marked as private.

  • There would need to be something in the duplicate function that would look at the relationship field and find the posts of the right language. This would need to either be built into WPML or possibly be done by adding your own custom filter to the duplication process. In either case the best place to get help with this is going to be WPML.

  • Hi @roi

    I’m not sure what happened, but a lot of things can happen in two years of time span. It’s possible the issue came from ACF, but it’s also possible that the issue came from WPML itself.

    If the issue can be solved by re-saving the post, then I suggest you do that instead. Re-saving the post mostly will save the required data that is not generated back then.

    Also, could you please make sure that you have followed the guide here: https://www.advancedcustomfields.com/resources/multilingual-custom-fields/.

    Please make sure to backup your site before doing that.

    I hope this makes sense 🙂

  • Thanks, field names are always English. My site will most likely be in Dutch.

    I read through all the docs on ACF and WPML and since it was written in the WMPL docs that all template strings should be in English, I was doubting, since I echo all the field labels manually in my template… Hence…

    The field names are only shown when a user adds/edits a post (through the front-end).
    Knowing this, would you still advise to do it in Dutch or does this change it ?

  • Sorry to be the guy who necros an old post like that but as of September 2016 the issue still persists. I am running ACF 5.4.4, WPML 3.5.1.1 and WordPress 4.6.1 so pretty much the bleeding edge on all fronts. I am experiencing the exact same bug as described above – when duplicating a field group from the main language to another I get a separate translation even though I check the Duplicate tickbox. This can lead to having a hard to diagnose discrepancy between field group definitions in different languages especially when working with a team of people. The groups need to be duplicates to remain up to date with the main language.

Viewing 25 results - 101 through 125 (of 495 total)
1 2 3 4 5 6 … 18 19 20