Support

Account

Register Login

Forum Replies Created

  • Changing the field keys to be the same across all sites resolved the issue.

    Thanks for the help John.

  • Sorry ignore the stray “)” within the foreach loop. Was just a typo.

    Note: I removed this using the “edit button” so ignore this comment.

  • Hi John,

    Thanks for the speedy response.

    The field groups do already exist on the site I am publishing from. Although they do have different field keys.

    The repeater field key is field_5d14dda3d0dcc.
    The repeater sub field key is field_5d14ddb4d0dcd.

    Do these keys need to be the same across the multisites?

    The way we’re building our repeater array is shown here: 

    
//this is done before we use switch_to_blog()
$downloads = get_field('downloads', $original_post->ID, false) 
$repeater_values = [];
foreach ($downloads as $download) {
     $repeater_values[]['field_5df8e6a37e4c1'] = $download['field_5d14ddb4d0dcd']; //meta key of the sub field. first key is the target site, second key is current site.
}

  • For those who are curious, I created a private ticket and got a solution for this.

    The reason is being, in the latest version of ACF, the field group location options only validate field groups which have been registered for that specific post type. By default are only set for pages and thus not evaluated for custom post types.

    This meaning, in the actual template file, we need to ensure that the post type is set in the top of the file.

    For example in my template-content-areas.php file i needed the following:

    <?php
    /*
    Template Name: Content Areas Template
    Template Post Type: post, page, custom_post_type
    */
    ?>

    //rest of page markup here

    I’m not sure if this will work for pages as previously stated, the field group location settings “By default are only set for pages”

  • Is there anyone who can help with this please?

    I’m still getting this issue with clients chasing me for answers

    Thanks

  • Works perfectly!

    Thanks for your help John

  • This looks like it should resolve my issue.

    Is there any way of passing the two field keys into the function or will I need to create an entire function for each bidirectional relationship I have since the keys are only set within the function itself?

    Thank you for all your help!

  • Ok dokey, so undertaking the same process.

    Before my update:
    post_id 16095 (Vacancy): field_58c2e0bbb4904
    post_id 15540 (Research Group): field_58b99b4e8da6c

    After my update:
    post_id 16095 (Vacancy): field_58c2e0bbb4904
    post_id 15540 (Research Group): field_58c2e0bbb4904

    After re-updating my admin post:
    post_id 16095 (Vacancy): field_58c2e0bbb4904
    post_id 15540 (Research Group): field_58b99b4e8da6c

    Ok so looking at this. I can see that the field key references are initially different.

    After updating, the field key references change to the same value (my broken post is the value which changes to match the other)

    And then after re-updating my broken post the field key reference for this post updates back to it’s original value.

    Now this would make me think it was an issue with how the fields are registered initially, but surely they must have different keys in order to show the matching values. e.g. show groups on the vacancies admin or vice versa; show vacancies within the groups admin.

    So perhaps it’s an issue with my update_value call? although I followed the documentation for this to reference to the field name.

    e.g. add_filter(‘acf/update_value/name=research_group_vacancies_relationship’, ‘bidirectional_acf_update_value’, 10, 3);

  • Ok so doing a search for the field name within my database i get the following values:

    Before my update:
    post_id 16095 (Vacancy): a:1:{i:0;s:5:”12729″;}
    post_id 15540 (Research Group): a:1:{i:0;s:5:”15551″;}

    After updating the Vacancy relationship field:
    post_id 16095 (Vacancy): a:2:{i:0;s:5:”12729″;i:1;s:5:”15540″;}
    post_id 15540 (Research Group): a:2:{i:0;s:5:”15551″;i:1;s:5:”16095″;}

    At this point my field var_export() on the frontend of my research group shows a blank array.

    After resaving the research group side of relationship (in order to fix the frontend output, I changed nothing on the page, just hit update):
    post_id 15540 (Research Group) I have: a:2:{i:0;s:5:”15551″;i:1;s:5:”16095″;}

    So from this I can see that my ids have updated to include each other within the database correctly after my initial update and after updating again this changed nothing in the DB.

    So this brings me towards the conclusion of possibly something front end rather than backend causing the issue?

    Why would my var_export() return as blank when the values are saved correctly within the DB after the first update. And why would this issue be fixed when i resave the opposite side of the relationship without changing anything

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