[Resolved] Post relationships not configured as expected

[Author]

Posts

[johnB-38]

Greetings,
The Toolset framework is impressive and offers some excellent tutorials which I have been doing my best to get through. However, with a deadline pressing, I would like to ask a question about relationships.
My background is Drupal for the past 8 years: I've never had a go with WordPress and am struggling with basic concepts.
In this specific case, I am migrating a bunch of nodes (posts) from Drupal to WP, and I need to keep the entity relationships intact.

We have type=projects and type=publications

Projects have a unique NID value, and I have imported this to the CPT postname value, and the value is also stored in a custom field.
Each project can have many publications...but the project itself has no idea about these publications. In other words, there are no "referencing nodes" values stored on each project.
Over on the publications side, each publication may have up to 1 project reference. This value is stored as ProjNID and is sitting in a custom field.

I am trying to do two things with relationships and views:
1. When a Project post is loaded, I want a View that dynamically takes the current post variables (eg URL as query parameters), use a defined relationship, and load/display custom fields from related publications (loop).
2. When a Publication post is loaded, I want a view that dos the same thing, except its relationship will allow it to loads custom fields from the one related project.

In Drupal this would be a straightforward process...and I just feel it is in Toolset as well, but I can't get my head around how to make it work "the Toolset Way".

I think I need two different relationships and two different views...one to work for each of the CPTs.

Starting with the Projects, they have a 1:M with Publications (each Project can have many publications related to it).
But projects themselves have no list of these related Publications...that value sits in the Publications.

So the query has to run "backwards"...[for (thispost); take URL(string); find all publications where URL(string) = ProjNID]

Does that make sense? How can this be configured in Toolset?
Perhaps I will leave it there...maybe if you can help me with this half of the query I can work out the other situation with querying for a Project reference when a Publication post is loaded.

Thanks indeed for your assistance!!

[Luo Yang]

Hello,

Yes, you are right, it needs to setup one-to-many relationship between post types "projects" and "publications".

If you don't migrate to one-to-many relationship, you can try these:

1) When a Project post is loaded...
In a single "Project" post, you can get the post name(slug) with shortcode [wpv-post-slug], then you can pass it to a post view and filter by the post name value
For example:
create a post view, with a filter:
Select items with field:
ProjNID is a number equal to VIEW_PARAM(projnid)

Then display above post view in the single "Project" post, like this:
[wpv-view name="houses" projnid="[wpv-post-slug]"]

see our document:
https://toolset.com/documentation/user-guides/passing-arguments-to-views/#controlling-the-filter-with-shortcode-attributes
https://toolset.com/documentation/user-guides/views-shortcodes/#wpv-post-slug

2) When a Publication post is loaded,

There isn't post name filter within post views, but you can still use Views filter hook to apply it, see our document:
https://toolset.com/documentation/programmer-reference/views-filters/#wpv_filter_query

You can get the ProjNID field value with function
https://developer.wordpress.org/reference/functions/get_post_meta/

Then apply it to the view's query
https://codex.wordpress.org/Class_Reference/WP_Query#Post_.26_Page_Parameters
name (string) - use post slug.

[johnB-38]

Greetings Luo Yang,

Thank you so much for the reply and further explanation.

My developer has created a "hardwired" solution so you can see the end result on this page...list of publications is at the bottom:
hidden link

This has been achieved through a custom cron script that queries the CPT tables and populates a lookup table (I think).

I am concerned that this is a brittle solution. And I am concerned that we are missing the power of Toolset Views and Relationships.

Your first line is curious: I am not sure what you mean: "If you don't migrate to one-to-many relationship"

You refer to the fact that Projects are imported without reference to their "referencing publications"...is that right?

Yes, at the end of CSV import, we have "half" of the relationship...Publication rows have their "parent" Project ID stored in a custom field...but the Projects have only their own ID stored. They do not store the [many] IDs of their children. (maybe Projects are considered bad parents??)

Then, in your point (1) above, it sounds like you solve the problem...no custom script is needed...all the query and display is done on the fly. Is that right?

Sorry if I'm needing a bit more clarity...and thank you for your patience.

Kind regards,
JBrisbin

[Luo Yang]

Dear JBrisbin,

Q1) You refer to the fact that Projects are imported without reference to their "referencing publications"...is that right?
I mean if you keep on use the setting you mentioned in original post:
https://toolset.com/forums/topic/post-relationships-not-configured-as-expected/#post-922731
you can still achieve it with Views plugin + some custom PHP codes.

Q2) it sounds like you solve the problem...no custom script is needed...all the query and display is done on the fly. Is that right?
Yes, it should be able to solve the problem without any custom codes.

[johnB-38]

Great! Thanks so much for your assistance.

If I can suggest a feature request for your development pipeline: please consider that people will be either modifying existing installations or importing new data...in either case there is a need for robust UI to help solve the sort of problem I bring up here.

Ideally I would encounter the Relationship and View UI that allows me to specify the key value used to join tables in the relationship. This join should be available in the UI.

In my case, all we needed to do is tell Relationship that the table join is intended between between two custom fields on the two CPTs.

I look forward to further Toolset development on Relationships and Views.