Support

Account

Register Login

Forum Replies Created

  • Good news! With the new PRO version 5.6.6 this feature has finally landed in Core.

    It works great so far. It sets the currently active tab in Local Storage when the page is unloaded. As far as I can see, there’s no logic yet that unsets the setting at a certain time, so as long that value is in Local Storage, it will load the same tab.

  • Hey @virgodesign

    I also hope that there will be a solution implemented into core.

    You are right, the solution provided also sends an AJAX request when you open a post for editing, which is unnecessary, because the first tab is always selected by default.

    I optimized the code a little, so that it only sends an AJAX request when it’s really necessary. It won’t send one on startup, only if a different tab is selected.

    https://gist.github.com/gchtr/2d371918f3778683c61f629dbc545972

    The solution currently saves the index as a transient, which is valid for 5 minutes. I like your idea of using the value just once and then deleting it right away. I added that to the gist as well.

    Saving the current tab in a hidden field and store it in the database when saving a post might be the better solution, but it needs a little more effort to implement. I prefer the quick and easy fix here, because I don’t consider it to be a permanent solution.

  • I further looked into it. And you are right, it’s actually not a bug. I had to make sure that the local field group is also registered when the wp_ajax_acf/post/get_field_groups action runs. A classic hooks problem.

    This can be closed. Thanks for your help!

  • This bugged me a lot. So I wrote a small class to handle this:
    https://gist.github.com/gchtr/2d371918f3778683c61f629dbc545972

    Whenever a tab is selected in a post, a transient containing the current tab index is saved via AJAX. When a post is loaded, it checks the transient and selects the last selected tab via JavaScript.

    Hopefully, a proper solution for this will soon be implemented into ACF.

  • Some more information to add which is missing in the answer above:
    This error only happens when you try to access all options at once using get_fields().

    Elliot meant that he can’t think of a quick and easy bug fix for this.

    However, there’s a workaround, where you don’t use get_fields(), but get_field() for every repeater. To still have them all accessible in one place, you can do something like this:

    
// Put all repeater field names you have in your options fields in an array
$options_repeater_names = array(
    'options_repeater_name_1',
    'options_repeater_name_2',
    'options_repeater_name_3',
);

$options_repeaters = array();

// Loop through repeater field names and use get_field separately for each repeater field
foreach ( $options_repeater_names as $field_name ) {
	$options_repeaters[ $field_name ] = get_field( $field_name, 'options' );
}

// Now all the repeaters are accessible in $options_repeaters

    Good luck!

  • We ran into the exact same problem when using repeater fields in theme options.

    I found the culprit, but there is probably not an easy way hook or filter it away. It’s right there in get_fields_objects(). When ACF saves a theme option in a different language, it appends the language code to the option name, like this:

    Default language (German): options_fieldname
    Other language (English): options_en_fieldname

    The get_fields_objects() function runs a direct query on the database, with the following SELECT for the default language:

    SELECT option_name, option_value FROM wp_options WHERE option_name LIKE 'options_%' OR option_name LIKE '_options_%'

    When when we compare it to the query which is run for the English options, we see that is looks explicitly for options with the language code:

    SELECT option_name, option_value FROM wp_options WHERE option_name LIKE 'options_en_%' OR option_name LIKE '_options_en_%'

    The problem here is, that for the default language, it also matches options with language codes suffixes from other languages. So the English options are loaded as well. ACF then can’t correctly set a value and overwrites the values for the default language with the additionally loaded values from another language.

    Now I don’t know how this is solved best. I guess either the query has to be adapted to filter out all other languages or they have to be filtered out after the query.

  • I think you need to tell ACF that it should load the value for the correct attachment translation.

    I just ran into the same problem and solved it with the following filter function added to functions.php. I have the the WPML Media Translation Module activated, but didn’t test it without it. 

    
/**
 * Make Media attachments translatable with WPML
 *
 * Filter ACF images and galleries to switch attachment ids with their
 * corresponding WPML translation.
 */
add_filter( 'acf/load_value/type=gallery', 'my_acf_load_translated_attachment', 10, 3 );
add_filter( 'acf/load_value/type=image', 'my_acf_load_translated_attachment', 10, 3 );

function my_acf_load_translated_attachment($value, $post_id, $field) {
    $newValue = $value;

    // Make sure we are using WPML
    if ( function_exists('icl_object_id') ) {
        // Galleries come in arrays
        if ( is_array($value) ) {
            $newValue = array();
            foreach ($value as $key => $id) {
                $newValue[$key] = icl_object_id($id, 'attachment');
            }
        }
        // Single images arrive as simple values
        else {
            $newValue = icl_object_id($value, 'attachment');
        }
    }

    return $newValue;
}

    This isn’t tested thoroughly, but can you try if this is working for you?

    This might also fix the issue described in http://support.advancedcustomfields.com/forums/topic/wpml-and-gallery-field/.

Viewing 7 posts - 1 through 7 (of 7 total)