Skip Navigation

[Resolved] View within view for sequence of many-many CPTs

This thread is resolved. Here is a description of the problem and solution.

Problem:
I setup a many-to-many relationship in types using three custom posts such that
-A is a custom post type
-B is a custom post type
-C is a custom post type
-C is a child of A and B
The problem occurs in the edit screen of the posts of type (A) and (B)
When I add new raw in the "post relationship" section, all the buttons (Save,Edit,Delete) are disabled.

Solution:
Please update Types to the latest version.
If this didn't work, please replace the file " \wp-content\plugins\types\embedded\resources\js\post-relationship.js"
with the following file: http://tinyurl.com/z6w74vb

This support ticket is created 8 years ago. There's a good chance that you are reading advice that it now obsolete.

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

Sun Mon Tue Wed Thu Fri Sat
- 9:00 – 10:00 - - - - -
- - - - - - -

Supporter timezone: Africa/Cairo (GMT+02:00)

Tagged: 

This topic contains 26 replies, has 4 voices.

Last updated by jimP 8 years ago.

Assisted by: Mohammed.

Author
Posts
#372045

I'm wandering into slightly new territory here, and would appreciate assistance:

(1) I have a sequence of three CPTs, we'll call A, B, and C. My goal is to display fields from C on the content template for A. A and B are in a many to many relationship, as are B and C.

(2) I have a View defined for the intermediate CPT between B and C that shows fields from C; when I insert this View in a content template for B it works fine.

(3) I also have a View defined for the intermediate CPT between A and B that shows fields from B; this also works fine in a content template for A.

(4) Here's the problem, when I insert the View from #2 above into the view for #3, I get "No items found" for the fields from C (i.e., view in step #2 doesn't work correctly inside view in step #3).

I would assume this should work; I'm sure I'm just getting the syntax wrong somewhere. The reason this should work is that there is a logical path from A to C via B; however, these are not parent-child relations, as are what you feature in your Views Within Views documentation:

https://toolset.com/documentation/user-guides/using-a-child-view-in-a-taxonomy-view-layout/

Thank you as usual for your guidance!

Jim P.

#372051

