So you know I'm not a lazy customer... I have spent about a week of researching, reading, and trying before my flurry of posts!
I think a lot of my confusion is because the same terms and words are used for multiple concepts . Confusion examples:
- "Hierarchy" = tags category hierarchy, Toolset post relationships hierarchy concept, a general concept, AND native WP page parent-child hierarchical relationships which do not exists for posts (but can be enabled?).
- "Post" = an action of publishing / posting content, a built-in WP entity called a Post, and a concept of Custom Post Types (which is itself a concept, name of a Toolset component, and a created entity... that overlaps with hierarchy... sheesh!)
My goal in these questions is to understand the idea of hierarchical post types moreso than a specific configuration.
1. I have a many-to-many post relationship (eg. Bands / Appearances / Events example). When creating a view with content selection Bands and Appearances. If I try to create a query filter: Post Parent - Select posts whose parent is the page where the view is shown. I see a notice " This will filter out posts of the following types, because they are not hierarchical: <my CPT>" ... will you please explain this to me?
2, When creating a CPT.
2a. Sections to display when editing CPT... "Page Attributes. Menu order and page parent (only available for hierarchical posts)"
2b. Options: "hierarchical. Whether the post type is hierarchical. Allows Parent to be specified. Default: false."
3a. Is this the ability to create nested parent - child PAGES (Page Attributes > select Parent from dropdown) as a custom post type?
3b. What does #2 have to do with #1?
3c. Is this related to a difference between a formal built-in WP [Custom] Post Type Hierarchy vs. creating Post Relationships with Toolset (which is a parent-child relationship, even in the many-to-many concept of using a CPT with 2 parents)?
3d. What else do I need to know about this in order to make decisions (which is more important than understanding tactical configuration I think).
I tried to number everything to make responses and conversation easier.
I hope this makes sense :-\ ... thanks for your help.
Dear GTD9219,
There are lots of questions in this thread, I am trying to answer them one by one
Q1) notice " This will filter out posts of the following types, because they are not hierarchical: <my CPT>"
In your case, you will need to setup the post type relationship filters, see our document:
https://toolset.com/documentation/user-guides/querying-and-displaying-child-posts/
3A) Is this the ability to create nested parent - child PAGES (Page Attributes > select Parent from dropdown) as a custom post type?
Yes, you are right, this is the ability to create nested parent - child PAGES, see wordpress document:
https://codex.wordpress.org/Function_Reference/register_post_type#hierarchical
Whether the post type is hierarchical (e.g. page). Allows Parent to be specified. The 'supports' parameter should contain 'page-attributes' to show the parent select box on the editor page.
3B) What does #2 have to do with #1?
If you enabled the option "hierarchical", you will need to enable the option Sections to display when editing CPT... "Page Attributes. Menu order and page parent (only available for hierarchical posts)", so when you edit a single custom post, you will be able to see a meta box "Page Attributes", where you can setup it's parent post.
3c)Is this related to a difference between a formal built-in WP [Custom] Post Type Hierarchy vs. creating Post Relationships with Toolset (which is a parent-child relationship, even in the many-to-many concept of using a CPT with 2 parents)?
Wordpress built-in WP [Custom] Post Type Hierarchy is relationship between posts of same post type, but Types Post Relationships is the relationship between posts of two different post type, see our document:
https://toolset.com/documentation/user-guides/filtering-views-query-by-post-parent/
3d) What else do I need to know about this in order to make decisions (which is more important than understanding tactical configuration I think).
If you are going to setup relationships between posts of same post type, you can try with WordPress built-in Hierarchy option ,
If you are going to setup relationships between posts of different post type, you can try with WordPress built-in Types Post Relationships:
https://toolset.com/documentation/user-guides/creating-post-type-relationships/
Thanks!
FYI, i've read the https://toolset.com/documentation/user-guides/querying-and-displaying-child-posts/ , https://toolset.com/documentation/beyond-the-basics/post-relationship-concepts/implementing-many-to-many-relationships/ and a related dozen posts 2-5 times.
So, my understanding and conclusion are: There are a variety of ways to "configure" hierarchy and relationship:
Option #1. CPT with Hierarchy enabled (like WP Pages).
Option #2. CPT Post Relationships (Parent / Child) using Toolset
... which correlates to options for configuring Views and Query Filters
A. Filter By: "Post Parent" is for CPTs with hierarchy enabled (Option #1 above)... this is a strict hierarchy like that which native Pages uses. To use this, I need to have hierarchy enabled and nest sub pages within a single CPT (which is unrelated to CPT Post Relationships because Post Relationships are across multiple CPTs) ... right?
B. Filter By: "Post Relationship - Post is a child of" ... Is this related to the across-multiple-CPTs Toolset Post Relationship... or also related to Option #1.
C. My confusion and challenge was related to https://toolset.com/documentation/beyond-the-basics/post-relationship-concepts/implementing-many-to-many-relationships/
Section: "Display artists appearing at an event" ... "Add a Query Filter to filter by Post relationship. From the options choose Select posts that are children of the Post where this View is shown
and
"Section: "Display events at which an artist appears"... Add a View cell which queries appearances posts using a Query Filter to show appearances that are child posts of the post where this View is shown (namely, the artist being shown)
I think I was incorrectly associating those instructions to Views > Query Filters, when that is related to the Toolset Layouts Module... but remained confused about how "child post relationships" were being reference. In the last of the above instructions related to "implementing many-to-many relationships". Bands and Events are accessing each other "through" the intermediary child CPT (appearances) in the Content Template or Layout.
D. https://toolset.com/documentation/user-guides/many-to-many-post-relationship/ ... "When you create this View, remember that we are querying the intermediary post. In our case – appearances. Add a filter for event parent, selecting Post where this View is inserted. This will keep just the appearances that belong to the displayed event."
My confusion is Appearance has two Parents: Bands & Events... but Appearance itself seems to not have any children... but Events "access" Bands through Appearances... so Bands operate as a child of Appearances, and is defined by id="$band" when configuring the View.
E. In the upcoming new release of Many-to-Many... is this structure changing or is the UX simply improving?
Gosh... I hope I am making sense.
A) I need to have hierarchy enabled and nest sub pages within a single CPT (which is unrelated to CPT Post Relationships because Post Relationships are across multiple CPTs) ... right?
Yes, you are right
B) Filter By: "Post Relationship - Post is a child of" ... Is this related to the across-multiple-CPTs Toolset Post Relationship... or also related to Option #1.
Yes, it is across-multiple-CPTs Toolset Post Relationship
C) What is your question here? please elaborate it
D) Appearance has two Parents: Bands & Events
Yes
so Bands operate as a child of Appearances
No, "Bands" is the parent post type of "Appearances", I suggest you follow our document to setup a demo in your own website:
https://toolset.com/documentation/user-guides/many-to-many-post-relationship/
E) In the upcoming new release of Many-to-Many... is this structure changing or is the UX simply improving?
Yes, the structure will be improved, see our blog post
https://toolset.com/2017/09/preview-for-many-to-many-relationships-in-toolset/
And please create new threads for the new questions, that will help other users to find the answers.
I get a little frustrated when the ticket response points me back to the same page I referenced in my initial post and said I have read many times :-\. If that page answered my question, I wouldn't bother yall.
"C) What is your question here? please elaborate it"
Perhasp the following will be clearer.
"D) Appearance has two Parents: Bands & Events... Yes. So Bands operate as a child of Appearances.
No, "Bands" is the parent post type of "Appearances", I suggest you follow our document to setup a demo in your own website: https://toolset.com/documentation/user-guides/many-to-many-post-relationship/"
hidden link - I understand the dual parent relationships. However, if it is a parent post, then why does the graphic show and highlight "post relationship filter > select posts that are CHILDREN of the Post where this View is inserted"? ... In this example, the Band Appearances view is being inserted on the Event page. Based on the filter "Post where this View is inserted" ... the child of Events, is Appearances. Appearances has the 2nd parent: Bands. Based on the "Displaying Many-to-Many Relationships Using Views" section... what is the mechanism for how Events "gets to" Band data? Said another way, the filter seems to get from Events to Appearances... but what traverses back up from Appearances to Band and back to Event?
What is the loop for this relative to the Post [where the view is inserted] and the post relationships?
Q1) select posts that are CHILDREN of the Post where this View is inserted"?
Since the screenshot you mentioned above is a view querying child "Appearance" posts, and this view is displaying in a single "Event" post, so you will need to setup the filter as the screenshot, for post type relationship filters, please check our document:
Querying and Displaying Child Posts
https://toolset.com/documentation/user-guides/querying-and-displaying-child-posts/
Q2) what is the mechanism for how Events "gets to" Band data?
The best document for answer your question is the document you mentioned above.
Let me simplify it:
in a single "Event" post, query it's child "Appearance" posts, and display their parent "Band" posts information, and here is a document about display parent post field document:
https://toolset.com/documentation/user-guides/displaying-fields-of-parent-pages/
Q3) but what traverses back up from Appearances to Band and back to Event?
Same as Q2)
Q4) What is the loop for this relative to the Post [where the view is inserted] and the post relationships?
Same as Q2) , please check our document:
https://toolset.com/documentation/user-guides/filtering-views-query-by-post-parent/
Parent is the current post in the loop
The post_parent field matches the id of the current post in the loop, used with nested Views when listing a series of posts to display content from their immediate descendants.
