Skip Navigation

[Resolved] How to select a main parent CPT

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

Problem: I would like my Users to select one parent post, then have that parent post applied to a post relationship filter in each View they visit on the site until they choose another parent post.

Solution: You can store the selected parent post ID in a custom field on the User's profile, then use a shortcode attribute to pass that value into a post relationship query filter using a View shortcode attribute.

Relevant Documentation:
https://toolset.com/documentation/user-guides/views/passing-arguments-to-views/
https://toolset.com/documentation/customizing-sites-using-php/functions/

This support ticket is created 4 years, 8 months 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
8:00 – 12:00 8:00 – 12:00 8:00 – 12:00 8:00 – 12:00 8:00 – 12:00 - -
13:00 – 17:00 13:00 – 17:00 13:00 – 17:00 13:00 – 17:00 13:00 – 17:00 - -

Supporter timezone: America/New_York (GMT-04:00)

Author
Posts
#1539047

Hello!
I would highly appreciate some help with the following situation:
- I have a parent-child relationship where the CPT "Project" is the parent.
- The user should have an option to select a certain project - let's say at the start page he/she can choose from a list/dropdown of the available projects.
- After that all the other views which show child posts of the parent CPT "Project" should automatically know which project is selected; no matter where the user navigates to in the site structure, until he/she selects another project.

I cannot see how to achieve this for example with URL-parameter or shortcode-parameters. Is there a way for toolset to store this information globally?

Thanks in advance for your help!
Regards,
Andreas

#1539339

Hi, one Toolset method to store and reuse that parent post value would be to create a custom field on User profiles. That field would be used to store a parent post ID ( a numeric field would be fine ). Then you could pass that stored value into each related post View using a shortcode attribute, or using the Views API and some custom code. Let's say the custom field is a numeric field with the slug "selected-parent", and you will use shortcode attributes instead of the API.
- Create an Edit User Profile Form that includes a generic select field with the slug wpcf-selected-parent and remove the other fields like name and password, etc. Keep the Form Messages field, since it handles error displays.
- The options in the generic select field should be generated by a View of parent posts, using the loop format "list with separators" and a specific output style and syntax including the post ID and post title shortcodes. There are several other tickets about this in the forum, like this one: https://toolset.com/forums/topic/place-view-inside-generic-field/
- User submits the Form and this automatically updates their profile to include the selected parent post ID custom field value.
- User navigates to another page that contains a View of child posts. There is a Query Filter for post relationship on this View, where the parent post is set by one shortcode attribute wpvrelatedto.
- You have inserted the View of child posts into this page using a shortcode, and in the wpvrelatedto shortcode attribute you have inserted the User field shortcode for selected-parent:

[wpv-view name="Your child post View" wpvrelatedto="[types usermeta='selected-parent' output='raw'][/types]"]

- The View now only shows child posts that are related to the parent post stored in the selected parent field for the current logged-in User.

Another option is to use a proxy post and a post relationship. This approach eliminates the need for a generic select field with options generated by a View. Instead, you'll just use a many-to-many relationship between the parent post type and some proxy post type for Users, like "Members". The post relationship field in a Form is easy to use because it allows the User to search for parent posts by name using an autocomplete field.

Each User is responsible for publishing one and only one Member post using Forms. Since the User is the author of that post, you now have a way to create post relationships with Users by means of a proxy post type. More information about that concept here: https://toolset.com/documentation/post-relationships/how-to-create-custom-searches-and-relationships-for-users/

The tricky part in this approach is getting the User's Member ID easily so you can pass it into a View of child posts using a shortcode attribute. It might require a small custom code snippet or shortcode. I can find one of those I've worked on in the past as an example if you decide to take this approach.

Yet another approach involves storing a front-end cookie with the selected value, but this requires a significant amount of JavaScript that falls outside the scope of support we provide here. I wouldn't recommend this approach unless you or someone you know is a JavaScript developer.

Let me know your thoughts and we can go from there.

#1540417

Hi Christian,
thank you very much for your thoughts! I went for the first option to store the selected parent in a custom field of the user profile. In the generic select field of the Edit User Profile Form I just had to include an "persist":1 in order to have the value stored in the db. It took me some time to figure that out, so here the code of the generic select field which worked for me , maybe it is of future use for somebody:

[cred_generic_field field="wpcf-selected-project" type="select"]
{
"required":0,
"validate_format":0,
"persist":1,
"default":[],
"options":[[wpv-view name="nbm-custom-project-select-output"]]
}
[/cred_generic_field]

Again, thanks a lot for your support!

#1540419

My issue is resolved now. Thank you!