I have a hierarchical custom post type called "section" which conveniently lets me break my site into content sections like 90 % of the sites you see out there. In each "section", I can have any number of posts, media, or about 5 different custom post types.
I am hoping that you have a way to set up a one-to-many relationship that allows one custom post type to have multiple different post types and instances of those posts types related to it.
So when I write an article for the News section, I select News from the Section field in my editor for the article before publishing. If I want to set up a gallery, I use the Gallery custom post type and it has images related to it. But it is also related to a section.
And some content needs to be able to be assigned to more than one section.
So the relationships would be like:
Section Articles
Section Topics
Section Galleries
Section Subsections
Section Forms
Section Profiles
Section Portfolios
Section Media
as well as
Article Topics
Topic Images
Gallery Images
Forms Images
Profile Images
etc. etc. etc.
------------------------
You might think of it as having two new relationship types:
one-to-one,
one-to-many,
many-to-many,
one-to-every (where all post types and custom post types would be related to one element)
and maybe
one-to-any (which would be like one to one, but it could be any post type singly linked to another)
I am working on a new theme. It's been a long time since I have worked with Toolset and it sounds like things are coming along great.
I am working on my local site at the moment.
Thanks for letting me know if this is possible or if I should put in a feature request. Best wishes,
Jase
Sorry for the delay responding to your question. We had a problem in the forum and this ticket didn't get assigned to a supporter correctly. I'll try to help.
I am hoping that you have a way to set up a one-to-many relationship that allows one custom post type to have multiple different post types and instances of those posts types related to it....And some content needs to be able to be assigned to more than one section.
So can you explain in more detail how is this not a many-to-many relationship or a group of many-to-many relationships? A one-to-many relationship allows one parent in a single post type. If a specific piece of content needs to have more than one parent in the same post type (i.e. one article shows up in more than one section), and parents need to have more than one child from the same post type (i.e. multiple articles show in one section), that's the definition of a many-to-many relationship between articles and sections. This assumes section is a custom post type, and article is a custom post type. Why won't a many-to-many relationship work here?
This is a little difficult to describe and I have written this response a dozen times, so bear with me please. When you setup "relationships" in Toolset, I guess you are setting up one-to-one relationships between post types only. In other words, ONE POST TYPE relates to ONE POST TYPE. Within that relationship, you can have one instance of the first post type relating to one instance of the second post type (what you call ONE-to-ONE) or you can have one instance of the first post type relating to multiple instances of the second post type (what you call ONE-to-MANY). But I feel like this is a semantic change of context. For me to setup a post-type relationship the things that should be relating are the post types, not their content. Logically, a ONE-to-MANY post type relationship would clearly indicate that one POST TYPE relates to multiple other POST TYPES. Now, I understand that what you mean is that you only set up one POST TYPE RELATIONSHIP (one post type to another single post type) with ONE or MANY instances of that relationship.
My problem is that I have one post type that I want related to all the other post types. A field inside the one post type would contain an array of references to a large variety of different post types. So your solution, I can tell, is to manually create these one-to-one post type relationships for every possible combination of my main post type and every custom post type. This means that if someone adds a post type in the future and I don't explicitly declare the relationship, it just won't relate. That's the problem.
If you separated the INSTANCE relationships (contents of the various post types) and actual POST TYPE relationships, you could do some much more effective things. In other words, you could setup a new type of POST TYPE RELATIONSHIP (probably called ONE-to-ANY) that would automatically associate itself with any newly added custom post types--no need to add the relationship because it is covered. In fact, one relationship between post types (not their contents) would allow you to setup in effect multiple INSTANCE relationships. And then you could create an INSTANCE relationship that sought to relate one post (content) to all other posts (content). So you could have a SITE post_type where you setup your site parameters (like logo, title, colors, etc.) and relate that one instance of your "SITE" post_type to every other piece of content in any other post type with one relationship.
I was just looking for a logical programmatic way to establish relationships that would persist through adding custom post types in the future (without having to manually declare relationships). I realize you are too far into your current implementation of relationships to change, so I will just look elsewhere. Thanks for your help. Jase
I understand better now, thanks for the details. There's no way to set this type of dynamic relationship in the current system, but I can see how it would be useful. I think it could be accomplished with either an API for the initial setup of Relationships, or an introduction of the one-to-any relationship type. I encourage you to submit new tickets in the forum using the "suggest an improvement" option, and describe either approach. This will allow other Users to see your request and upvote it for importance. Our developers use the feature request list (https://toolset.com/feature-request) to help determine priorities. In the meantime, individual relationships must be created manually in the wp-admin area.
