Before the cred_save_data is completed I run a test query (below) to check for existing relationships, at which point some should have been removed, but they are not. This means that when I fire the same query on cred_submit_complete, the removed relationships still appear as connected.
$trip_event_relationships = toolset_get_related_posts(
$post_id, // get posts related to the current post
'trip-event', // slug of the relationship between the posts
'parent', // role of post to query by
100, 0, // pagination
array(), // Additional Argumants
'post_id', // what to return
'all' // role of the post to return
);
When checking in wp-admin after the form submission I see that the relationship was successfully removed, so why are the removed relationships still appearing as connected after toolset_disconnect_posts on cred_save_data and on cred_submit_complete?
Please only make changes to the Duplicator version of the site, not the Live site.
To recreate the issue, log in and go to /trips/5499/ where you'll see the relationship/s appear in two key places (see attached screenshot 'Relationships - Before') where the Turku event correctly appears in the table and in the paragraph text. In a new tab, view the post in wp-admin to confirm the 'Trip Events' relationships assigned.
In the original tab (the front-end view of the post) click the 'edit' link (See bottom left corner of 'Image 1') to edit via the CRED form. Scroll to the field titled 'Does this Trip BEGIN at any Events?' and then scroll to the bottom of the checkboxes list underneath it where you'll see the Turku event selected (see screenshot 'Form Field'). De-select this event, then save the form.
You'll then be redirected to the post, where you'll see that the Turku event has disappeared from the table but not from the paragraph text (see screenshot 'Relationships - After'). The table is generated in a content template, so reflects the fact that the relationship was removed (as can be seen in wp-admin) but the paragraph text is generated and saved on cred_submit_complete, where the relationship should have already been removed but in fact has not.
The relevant functions in functions.php are ahoy_save_trip_relationships and ahoy_trip_generate_text.
Thank you for contacting us and I'd be happy to assist.
During troubleshooting on your website's clone, I noticed that in the function "ahoy_trip_generate_text", the initial call to "toolset_get_related_posts" is requesting "all" and not "child" items, which brings the "intermediary" posts in the focus as well:
$trip_event_relationships_on_cred_submit_complete = toolset_get_related_posts(
$post_id, // get posts related to the current post
'trip-event', // slug of the relationship between the posts
'parent', // role of post to query by
100, 0, // pagination
array(), // Additional Argumants
'post_id', // what to return
'all' // role of the post to return
);
Changing the "all" to "child" returns the correct IDs of the connected posts, in this "cred_submit_complete" hook function:
$trip_event_relationships_on_cred_submit_complete = toolset_get_related_posts(
$post_id, // get posts related to the current post
'trip-event', // slug of the relationship between the posts
'parent', // role of post to query by
100, 0, // pagination
array(), // Additional Argumants
'post_id', // what to return
'child' // role of the post to return
);
I hope this helps and please let me know if you need any further assistance around this.
The setting of "all" is required because I need the return to be [ 'parent' => 43, 'child' => 57, 'intermediary' => 135 ], allowing me to then access custom fields in the child and the intermediary at the same time.
Does toolset_disconnect_posts delete the intermediary, or do I need a separate action to delete the intermediary?
In my tests, the intermediary post is not deleted when a connection is broken through the "toolset_disconnect_posts" function. I've shared this with the concerned team for further review on this.
I also tried deleting the relevant intermediary post right after "toolset_disconnect_posts( 'trip-event', $post_id, $remove_relationship );" in the "ahoy_save_trip_relationships" function, but it still seems to fire too late for the "ahoy_trip_generate_text" function.
Based on this, you have the following options:
1. You can call only child items through the "toolset_get_related_posts" function as suggested in my last reply and then call the relevant parent and intermediary posts separately, to get field data from them.
OR
2. You can restructure your custom functions so that the paragraph text is updated/generated at the same level as toolset_disconnect_posts ( i.e. toolset_disconnect_posts( 'trip-event', $post_id, $remove_relationship );).
Based on your feedback I was struggling to figure out how to restructure the code around the options you gave, but in the process I found a third option.
The data that I needed to access the intermediary for is available (without the intermediary) based on the form field being used (out of the 4 available), so I am now accessing the form field values (as they are up to date) for this data instead of querying for relationships (which aren't updated in time).
This is tested and appears to be working correctly.
My only question is: is it good practice to use $_POST on cred_submit_complete or would you advise against this? Example below:
Thanks for the update and this third option is indeed much neater and simpler.
I would pick the option of using the data from the $_POST global variable (whenever it is available) always over getting it through functions that call it from the database, as it saves database queries and is, therefore, more beneficial in terms of performance.
Also thanks to your report, the issue of intermediary posts not getting deleted through the "toolset_disconnect_posts" function has also been accepted to be fixed in future releases.
Glad to hear that issue has been accepted for a fix, and thanks for your help - based on your last response I see that I have the potential to increase performance by switching to $_POST instead of using database queries on cred_submit_complete - I hadn't considered that before.
This ticket is now closed. If you're a WPML client and need related help, please open a new support ticket.
