Skip Navigation

[Resolved] relationships of posts created via formidable forms not updating after migration

This support ticket is created 4 years, 1 month 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
- 10:00 – 13:00 10:00 – 13:00 10:00 – 13:00 10:00 – 13:00 10: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/Kolkata (GMT+05:30)

This topic contains 10 replies, has 2 voices.

Last updated by gorakhnathS 4 years ago.

Assisted by: Minesh.

Author
Posts
#1891549

Tell us what you are trying to do?
Actually nothing new. However after migration (which we aren't sure when or how it happened), the relationships of posts created via formidable forms aren't getting updated by updating the _wpcf_belongs_parentposttype_id. so I searched and figured that toolset doesn't support that method any longer, after migration. ref: https://toolset.com/forums/topic/entering-the-_wpcf_belongs_parent-slug_id-no-longer-connects-the-post-types/

Is there any documentation that you are following?
Now I tried to understand my alternatives based on the new relationship API, however, given that my posts are being created on the fly by formidable forms, there is no way to get the post id of the child post type to use the relationship API.

Now I want to know if without reverting to the pre-migration relationship, is it possible to udpate the relationship, either by using a value from the custom field or something similar. May be you can create a "migration undo" tool and share with those of us who don't want the migration features, because manually going back to the backup before migration is going to be one hell of an effort, given that there are hundreds of entries daily and the last possible pre-migration backup is more than few weeks old.

What is the link to your site?
Most of this happens behind the login, so will be able to share only if absolutely necessary (privacy concerns)

#1892043

Minesh
Supporter

Languages: English (English )

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

Hello. Thank you for contacting the Toolset support.

We always recommend running your site with the latest features Toolset plugins offered and the post-relationship is one of that major change.

We offer post-relationship API where you can find the function to connect the posts:
=> https://toolset.com/documentation/customizing-sites-using-php/post-relationships-api/

But as you shared, you do not have child post ID, so to connect two post types, it will require child post ID and parent post ID.
=> https://toolset.com/documentation/customizing-sites-using-php/post-relationships-api/#toolset_connect_posts

The feature you asked could be there but our Devs might not be agree as shared, we always ask users to run their sites with latest software versions and features. The method you used was the legacy method and its been replaced by new efficient post-relationship.

Having said that, there is no way to undo the changes, so you might want to consider replacing the old backup.

#1893715

Hey Minesh,

Thanks for clarifying the possibilities out there. Kind of hitting a wall in our case.

Alternatively is it possible that instead of using relationships, we use a custom field for it? what we can do is add a custom field to the child post type. This custom field will collect the id of the parent post type. While displaying the list of the child post types on the parent post page, we can simply filter it to check if this custom field equals the parent post id.

For now this seems possible and found out some reference to such solutions here -> https://toolset.com/forums/topic/filter-view-by-post-id-of-current-post-how/ and here -> https://toolset.com/forums/topic/filter-view-by-post-id-of-current-post-how/

So I figured that the only way to filter a view by current post id of the parent post type is by nesting shortcodes. Well, here we hit another wall. We have built this site using Oxygen Builder. So nested shortcodes aren't working. Can you please guide me around this? This is critical to the website's working and no matter how many days we've spent around this, we're unable to figure out a way to filter the view by the current post id without using nested shortcodes

#1893717

Minesh
Supporter

Languages: English (English )

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

Alternatively is it possible that instead of using relationships, we use a custom field for it? what we can do is add a custom field to the child post type. This custom field will collect the id of the parent post type. While displaying the list of the child post types on the parent post page, we can simply filter it to check if this custom field equals the parent post id.
==>
Yes, that could be possible but it will not influence the native Tooslet post-relationship as Toolset post relationship content/data will be stored in custom Toolset tables and in your case, if you create a custom field that holds the parent ID, the custom field value will be stored in postmeta table. So, if you go for custom field solution, that means you are dropping the idea of using post relationship.

So I figured that the only way to filter a view by current post id of the parent post type is by nesting shortcodes. Well, here we hit another wall. We have built this site using Oxygen Builder. So nested shortcodes aren't working. Can you please guide me around this? This is critical to the website's working and no matter how many days we've spent around this, we're unable to figure out a way to filter the view by the current post id without using nested shortcodes
==>
If you do not want to use nested shortcode, then you can use the view's API filter hook: wpv_filter_query using which you can modify view's query on fly and hook in any query argument, for instance, to filter post by current ID.

More info:
- https://toolset.com/documentation/programmer-reference/views-filters/#wpv_filter_query

#1893767

ftf: Thanks for a quick reply Minesh. appreciate it.

"... So, if you go for custom field solution, that means you are dropping the idea of using post relationship."

Yes. the relationship is not much use if it cannot be populated 'on the go' while creating the child post type by using Formidable Forms and all it is used for is listing the child post types on the parent post page.

"If you do not want to use nested shortcode, then you can use the view's API filter hook: wpv_filter_query "

So this I had explored before as well. However, in the link you've mentioned -> https://toolset.com/documentation/programmer-reference/views-filters/#wpv_filter_query and the example code given therein (posting below)

//Return only posts from the current author when listing posts of type company:
add_filter( 'wpv_filter_query', 'prefix_show_only_current_author' );
 
function prefix_show_only_current_author( $query_args ) {
    global $current_user;
    $types = (array) $query_args['post_type'];
    if ( !is_admin() && in_array( 'company', $types ) ) {
        $query_args['author'] = empty( $current_user->ID ) ? -1 : $current_user->ID;
    }
    return $query_args;
}

How does this snippet associate with a particular view? assuming that I will be posting this in either functions.php or code-snippets plugin? Any example you know which I can look at? Please correct me if am assuming or misunderstanding something. I was hoping that there is a standard way to define/call a function to ensure the code is applicable only to that view filter/query.

#1893775

Minesh
Supporter

Languages: English (English )

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

To target the specific view ID, you should use the below:

function func_your_function( $query_args ,$view_settings, $view_id ) {
    global $post;
     
    if ( $view_id == 99999 ) {
            //// your code goes here
         
    }
    return $query_args;
}
add_filter( 'wpv_filter_query', 'func_your_function', 10, 3);

Where:
- Replace 99999 with your original view ID.

You should add such custom hooks to "Custom Code" section offered by Toolset plugin:
=> https://toolset.com/documentation/adding-custom-code/using-toolset-to-add-custom-code/
OR
To your current theme's functions.php file:

#1893835

Thanks again for a super quick reply Minesh!

It's silly of me to have missed that. At the same time it is super nice of you to have laid it out for me for this as well as future requirements. Will set it up, test it and get back to you. Sincerely appreciate all the help here and loving it too, it's my first time I think I've raised a support query with toolset in all these years 🙂 The product is so powerful and ever evolving since I've started using it, never needed to bother the support team to be honest!

#1893839

Minesh
Supporter

Languages: English (English )

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

Glad to help 🙂

#1895299

Hey Minesh,

Thanks again for all the help, took me some time to figure out the optimum query parameters, but finally narrowed it down.

function func_cpnumcompare ( $query_args ,$view_settings, $view_id ) {
    global $post;
    global $postid;
    $postid = $post->ID;
  
    if ( $view_id == 2126 ) {
      // conditional code below
    $query_args = array(
    'post_type'  => 'cpchild',
    'meta_key' => 'wpcf-cpnum',
    'meta_value' => $postid,
);    
    }
    return $query_args;
}
add_filter( 'wpv_filter_query', 'func_cpnumcompare', 99, 3);

Sharing the code if it is useful for someone else. Also thanks for updating my knowledge about the custom snippet area toolset provides to add code snippets, was exclusively using a third party plugin till now.

#1895823

Minesh
Supporter

Languages: English (English )

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

Great, and glad that the hook I shared help you to resolve your issue.

Would you mind to mark resolve this ticket 🙂

#1896007

Although the resolution of the issue is complete. it's a workaround. and I wish to request the toolset team to reconsider bringing back the access to the post type relationships via a single field value, so that it could be accessed and updated by third party plugins like it was possible before migration by updating the wpcf-belongs-to-parent-post-type-id field. the API method could then get the value from this field automatically, or there could be a setting for a post type or post type relationships, to switch on the trigger to update the relationships via the field value update process, or you guys could think of something even better 🙂