Home Forums General Issues Helping planning ACF project Reply To: Helping planning ACF project

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