Btw, this is not a solution, but as a diagnosis if I remove the query filter from the inner View (#2 above, displaying fields from C), then *all* records from C are displayed on A. (I occasionally meant "records" above when I said "fields.")

So, I'm pretty sure I just have the wrong query filter for the the inner View. My current query filter for both was "Select posts that are children of the Post where this View is inserted."

Regards,

Jim P.

#372123

Yes, since you query Intermediate Post Object (IPO) in View One, and then tell the second View to display posts that are child of the Post set in View A, this will not return results.

Because the second view is querying IPO's as well, which are only child to Post Types not queried in the First View.

If you call a parent Post meta or data in a View, it does not mean this is the Post returned by that View.
You simply return the Current IPO and call a parent meta of that Post.

What you will need to do is query a given Parent Post and then insert a View that queries Child Post Types set by the parent view post.

https://toolset.com/documentation/user-guides/displaying-related-child-posts/
https://toolset.com/documentation/user-guides/querying-and-displaying-child-posts/

Does this help?

#372424

Beda, I'm trying hard to understand...read those help pages, but don't necessarily find exactly what I'm looking for. Would it be possible for you to clarify what you mean by "What you will need to do is query a given Parent Post and then insert a View that queries Child Post Types set by the parent view post" by referring to my CPTs A, B, and C? (Remember that, for our needs, A-B and B-C both have a many to many relationship...we can call their IPOs IPOab and IPObc.)

My general assumption is that I'll have three elements:

(1) A content template for CPT A (this what I'm ultimately displaying), containing

(2) A view for IPOab, which itself contains

(3) A view for IPObc.

For (2) and (3) above, I'm trying to be clear about:

(a) Which post type to select under Content Selection (I'd assume in each case the IPO, i.e., #2 = IPOab and #3 = IPObc).

(b) Which Query Filter to apply (for #3, the "inner" View, I can hear you saying "Select posts that are a children of the Post set by parent View"; not sure on the other one).

My guess is that my general assumption as to flow (1, 2, 3 immediately above) may be incorrect, or one or more specifics in my views (a and b immediately above) may be incorrect...or both!

I sure appreciate your help. If I could have found an example that's just like this I think I could have done it myself!

Regards,

Jim P.

#372472

Let's see.

My general assumption is that I'll have three elements:

(1) A content template for CPT A (this what I'm ultimately displaying), containing

==> So far so good

This will display Posts in CPT A
CPTA Is liked to CPT B with IPOab and CPT B is linked to CPT C with IPObc

(2) A view for IPOab

==> Good as well.
With this View, you can display:
IPOab posts directly
CPT B posts (by calling Parent Fields of the CPT B in the above View)
CPT A posts (by calling Parent Fields of the CPT A in the above View)

[...], which itself contains:
(3) A view for IPObc.

==> You have a connection from CPT A, CPT B and CPTB by the two IPO (ab and bc)
==> I assume, finally, you want to display on the Content template for CPT A, information about CPT B and CPT C
==> CPT B can already be easily displayed, as illustrated above
==> CPT C is only related to A via the CPT B, not via a direct Child/Parent relationship.

==> The easiest solution is to display your stuff on CPT B instead, with 2 Views, the first View for IPOab and the Second Vie for IPObc

You can not insert a View that is set to display Child Posts of the Post set by the parent View, in a View that actually displays already a Child Post Type.

What you could try as well, is insert the Content Template for your Post Body of CPTB in your View for IPOab.
Then, in that Content template, insert a View, that queries IPObc where the Query is set to return Posts child of the Current Post.

This set up is a bit "messy" to explicate in bare theory.

What I would like is to show you the opportunities.

If you know Discover WP please set up a test site there, create your Post types and relations, some dummy content, send me the login details and I will show you what you can do.

Or, if you have already a Test Site, send me the login to that, so I can have a look to explain this better to you.

Discover WP is located here:
http://discover-wp.com/

I will enable a private reply.
Please ensure backups if you provide access to a site of yours.

thank you

#372726

Okay, I have gone ahead and duplicated my Types CPTs & custom fields, and Views content template and views, at this discover-wp.com site:

hidden link

This page here summarizes the relational structure of our CPTs, with all sample records on this discover-wp site noted in the diagram at bottom:

hidden link

As you'll note, the only visible CPT is the (regular) post; I have a very barebones content template for that one, just to test whether appropriate Contributor and Contributor Resource records appear (the latter do, the former don't, for the reasons we've been discussing).

This content template includes a Post - Contributor Resources View, which itself includes a Contributor Resource - Contributors View. Again, these views, like the content template, are not replete: they were just done to figure out how to include the correct Contributor(s) (item C in my original post in this support thread) on the editor's post (item A in my original post). This isn't yet working, as discussed.

You don't need to worry about all the other fields and etc. I haven't yet included...they should be pretty easy.

Do be in touch, and thanks for your prompt attention!

Jim P.

#372872

Minesh
Supporter

Languages: English (English )

Timezone: Asia/Kolkata (GMT+05:30)

Beda on his weekend holidays. This is Minesh here to help you further. Hope this is OK.

Could you please send discover-wp.com access details.

I have set the next reply to private which means only you and I have access to it.

#373311

We do have a possibility to access any Site on WP Discover, but would you like it when any supporter would have access to any Test Site, which after all is a Private test Site?

This is why the Super Admin access is kept secret and only a few persons in the Company with the right permissions could actually access your Site without asking you permission or details.

I apologize that this might be confusing and time consuming, but it is to protect your Data and to do things on your test site only with previous warning and your agreement.
I also requested the details in advance so to save time.

I had a look at the diagram and the related Post Types.

This Post Type (IPO)
Posts-Contributor Resources Links
Is Child to Post and Contributor Resource, and this is what you can deeply with it.
==> Query the IPO and call the parent posts.

The View you use for this Post Type is set to:
Select posts that are children of the Post where this View is inserted.

This will return (query) all IPO of type Posts-Contributor Resources Links that are Child to any Post or Contributor Resource, if inserted to one of the Post Types.

Since you then call the View for Contributors-Contributor Resources Links in this same view and tell to Select posts that are a children of the Post set by parent View, and this Post type is not Child to Posts-Contributor Resources, there will be no results to return.

This IPO is only child to Contributor and Contributor Resource but those are never queried by Your parent View.

From your Diagram I deduced what you want and will try to explain what you need to do.

EDITOR POST is your central item here.
You have EDITORs and CONTRIBUTORS connected to them

Since you want a many to many relation, you will have a Child Post to EDITOR Post and EDITORs (IPO one)
Then you have another Child Post to again connect EDITOR Post and CONTRIBUTORS (IPO two)

Since contributors can have Resources as well, you will set the Child Post TWO as well to be child to EDITOR Resources.

Now you create your Posts, and then you query CHILD POSTS in the Views.

The first Views will be insert in a Content template which styles the EDITORs Posts.
With this view you can call Editors

Then you also insert the View two with which you can call Contributors and their Resources (depending on the current EDITOR post)

This will automatically return the connected CHILD Posts by the View, in where you can then call the connected Parent Posts.

You will need two Views, there is no way to call a Child Post of a Post if it's not directly insert in the Post, or the View is not returning that Post by query.

Please let me know if you have further questions regarding the issue mentioned in this Thread

Thank you for your patience.

#373469

Okay, yes I do understand this, and thanks! Basically, the difference btw your structure and mine is that there are *three* parents to IPO two; this way we don't have to query a child post that is not directly connected to the editor post.

The drawback, as I look at it just now, is that there is no necessary relationship btw contributor and contributor resources: this will need to be set each time a particular contributor resource is invoked. What I think I will do is this: maybe I will simply merge contributor and contributor resource (i.e., the contributor fields will become attached to the contributor resource CPT).

Regardless of how we do this, I now understand that my original solution -- to put a view inside another view -- does not work with a sequence of many-to-many CPTs, in that one would have to query an IPO child that is not directly connected to the parent of interest.

I'll keep this ticket open if you have any clarification on the above, but I'll go ahead and move accordingly.

Regards,

Jim P.

#373545
Screen Shot 2016-03-07 at 10.53.28.png
Screen Shot 2016-03-07 at 10.47.27.png

Now I have an issue, which perhaps may be resolved by placing a view within a view! See the attached Post Relationship which shows up when editing an editor post, and the resultant post. (Pardon formatting; this is just for testing.)

In your recommended approach, IPO two has three parents: editor post, contributor resource, and contributor. The other two linked CPTs, contributor resource and contributor, are selected together when a new link is added (see attached Post Relationship screenshot). If we wish to specify more than one contributor for a particular contributor resource, we would create additional links (i.e., rows) for this contributor resource, and select a different contributor for each. In this example, I have two contributors for resource #2, and one contributor for resource #1.

The problem lies in the formatting of the content template for editor post, as the view that queries the above IPO two inserts the multiple-contributor resource as many times as there are contributors (i.e., links or rows in the Post Relationship metabox). What you'll see in the example is that Contributor Resource Two is listed twice. I'd instead like to list it only once, and loop through the two contributors for this resource, then go on to the next resource.

Again, this may be solved by placing a view inside my view querying IPO two! So maybe a view inside a view is still needed.

(Btw, I did not do what I proposed above, i.e., add contributor fields to contributor resource CPT, as this would require that we enter contributor information multiple times, when in fact we are working with a relatively small number of contributors and often multiple resources by the same contributor. In short, I'm sticking with your recommended solution.)

Regards,

Jim P.

#373677

This can not be solved with a nested View.

You will display PCR Links child of the current Post, and then parents of the PCR Link.
This will always loop thorough all items and output contents as many times there are items to display.

The only way to restrict this would be to add additional Filed information to the parent Posts like a field "Duplicate"

So in the View where you display the parent info of PCR Links you can check with HTML conditionals if the Parent Post has field value "duplicate" or not, and accordingly display it.

Eventually you could add this Field to the PCR link post itself, and check if it stores "duplicate", then display only CERTAIN data, other wise display ALL data.

You can also add values or fields like "Different Contributor" or "Different Resource" and according to this value again with conditional HTML you can decide what to display.

Conditional HTML is elaborate here:
https://toolset.com/documentation/user-guides/conditional-html-output-in-views/

Please let me know if you have further questions regarding the issue mentioned in this Thread

Thank you for your patience.

#375264
Screen Shot 2016-03-13 at 13.47.44.png
Screen Shot 2016-03-13 at 13.47.30.png
Screen Shot 2016-03-13 at 13.47.08.png

Okay, I have now decided on a new "star" structure for the CPT relationships based on your response, so as to simplify the Posts content template; it is as you'll see here:

hidden link

This is simpler: there is one child intermediate post type connecting Posts and the three CPTs. All in theory is straightforward and could readily be incorporated onto the Posts content template (as well as upcoming content templates for Editors and Contributors).

But there is possibly a bug in your most recently released versions (we're on Types 1.9.1, which I'd assume is the relevant plugin); see attached screenshots. What you'll see is the following:

(1) When you are editing a Post and add the *first* post relationship (of any CPT), all works fine.

(2) But when you add the *second* post relationship (of any CPT), all "Add New ... Link" buttons are greyed out, as is the "Save Draft" button. At this point, I've only found two workarounds:

(a) Publish the post (which the author may well not yet want to do); or

(b) Close the post edit window, then re-open from Posts. This is workable, but of course not optimal when a number of post relationships are being specified.

Feel free to try this on our test site, and I'm sure you can reproduce it. Possibly there's something else I haven't thought of, but so far on my production site and this test site I can't get around this bug.

Many thanks,

Jim P.

#375317

I see this - it should not be like this.

I will try to reproduce that locally now and escalate - thanks very much for kindly reporting this!!

If you don't have any more doubts on the setup, you can consider this handled.

We will try to provide a Errata (hot fix) and if it's not possible, the next release will include the fix.

Thank you again for your immense patience and professional bug reporting!

#375318

I have been able to reproduce this with a single, simple Parent - Child(IPO) - Parent relationship

There seem to be more.
Also adding Fields like Images, after you save the post, grays out the Save Post button of WordPress (but it's still clickable)

I will report this issue.

Please expect my informations here in the forum.

Thank you for your patience.

#375319

Okay, many thanks...I look forward (and so do my student editors!) to that bug getting fixed.

Regards,

Jim P.

This ticket is now closed. If you're a WPML client and need related help, please open a new support ticket.