[Resolved] Why use repeating fields/groups versus parent/child post relationships?

[Author]

Posts

[John Johansen]

Tell us what you are trying to do?
Understand when and why I would use repeating fields and/or repeating field groups within a custom post type in order to support a multi-level data hierarchy rather than using multiple custom post types with parent/child relationships.

Is there any documentation that you are following?
Toolset Types.

Is there a similar example that we can see?
No.

What is the link to your site?
Not applicable.

[Nigel]

Hi John

Firstly, note that this will change significantly when the current major update to Types is complete, which you can read about here: https://toolset.com/2017/09/first-beta-of-types-2-3-with-post-relationship/

Bearing in mind that the current implementation is based upon standard WordPress posts and post meta, stored in the standard wp_posts and wp_postmeta tables, the current situation is as follows:

Repeating fields mean you can have multiple instances of a field assigned to a single post, e.g. if you want to add a custom 'to-do' field to a 'project' post type you can add as many to-do's to that project as you like, and as many to-do's to other projects as you like, each to-do field stored as an entry in wp_postmeta for the corresponding project post.

Say you want to store some additional information about the to-do's, such as status, priority, and deadline.

You could add repeating fields for each of these to a project, but they wouldn't be associated with the to-do's in any way.

With repeating field groups you could have a group of fields, to-do's, status, priority, and deadline, that were associated with each other and connected to the project post, and you could add as many repetitions of these associated fields as you wanted to each project.

But. These are not directly supported in Types currently (this will be added in the new version).

You can simulate repeating field groups by making a child post type of projects which is a container for the group of fields, and you can then assign as many child posts to the project as required. So you might make a child post type called 'task' and this post type has custom fields for the to-do, status, priority, and deadline.

Under the hood this is still how repeating field groups will work in the future version, but the UI will be substantially improved and you won't have to deal with registering the child post type yourself.

If you go ahead and make a site based upon the above now, it will migrate to the new system automatically when available.

You can read more about post relationships here (https://toolset.com/documentation/beyond-the-basics/post-relationship-concepts/) and here (https://toolset.com/documentation/user-guides/creating-groups-of-repeating-fields-using-fields-tables/).

[John Johansen]

Nigel:
Thank you for your detailed response. I will review the suggested documentation as soon as possible.

I'm still not clear on how I would decide whether to use a parent/child custom post structure OR to use repeating fields and field groups (when they become available). As you mentioned, the methods used 'below the waterline' by these two techniques for storing and organizing the data are different but they still support specific data relationships that can be used on the front-end. All good there. My concern is the comparative advantages/disadvantages to using one technique over the other, especially from a design/development/maintenance perspective. For example, does the advent of repeating fields/groups make the use of parent/child posts obsolete?

[John Johansen]

Follow up question:

Using the existing practice of parent/child post relationships, it is possible for a given 'child' post to have multiple 'parent' posts. For example, an Order Detail post could have a parent post of 'Order' and another parent post of 'Product'.

However, under the proposed structure of repeating field/groups, a given instance of a repeating field/group could have only one parent, correct?

[Nigel]

Hi John

You may have misunderstood the point about how repeating field groups will work in the new version, in that, under the hood they will work *the same* way as parent-child relationships, not differently. You won't need to explicitly create the child post type, it will be done for you.

Parent-child relationships and repeating field groups each has their use, and with the underlying data structures being the same, which you choose will depend very much on what makes sense for a particular project.

For example, with repeating field groups you need never know that there is a child post type. In some projects you may explicitly want to reference and display the child post type, create "orphan" child posts that don't have a parent, or that have several parents of different post types. (That touches on your last update, where you are correct that a child post can have parents of different post types but a repeating field group will only ever belong to a single post.)

By the way, please post in the "Technical Support" forum in future where you'll get faster responses. This forum is intended for users of the free version of Types.

[John Johansen]

Nigel:

Thanks for the detailed response. Very helpful.

Regarding the appropriate forum, will do.

JJ