Support

Account

Register Login

Home › Forums › ACF PRO › get_field('field')['subfield'] vs get_field('field_subfield')

Solved

get_field('field')['subfield'] vs get_field('field_subfield')

  • hi,

    I was wondering which of the two is the more efficient way to get the content of the subfield of a group.

    At the end, they’re saved as field_subfield in the data base. Is there an extra interaction when I call the field using get_field('field')['subfield']?

    thx!

  • 
get_field('field')['subfield'];

    calls

    
get_field('field');

    so ACF gets the entire group field as an array

    
get_field('field')['subfield'];

    is simply returning one element of that returned array. So yes, this could create extra work if you do not want to get the entire group and all of its sub fields.

    Basically what you are doing is a shortcut for

    
$array = get_field('group_field');
value = $array['sub_field'];

  • Thank you for the explication.

    I’ve also seen that get_field('field')['subfield'] does not work very well when working with an image subfield in a custom block. get_field('field_subfield') works!

    For example: 

    $groupA_image =  get_field( 'groupA')['img'];
$groupA_imgUrl = $groupA_image[ 'sizes' ][ 'large' ];

    vs

    $groupA_image =  get_field( 'groupA_img' );
$groupA_imgUrl = $groupA_image[ 'sizes' ][ 'large' ];

  • I don’t know why this does not work in the case of an image sub field. The only thing that I can think of is that when called that way the format_value method of the image field is not being run for some reason. Exactly what is returned by this:

    
$groupA_image =  get_field( 'groupA')['img'];
var_dump($groupA_image);

    I personally do not use shortcuts of this nature because I feel that it makes it harder to understand what’s going on when I have to look at it again in 6 months or a year.

    To be honest, I don’t event use the shortcut of 

    
get_field("{$group_name}_{$sub_field_name}")

    when getting the sub field of a group because when I look at this code in 6 months or a year I want to know that I’m looking at code for a group field.

    Another reason is the possibility of unpredictable results, like in this case, that might break the site after an update.

  • hi John,

    In this particular case, how would you do it then?

    Also, with shortcut, do you mean using $groupA_image = get_field( 'groupA')['img'] as code or, in general, using groups?

  • Sorry, I didn’t mean to imply anything other than I don’t use shortcuts. I’m sure if I wanted to spend several hours stepping through the code I could figure out what it works in some cases and does not in others but I would rather not.

    To answer your question, I would likely do what I posted above

    
// get group
$group_value = get_field('group_field_name');

// get the image
$image = $group_value['image_sub_field_name'];
// get the url
$url = $image['sizes']['large'];

// or I might shorten the above two lines to something like this
$url = $group_value['image_sub_field_name']['sizes']['large'];

    If we really want to get down to what I would do, I would not return an image array for an ACF image field to begin with. Why? Because getting the details for every size of an image causes extra work to be done. This extra work will not be noticed for 1 image field but if you have 10 image fields all returning this information then there would likely be a performance hit. If the only image size I am going to use it “large” then I would return the image ID and then get the other information I need using built in WP functions, something like this.

    
$group_value = get_field('group_field_name');
// image field set to return image ID
$image_id = $group_value['image_sub_field_name'];
// get only the image size I need
$image = wp_get_attachment_image_src($image_id, 'large');
$image_url = $image[0];
// get the alt for image
$image_alt = get_post_meta($image_id, '_wp_attachment_image_alt', true);
// etc...

  • Well, there might be ten or more image per post, so your input is more than welcome.

    Thanks a lot for taking your time explaining!

    🙂

  • Correct me if I am wrong, but making ACF groups can be a way of having less calls to the database, just by grouping all needed info into one array (and so one call).

  • A group field can have more calls to the DB or the same number. This depends on if the values for the sub fields are already in the WP meta cache. Usually they are, but there are conditions where they are not. Each sub field of a group field is stored separately in the database.

    In the normal course of actions WP runs setup_postdata on the current post and all meta fields retrieved in a single query and stored in the cache.

    When getting values for a post that does not already have its meta fields stored then there is one db query for the group field and an additional db query for each sub field.

  • Ok, I see. So, best, is to test and check the database then when making new blocks.

    One question that’s a bit off topic, but driving me crazy, do you happen to know how I can store the custom post type into the block data?

    Thank you!

  • I didn’t realize we were talking about blocks. Part of the inconsistencies you’re seeing could have to do with that. I can’t help much with information of blocks because I do not developer for gutenberg.

  • Ok, thank you. I’m using your suggestion from a few posts earlier and it works fine. It also looks like a cleaner code.

    I asked the other question on the forum here, and to support too, but with no answer. Do you know where I can find the answer? I would be storing a value programmatically in de custom post type with the data of the block. This shouldn’t be so difficult. But I can’t find the answer in the docs here and I know that on the wordpress forum they will tell me to ask here :/

    EDIT: I’ve found a little work-around to that problem. A bit ugly, because it involves css !important rules, but it works. Still frustrating I can’t retrieve and store a value programmatically.

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

You must be logged in to reply to this topic.