Repeater field returning repeater count until post is saved via admin screen

• hyperarts

• April 26, 2016 at 4:47 am

Hi –

I have a repeater field that I’m saving rows to when a form is posted. This form posts to a custom post type that is never open or ‘saved’ by a person via the admin screen.

Using the update_sub_field() appears to be working correctly, when I open one of the custom post via the edit admin screen, I see all the correct data for the repeater that was submitted from the form. But, if I call get_field(‘repeater_name’) i get the count instead of the normal values array. If I call has_rows(‘repeater_name’) it returns false.

As soon as I “save” the post via the admin screen, has_rows() and get_field() return the data I’m expecting.

How can I resolve this. I can’t have someone go in a save the post each time, the whole process is supposed to work w/o human intervention. I have also tried just saving the post with wp_update_post($post->ID), but that doesn’t seem to trigger whatever it is in ACF that needs to know not to return the repeater count, but rather the data I’m after.

• James

• April 26, 2016 at 2:40 pm

Hi @hyperarts

It’s possible that the saved data didn’t have the reference keys yet. Could you please use the update_field() function instead and use the field keys for the selector instead of the field name. This page should give you more idea about it: https://www.advancedcustomfields.com/resources/update_field/.

I hope this helps.

• hyperarts

• April 27, 2016 at 2:48 am

Hi James –

I’m using the outside have_row() version of update_sub_field.

update_sub_field( array( 'field_559eee03f62d2', intval( $field['data']['group'] )+1, 'field_559eee10f62d3' ), $field['data']['term_id'], $submission_id );
update_sub_field( array( 'field_559eee03f62d2', intval( $field['data']['group'] )+1, 'field_559eee26f62d4' ), ucfirst( $field['value'] ), $submission_id );
                            

If I convert over to update_field() than I have to rewrite the code to make the whole array first, then send to update field all at once, correct? (A lot of investment in that.)

The very odd thing is, when the admin page loads, the fields are set correctly, but when trying to get the values in code, only the number of rows is returned and have_rows() returns false. Seems like a bug with update_sub_field()

I’d also like to add that this code was working previously and I wonder if an update introduced a bug. Unfortunately this code is only run quarterly. I remember it working fine when I launched it 6-9 months ago. But now there are problems.

• hyperarts

• April 27, 2016 at 3:33 am

Dumping out the meta_data for one of these post reveals that when the post is saved via the admin save button, it has a [_primary] => array ([0] => field_key).

When dumping out the meta for a post that has only had its repeater field sub fields saved, it is missing the [_primary] key in the meta array.

I guess I maybe able to resolve this (glitch, bug, or miss understanding of how ACF update_sub_field() works) by adding that meta value and array with key, programatically.

FIXED
Add this after the update_sub_field() function is called appears to fix this issue.

update_post_meta($submission_id, '_primary','field_559eee03f62d2');

The repeater name is “primary” and ACF needs the “_primary” meta to hold the “primary” field key ID. It would be nice if this was done via update_sub_field() but apparently it isn’t.

• James

• April 27, 2016 at 11:03 am

Hi @hyperarts

Thanks for sharing your workaround.

Like I said before, “_primary” is the reference key of the repeater field in the database. Please take a look at this page once more: https://www.advancedcustomfields.com/resources/update_field/#field_key-vs%20field_name.

When you use the update_sub_field() function, it creates the reference for the subfield in the database, but not for the repeater itself.

Another workaround, you can use the update_field() function and pass an empty array to it before the update_sub_field() loop. Maybe something like this:

update_field( 'field_559eee03f62d2', array(), $post_id );

That way, the repeater will be initialized first and have the reference key and an empty value.

I hope this makes sense. Thanks!

• hyperarts

• April 27, 2016 at 1:46 pm

Hi @James –

Thanks, that does make sense. I guess I assumed that updating a sub field would initialize the repeater, or did at some point. To me it seems like it should, or the docs should say to do an initialization to a repeater before calling update_sub_field().

Thanks