Skip Navigation

[Gelöst] intermediary of relationship show title of parent of child Part 2

This support ticket is created vor 3 Jahren, 8 Monaten. 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.

Heute stehen keine Supporter zur Arbeit im Werkzeugsatz-Forum zur Verfügung. Sie können gern Tickets erstellen, die wir bearbeiten werden, sobald wir online sind. Vielen Dank für Ihr Verständnis.

Sun Mon Tue Wed Thu Fri Sat
- 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 -
- 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 -

Supporter timezone: Asia/Karachi (GMT+05:00)

Author
Artikel
#1982643
Screenshot 2021-03-11 at 16.49.27.png

Tell us what you are trying to do?

Part one put forward the problem:

https://toolset.com/forums/topic/intermediary-of-relationship-show-title-of-parent-of-child/

Following on from this attempt to find a sollution to display the title of a parent in one to many relationship (Artist to artworks(products)) into the intermediarly of another relationship which is many to many (Exhibitions to Artworks), I did some research.

Firstly I see that from the intermediary go the many-to-many (exhibitions/artworks) , when I add a single field block and look at the dynamic options, one referring to the parent in the other relationship appears as you will seen in the screenshot attached: Parent: Artist Member.

This initially looks promising, but there is no output?

From the original support ticket it is suggested that this needs to be tackled programatically but so far I am bit vague in what this entails.

I found the following Toolset documents:

https://toolset.com/documentation/programmer-reference/views/views-shortcodes/item-attribute/

And

https://toolset.com/documentation/customizing-sites-using-php/post-relationships-api/#toolset_get_related_posts

Am I on the right track?

#1983487

Hi Stephen,

Thank you for contacting us and you're on a right track.

Reading through both these tickets, I feel what you're aiming at is possible, without having to write custom SQL queries, using any of these:
- nested views with the post-relationship filter,
- item attribute,
- toolset_get_related_posts function.

Note: Since nested views are not supported in the Blocks environment, whenever, you'll need to show related post information across multiple levels, you'll have to switch to the legacy/classic views.

While working with the related posts, it is important to keep track of the scope of the 'current' post. For example, if the current post is the intermediary post from the "Exhibitions to Artworks", it means that using the "item" attribute or view with the post-relationship filter you can reach its "Artworks" post. And once you've reached the "Artworks" post, you can reach its "Artist" post in the "Artist to Artworks" relationship too, which will only be one as it is a one-to-many relationship.

Now, which of the three tools should be used, depends on the particular requirement and where and how you need to show the related post(s).

If you just have to show a single field data from a directly related post and where only a single related post can exist, you can use the item attribute with the relevant shortcode.
( ref: https://toolset.com/documentation/programmer-reference/views/views-shortcodes/ )

If you have to show multiple related posts, multiple fields from a single related post, or have to go multiple levels deep into relationships, then it would be beneficial to change the scope of the current post, segment-by-segment, using views with the relationship filter.

And if you'd prefer working with Blocks editor and/or are comfortable with the PHP code, then you skip the use of multiple/nested views and can do the heavy lifting in the PHP code by getting the data from multiple levels related item(s) through a custom shortcode that uses "toolset_get_related_posts" function.

I hope this explanation helps.

regards,
Waqar

#1983831

Thanks Waqar,

I will keep the ticket op en while I go and research through the documentation.

#1984005

Ok, I am making some progress with this. It looks like there are several ways to do this and ways to present view and templates.

I may try out some of the other approaches aa well to gain a better understanding.

#1986429

Thanks for the update and glad that you're making progress.

Please let me know if you have any follow-up questions.

For a new question or concern, you're welcome to start a new ticket.

#1986647

Hi Waqar,

I have. made some progress. I need to explore more the opportunities afforded by the different options with:

https://toolset.com/documentation/programmer-reference/views/views-shortcodes/item-attribute/

and

toolset_get_related_posts

On the toolset_get_related_posts I have looked trough some of the tickets submitted by others on this and out of context it is not the easiest to follow what they are achieving with this. Equally, attempting to invent a scenario to test t this isn't easy either so the end result it is difficult to comprehend definitively what can be done with things like toolset_get_related_posts.

I sometimes think that some examples with a walk through in the documentation can help to illustrate what can be done. I see the snippets provided on the Post Relationships API page but again for somebody who doesn't do an awful lot of programming these are a bit of a mind warp until you understand what they are actually doing.

I did get the artist's name to appear on the intermediary post with nested views.

I have another related views on intermediary post query which I will open on a new ticket.

I will persevere. While block solutions are great for 80% of use case, it's the edge cases with other solutions where interesting things can be achieved.

#1988579

Thank you for sharing your feedback and observations.

A post-relationship connection consists of 3 elements:

1. Parent post
2. Child post
3. Intermediary post (only in case of many-to-many relationship type)

The "toolset_get_related_posts" function is handy for all those cases, where you have one of those elements and you need to get the information about the other element(s) inside the PHP code.

Since this function accepts a number of parameters in a certain order ( ref: https://toolset.com/documentation/customizing-sites-using-php/post-relationships-api/#toolset_get_related_posts ), it can look a bit complicated first, but if you clearly define those parameter values in different variables beforehand, the actual function's code will become tidier.

For example, check this very simple snippet from the other thread:
https://toolset.com/forums/topic/get-parent-in-a-relationship-not-working-as-expected/#post-1169512

I feel you're on the right track and you're welcome to mark this ticket as resolved.

But in case you have any new or follow-up questions, please feel free to start a new ticket - we're here to help!

#1988733

Thanks Waqar,

Before I close this ticket I have one more question.

With the examples you have shown, along with what I see elsewhere, do these need to be wrapped in the standard function calls for add_action, add_filter and add_shortcode? And, if this is the case, where is the best place to put them? In the theme's functions.php file or the Custom Code settings in Toolset settings? I usually put non theme/site specific functions into a custom plugin that I use an all my sites.

#1988765

Yes, your understanding is correct, and depending on where you need the result from the "toolset_get_related_posts" function, you can wrap it within the standard function calls for hooks and filters.

And it should work from the theme's file, Toolset's custom code section, and the custom plugin, alike. It is a matter of personal preference how someone would prefer to organize the custom code snippets.

#1988773

Thanks Waqar,

All makes sense. I'll close the ticket now and spend some time exploring what can be done with all this.