Helping planning ACF project

• gabick

• September 27, 2019 at 1:21 am

Hi! I am an experienced developer but it’s the first time I am working with ACF and I would like some help for planning my project before stating in the wrong direction.

Any advice will help
Thanks in advance!

This is a gift for my wife so I would like to make it as efficient as possible 
I will explain my project briefly.

In short, I would have 2 custom post type with a relation one to many.

One of them is client containing multiple fields like Name, addresses, etc.

The other one is Phone Call history. It will contain a repeater containing multiple fields of Date/notes/ if the person has answered etc.

Habitually, I would create another table and insert all those Phone Call history into it and do a Left Join query on this table to get the data.

Since it’s for my wife, I cannot use only 1 custom post type because later on I will like to add more data to those post (example of statistics of how many calls she did this months, etc.)

I would like to use the ACF_FORM so she will be able to do everything in the frontend.
She would like to be able to add history by “bulk”

Basically she would like a listing page containing X clients (let’s say 10)
each of those clients would have their repeater for their phoneCall history
I am having trouble figuring this page.
Having an edit link redirecting to post?xxx and editing on this one is fine, but editing on the “listing page” how can I achieve this?

Am I going in the good direction with 2 custom post type? Should I use Post-2-Post?

• John Huebner

• September 27, 2019 at 3:40 am

The main issue I see with your plan is on the front end of the site having multiple clients listed with a repeater for each client. The issue here is that ACF cannot handle updating repeaters attached to different posts at the same time. The reason for this is that the fields that ACF would display would be duplicates, in other words the name and id attributes of the fields would be duplicated for each repeater. There really is no easy way to update ACF field in bulk this way.

One way around this would be to have multiple forms on using multiple calls to acf_form(), one for each client.

Other than having multiple forms that each need to be submitted separately you would need to build your own front end form and not use ACF and then you’d need to build your own form processor that would save all the fields to the correct place. Possible, but not something that I would do.

I would likely make it so that each client would need to be edited separately.

——————-

As for the multiple post types, this is something to think about and may not be for everyone…

So I recently did a thing that is quite similar, it was not clients and a call log, but, I have one post that holds the main information and I have multiple other posts that hold details about each item in the repeater. My needs were a lot more simple as it was for events that can have multiple dates.

Here is how my events feature works.

I have a post type called event, on this page there is a repeater field that holds dates and other information specific to each date for these events. When this post is saved a child post of the event post is created for every date entered into the repeater. The reason for this is that it gives the client an easy interface for entering the dates and it also allows me to have a separate post for each date with detailed information about the event on that date. This was important because every event date must have it’s own post in order to display the event multiple times on the “upcoming events” page. As you may or may not know, it is impossible to make WP show the same post multiple times on a standard WP archive page. This setup allows me to use the single file archive-event.php to show events and have them seemingly appear multiple times. The rest of the work is a little more complicated, but being able to use the built in logic for the archive page saved more time than the rest of the work took.

The client does not know that these child posts exist. These are hidden in the admin and there isn’t any way for the client to directly edit these posts. The whole thing is a bit complicated but my goal was the same as yours, to give the person entering the information an easy interface.

On the front end of the site I alter the query for archive pages using a pre_get_post filter that forces only querying for child posts. Then I display data from the child post or the parent post depending on where it is stored. All links that are added all point to the parent post. In addition to this I have code that will redirect any requests for a child post to the parent post.

In the admin I have a pre_get_posts filter that hides all of the child posts in the post list as well as a redirect in the admin that will redirect to the parent post editor should someone attempt to edit the child post directly… unless it is me that’s looking at it.

Creation of the child posts is all done using an acf/save_post filter.

There are other filters as well, to be honest I probably couldn’t remember them all without looking at the code, but there are filters to handle deletion of values in the repeater as well and changes made to it. And there are other filters that handle things like the deletion of a parent post or changing the status of the parent post, etc.

There are also 2 field groups, one group with the repeater that only appears on top level posts and another field group with individual fields that is only used for the child posts.

This does mean that there is duplication of data in the database. Any of the values from the repeater fields that I need are duplicated to the child posts that are created, each field in the repeater has a dedicated top level field for the child posts. But it does mean that I can query for posts using that information directly instead of trying to query data in a repeater.

• gabick

• September 27, 2019 at 11:14 pm

Wow ! Thanks a lot for the anwser ! It’s really appreciated!

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 knew one big form for the listing page wouldn’t work because of those ID/Name, I was thinking of doing a for each for every client and creating a separate form for each of them.

I might try to do a multi-step form instead, it might be easier.

A listing page containing all the clients/phonecall data with an edit link that redirects to ?postXXX with a 2 step form. Step 1 editing clients if needed, step editing/adding the phone logs.

Thanks

• 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.