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
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!
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!
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
Thanks! Yeah, I’m already running filters for cf/prepare_field to get Bootstrap classes on there. Thanks again for your help!
-Alex
Thanks so much, John. That’s what I figured. It’s a bummer that the classes added to the fields in the backend can only be output on the frontend via acf_form(); but as you point out, it’s not super hard to just manually write the markup.
Have a good day!
You could take the random token and then ask for it again when the non-logged in user comes back to the page and the non-logged in user inputs the token and if it matches, the page loads the editable form again using acf_form();
Heya @rtm would you mind sharing the filter / function that finally worked for you on this? I’m trying to do the same thing but somehow am running into a wall. Or I’ve been up too long! Thanks.
In case it’s helpful, to be specific, I’m using acf_form() to allow people to fill in a frontend ACF form, and I want to log the user / id / name of the person who filled in the form. Can be a hidden function or a pre-filled form field that the person filling in the form can’t edit. So they can see that their name is logged or we can just do it in the background, I don’t care. When the acf_form() is saved, I’d like to write their user / id / name to an ACF field along with the rest of their form entry so we have a record of who filled it out.
Thanks!
