Support

Account

Home Forums Bug Reports Weird acf/load_field behavior with combined db and json fields

Solving

Weird acf/load_field behavior with combined db and json fields

  • Hi there,

    We have an issue with ACF Pro, which I know is somewhat an edge case. I apologize in advance for the size of the following read, but the issue is very hard to explain without a little bit of context:

    We have a set of sites running as a multisite setup. We have a “root” site running on a root theme, that holds all basic ACF. As we work in a team all fields are saved to the acf-json-folder so that we can use the sync option to stay up to date with each other’s changes.

    We then have a number of sites running each its own child theme. All themes load the json-fields from the root theme. All child themes load the json fields from their respective folders using the below code, which also ensures that fields are saved to the current theme.

    // Save json to current theme only
    add_filter('acf/settings/save_json', function() {
    	return get_stylesheet_directory() . '/acf-json';
    });
    
    // Load json from both parent and child theme
    add_filter('acf/settings/load_json', function($paths) {
    	$paths = array(get_template_directory() . '/acf-json');
    
    	if(is_child_theme())
    	{
    		$paths[] = get_stylesheet_directory() . '/acf-json';
    	}
    
    	return $paths;
    });

    This is all working as expected.

    Every child theme has a unique front page (seperate field group for each child theme). Each front page consists of rows of custom taylored layouts controlled with a flexible-content field. But within some of these layouts the user can place a widget. This widget consists of another flexible-content field with options like “Latest news post”, “Next event”, “Link to page”. These choices are the same every for every widget in every layout in every field group. This means that wihtout any tweaking we would have to maintain this list of flexible-content layouts towards a number of 30 times accross all the sites.

    Thus our solution (which has been working for almost a year) was to give every widget-field the same name (front_page_widgets) and the use the acf/load_field filter to “sideload” the layouts from one json file in the root theme using this (previously working) code:

    
    function load_front_page_widgets_from_json( $field ) {
      global $post;
      // don't load when editing a field group
      if ( $post &&  $post->post_type == 'acf-field-group' ) {
        return $field;
      }
      // load layouts
      $json = file_get_contents( TEMPLATEPATH . '/config/acf/acf_front_page_widget_layouts.json' );
      $field['layouts'] = json_decode( $json, ARRAY_A );
      return $field;
    }
    
    add_filter( 'acf/load_field/name=front_page_widgets', 'load_front_page_widgets_from_json', 11, 2 );

    In the admin screen layouts are correctly loaded into the fields, but when retrieving data, what used to look like this:

    front_page_widgets": [
      {
        "acf_fc_layout": "countdown",
        "label": "Ansøgningsfrist om",
        "to": "2017/03/01"
      },
      {
        "acf_fc_layout": "external_link",
        "label": "Test label",
        "header": "Test header",
        "introduction": "Test introduction",
        "link": "https://www.testlink.com"
      }
    ]

    now looks like this:

    
    "front_page_widgets": [
      {
        "acf_fc_layout": "countdown",
        "": "2017/03/01"
      },
      {
        "acf_fc_layout": "external_link",
        "": "https://www.testlink.com"
      }
    }
    

    This changed when updating from 5.3.7 to the 5.4.6. Does anyone have any idea what could have caused this change of behavior?

    Below is a seperate issue, however still relevant in this context:

    This whole thing was before the Clone-field (which does pretty much excactly what we’re trying to achieve). So as the first step towards solving the issue, we tried to implement this functionality with the Clone field type. However this resulted in even more weird behavior: As i edit the field group and select Clone as field type, the list of fields correctly display all available fields (as well from the child theme as the root theme). When saved however the input says “Unkonwn field”. This might might have to do with the fact, that the cloned field is not in the database as it is loaded from the root themes acf-json. But I’m not entirely sure what’s causing this either.

    Thanks in advance for any help resolving this issue.

    And thank you for a great product.

    All the best,
    Anders

  • I think I understand what you’re doing, though I’ve never tried it and I don’t know why it would have been working before and not working now, but I do have a possible solution.

    Rather than just trying to assign the layouts to the using
    $field['layouts'] = json_decode( $json, ARRAY_A );
    you may need to look at adding them as local fields one at a time to the field group where you want them, and I’m not 100% sure of all the steps that would be involved with doing this. Have a look here https://www.advancedcustomfields.com/resources/register-fields-via-php/

    You may need to look into the code for ACF. There is a hook that is run when a field group is loaded (don’t remember the hook right now) and you could add the layouts to the field groups at that point, before the field group is saved in ACFs cache. This could also be something to do with the cache and ACF may be caching the field group earlier than it did before. Once ACF has put a field group into its cache, any changes you make to it will basically be ignored.

    Hope this helps.

    ~JH

  • Hi Anders,

    Looks like we’re running a similar multisite setup. I’m experiencing the same “Unknown field group” error after saving my Child theme’s fieldgroup with Cloned Field groups loaded from the parent theme.

    Did you manage to solve this problem?

    Thanks,
    Tim

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

The topic ‘Weird acf/load_field behavior with combined db and json fields’ is closed to new replies.