• John Huebner

• September 27, 2019 at 11:56 pm

When you are talking about saving the child post, are you using two forms ? Do you have 1 field group containing all your fields and at the saving step you are using the acf/save_post hooks to separate the data into the good post type?

I have 2 different field groups, I have a custom location rule that shows one field group on top level posts and one field group on child posts. I’m not using 2 post types, I am using one hierarchical post type.

In the field group for the parent post I have a repeater field that has sub fields, for example “start_date” and “end_date”. There are other fields on the parent post that are also important, for example I have a field that is not in the repeater to allow setting the event as “featured”, things like this also need to be applied to the child posts. The repeater here is the data I need for creation of any child posts.

Each field I need to copy from the parent or the above repeater has a corresponding field on the child post group. For example if I need “start_date” from the repeater the child post group has a field named “start_date” (not in a repeater)

When the top level post is saved I have an action on acf/save_post. This action does a comparison between the content in the repeaters (I loop over the repeater) against all existing child posts to see what I need to delete and what I need to add. Then I delete any child posts that are no longer valid and add anything that is new using wp_insert_post() and then I use update_field() using the ID of the newly created post and the value I need from the parent or the repeater on the parent.

But like I said, you also need to deal with what happens when you delete, trash, untrash, or change the status of the parent post. All of this is done because I need to query the information for individual posts and the data in the repeater is really useless in that form.

With this setup you could have a list of each client and everything about them with a link to edit each client.