How to store a repeater row number as a value in another field

• alexwright

• June 27, 2021 at 2:06 am

Hi!

I have a site where users have one or more mailing addresses stored in their user accounts. Custom post types reference these mailing addresses. If a user adds or changes a mailing address, the existing custom post types need to keep their association with the unchanged mailing address – the one originally associated with the custom post type. I’m trying to figure out the best way to accomplish this. We have a lot of users and a lot of addresses.

I figure that I could add a repeater field for the users with one or many addresses stored per user. Some users will have one, some two, a few will have a dozen. Then I could have the custom post types get assigned a row of this repeater field, and the row number will be consistent and not change even if the user adds more addresses. In this way, addresses could never be deleted and the custom post types will always keep their association to the address that was assigned at the time the custom post was created.

Is this the best way to accomplish this, and if so, how do I add a field to the custom post types that simply holds a repeater row number for this address repeater? I’ve not seen this done in the “standard” stack of backend tools that ACF offers. I’m sure it could be custom programmed.

Is there an easier way?

THANKS!!!!!

-Alex

• John Huebner

• June 27, 2021 at 10:40 pm

Repeaters can be moved, so the row number may mean nothing if they alter the order of the repeater. They could also change the value of that row.

I would create an acf/save_post filter. I would use another field, outside of ACF to store “permanent_email_address” using a standard WP custom field using that used update_post_meta(), get_post_meta(), etc. When the post is first set up I would set this value.

• alexwright

• June 29, 2021 at 12:44 am

Yes I understand that repeater row order can change and that rows can be deleted. This is why I’m asking what the best solution is to add a unique value for a repeater row and then to store this value in another post that references the repeater row.

I’m not sure what you’re referring to with “permanent_email_address”. We are storing mailing addresses, not email addresses. And nothing is permanent as anything in the universe can change, which is what this whole process is meant to achieve – letting users add new mailing addresses while always keeping intact previous posts that reference previous addresses.

What I’m doing now is adding a “unique_id” field to the repeater row so that there’s something unique / unchanging about each repeater row to store elsewhere. Then I can add this unique_id value to any other post when I want to reference a specific row of a repeater.

I’m just not sure if this is the most efficient way to achieve this goal.

Thanks!

• alexwright

• June 29, 2021 at 12:51 am

I will say that I’ve seen a lot of interest in other support posts for an auto-incrementing id feature in ACF. For me, the question is what value to assign to this unique_id field in each repeater row.

Ideally, I’d like to have this unique_id just be an integer equal to the total number of rows in the repeater at the moment the post is saved. So if there’s only 1 row, the unique_id value of that row is 1. If there’s one and a second is added, the unique_id value of that second row is 2, and so on. If the row order is changed, who cares. The unique_id integers don’t change and can’t be edited. This integer value is already automatically auto-incremented and stored in the database in the field with the name of repeater itself – this is the number of current rows in the repeater. It’d be great to use this same auto-incrementing feature as a kind of unique_id field for each repeater row. I’ve seen numerous other requests for this feature while searching for a solution to my issue.

Instead, I’m using this https://github.com/KLicheR/wp-acf-unique_id which works fine but adds a 13 digit unique id using PHP’s uniqid() which seems like overkill to me.

It’d be really cool to see ACF integrate both an optional uneditable unique id field to repeater rows and add a way in the standard backend stack of options to select this row elsewhere in ACF. It seems from searching the documentation and support that I’m not the only one looking to achieve this.

Thanks again for reading!

• John Huebner

• June 29, 2021 at 1:30 am

I do something similar to the unique id plugin you found, but I do it manually. What I do is that I create a text field in each row, then I create a filter for this field to make it read only. Then I generate a value for this field, I generally do this in JavaScript but it can be done using an acf/save_post filter. The main issue with doing it based on the number of rows but if I had to… assuming that new fields can be added and fields can be moved.

add_action('acf/save_post', 'repeater_unique_row_id_on_count');
function repeater_unique_row_id_on_count($post_id) {
  if (have_rows('your-repeater-field')) }
    // first loop over repeater to get existing IDs
    $existing_ids = array();
    while (have_rows('your-repeater-field')) {
      the_row();
      if (get_sub_field('your-id-field')) {
        // note that this field should be a read only field
        // you could also hide this field using custom admin CSS
        $existing_ids[] = intval(get_sub_field('your-id-field');
      }
    } // when while have_rows
    // you may need to reset rows, I don't know, next line may not be needed
    reset_rows()
    // second loop to set any missing IDs
    $count = 1;
    while (have_rows('your-repeater-field')) {
      the_row();
      if (!get_sub_field('your-id-field')) {
        // id field is empty
        while (in_array($count, $existing_ids)) {
          // inc count until it does not already exist
          // this will cause count to skip anything that exists
          $count++;
        } // end while
        // record ID and update sub fiele
        $existing_ids[] = $count;
        update_sub_field('your-id-field', $count);
      } // end if empty id
    } // end while have_rows
  } // end if have_rows
} // end function

• alexwright

• June 29, 2021 at 1:49 am

This is really awesome, @hube2 thank you. This is more elegant than an arbitrary value from uniqid(). I appreciate you taking the time to document this. I hope it’s useful for others as well.

-Alex