Hi Beda,
thanks for looking at this.
I'm not sure why you got the error you mentioned above
the link is working on my end
for the ftp login please dont use a folder name for login path just use the domain name
I'm not expecting you to debug the functions code I have in place. each function is working just fine.
the current priority priority setting I have are as follow:
add_action( 'save_post', 'calculate_fields', 99 );
add_action('cred_save_data', 'net_worth_calc',10,2);
add_action('save_post', 'calculate_li_need', 99);
add_action('cred_save_data', 'li_calc',10,2);
do I need to chance the above?
the main problem is How to call function B (to run on child post) inside function A (the parent function)
I think the only parameter to pass is just the child post id
I will try to explain the issue in a simple way in the below example
function calculate_parent ($post_ID) {
run calculation code // this is working fine and no need to debug it
// update child post from inside the parent function
run the code to find the child posts // we have this in place
call the child function to run on the child post by providing the child id (I think) // this is where the issue is
}
function calculate_child ($post_ID) {
run child calculation by get parent custom post fields values // this is working fine
}
the current update child post code I have inside the parent function is (where function calculate_li_need is the function calculate_child in the above example).
// find child post - life-insurance-need type and update
$child_posts = types_child_posts('life-insurance-need');
foreach ($child_posts as $child_post) {
$post_ID = $child_post->ID;
calculate_li_need ($post_ID);
}
but I'm not sure if this is how to call the child_calc function to run from the parent. this is the major issue.
I know how to get the child posts, I know how to get the child id. but not how to have the child_calc function run on the child post from the parent calc function.
I hope this is more clear.
David
You can define the Function anywhere and then simply call it wherever you want.
This is basic PHP, it has nothing to do with Toolset.
A Function is defined with "function your_func(){ code here}" and the called with "your_func();"
I created a simple dummy function that does exactly what you need:
function my_func( $post_id ) {
$parent_field_value = get_post_meta($post_id, 'wpcf-single-parent-field', true);
$child_args = array(
'post_type' => 'toolset-child',
'numberposts' => -1,
'meta_query' => array(array('key' => '_wpcf_belongs_toolset-parent_id', 'value' => $post_id))
);
$child_posts = get_posts($child_args);
foreach ($child_posts as $child_post) {
$child_id = $child_post->ID;
update_post_meta($child_id, 'wpcf-child-post-line', $parent_field_value );
}
}
add_action( 'save_post', 'my_func', 50 );
Also we can use the Types API:
function my_func( $post_id ) {
$parent_field_value = get_post_meta($post_id, 'wpcf-single-parent-field', true);
$child_posts = types_child_posts('toolset-child');
foreach ($child_posts as $child_post) {
$child_id = $child_post->ID;
update_post_meta($child_id, 'wpcf-child-post-line', $parent_field_value );
}
}
add_action( 'save_post', 'my_func', 50 );
This updates the child Field value flawlessly, you can try it.
If your custom Functions are not working we cannot debug this.
I used Priority 50, and reported to the DEV to increase the suggested 20.
Hi Beda,
I think we have misunderstanding here. I might not explained myself correctly.
what you describe in your last comment is very clear to me and this is how I implemented all my functions and they work just fine. this is not the issue I'm facing. calling a field from a child or parent post to run some calculation on is something I do already with no problem. also the update meta is something I do with no issue.
now think of a scenario where I have 2 correctly defined functions. one is for the parent and the other is for the child, each function calculate numbers related to its own post.
in my scenario a user create a parent post and calculate it using the add action save post as you describe above. than he create a child post with some calculation that call values from the parent post. same here, no issues whatsoever the calculation are working flawlessly.
now here is the interesting thing in the scenario:
the user can go back and change values in the parent post and save it.
the issue - if he doesn't go to the child post and click save (so the function that calculate the child will run again) the child post values are the old ones and are not accurate.
so what I'm trying to do is to call the child function inside the parent function to run the calculation. I dont want to update just one field in the DB with the update meta option. I want to run the child function as if I was doing save post on the child when the parent post is saved.
I hope that this remove the misunderstanding on the scenario.
when I use cred_save_data as follow the child post calculation is working perfectly.
add_action('cred_save_data', 'li_calc',10,2);
function li_calc($post_id, $form_data) {
// if a specific form
if ( $form_data['id'] == 1744 || $form_data['id'] == 1748) {
calculate_li_need( $post_id );
}
}
I see that the line
calculate_li_need( $post_id );
is calling the child post function just fine.
now, the question is can I take this line and put it at the end of the parent function so it will update all its childs?
and I know we need to find all the child's first and than do foreach to get the id....
or in other words if my child post # 1234 I can use
calculate_li_need( 1234);
to update the child post and if this is how I will call it in the parent calc function?
David
You do not use CRED API when you want to do things in the backend.
Please specify where this should happen. On the Front end or in the Backend?
Independent from that, your function calculate_li_need() - off correctly programmed - can be called in the for each just like the update_post_meta() example as I show it above.
This will work, if the function calculate_li_need() does what it is supposed to do.
I cannot tell you if you can pass $post_id to that function.
It that function expects and handles a variable like that, and the variable is populated in a way that the function calculate_li_need() can process and use, then yes.
But this is related to your custom function - and if it is correctly coded it will work, just as it works in the update_post_meta() function which is programmed to receive a value to replace $post_id - it has to be a number, the Post ID.
The function is usually not populated with a hardcoded 1234 value but with a variable that takes the post id from the foreach that delivers all your post objects.
Hi Beda,
I use CRED API for front end interaction of the user.
no user have access to the backend.
my hard coded example was just an example. I'm not expecting the function to be hardcoded.
I was hoping that toolset will have some examples on how to do what I need to do, calculation across posts with relationship.
I'm sad we couldn't find a solution for this. this means manual work and errors. I guess I will have to continue to debug the function I have in place. I will continue to search for a solution.
Thanks,
David
Yes, this cannot be solved by Toolset Support, because it is Custom Code.
We analyzed the parts that are affected and dictated by Toolset.
The special part here is that if you use the code in the backend, which you repeatedly suggested by mentioning the save_post() action, you need a higher priority that usual (20 suggested or higher).
That is the only special part about Toolset and PHP on save_post().
Now, if you use CRED, you do not, never, hook in save_post() but instead CRED provides it's own hooks and filter.
These are elaborated here:
https://toolset.com/documentation/programmer-reference/cred-api/
I suggest, if you do this things on the front end only then use cred_save_data()
It works exactly like the save_post() action but you do not need to worry about priority.
And, you can use the provided variables too:
post_id. The id of the current created or edited post.
form_data. An associative array of data about current form:
form_id. The form ID.
post_type. The post type that the form operates on.
form_type. The type of the form (create or edit form)
These are very helpful so you can always fall back to the current edited or created post object and form data.
Please let me know if I can be of any more help with the Toolset API.
In future we will have public library of some code samples, but this will not include Custom Code Debugging.
For that, we suggest to contact the contractors:
https://toolset.com/contractors/
Contractors are very experienced Toolset Developers that also know (eventually) the PHP or other languages to extend Toolset's functionality that we cannot support in the Forum.
These Contractors are external, we are not affiliated, we just provide the contact and then step back.
This very unfortunate!
I dont think you understood the issue as you default to the same answer.
I work with CRED api for front end, you dont need to repeat this over and over again as if I didn't say it already. it makes me think you didn't read my comments.
I am one of the contractors on your site and stated it before in the thread. have you seen this comment?
I'm not asking for you to write a custom code for me. I can do it myself. as I'm not an "expert" I just need a small help and guldens with understanding the correct way of doing what I need to do.
the toolset support is full of examples of code you and others wrote to help me and others understand how to extend toolset using php code. and its great to see it. I was hoping the toolset support could have done the same here. provide the high level example. from there I can take it and modify it / adjust it for my need.
I wish you all the best and hope that in the future we will be able to find a solution.
Thanks,
David
Yes, I understood this.
But the CRED API and the save_post are not the same. I gave concise instructions on how to use both, with the Toolset API.
If this is not clear, please ask me so I can sort out the remaining doubts in regard.
I also know that you are listed as a contractor, I have seen your comment you posted in past.
I have discussed this with my superiors as well
Contractors - that list is intended to host Developers or other Users of Toolset that like to provide their work to other Users.
We cannot provide the custom code to the Contractors.
Eventually we will also add a specific kind of support for the Contractors - in future.
For now, we serve every client or User of Toolset according our Support Agreements.
We do of course always explain how to use the API, we debug it, we find issues due to that and fix them.
In your above concern there is no BUG spotted. I elaborated on the usage and limitations. But I cannot elaborate on the usage of custom functions that are not deepening on the Toolset.
If they do, I can elaborate on the details of those dependencies.
I also provided you a high-level example, elaborating with comments how things work in the Custom Logic.
We never provide custom code that is not related to Toolset. Snippets and examples you find on this forum are usually tightly knotted to Toolset API or it's components and are usually a generic example.
I apologize that you have been unsatisfied with my Support.
