Accueil › Toolset Professional Support › [Résolu] WordPress hierarchy in custom posts
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 |
---|---|---|---|---|---|---|
- | 9:00 – 12:00 | 9:00 – 12:00 | 9:00 – 12:00 | 9:00 – 12:00 | 9:00 – 12:00 | - |
- | 13:00 – 18:00 | 13:00 – 18:00 | 13:00 – 18:00 | 14:00 – 18:00 | 13:00 – 18:00 | - |
Supporter timezone: America/Jamaica (GMT-05:00)
Marqué : Content-submission forms, Toolset Forms
Documentation connexe :
Ce sujet contient 75 réponses, a 2 voix.
Dernière mise à jour par Shane Il y a 5 années et 6 mois.
Assisté par: Shane.
Hi Geoff,
Is the function working fine for the other forms? I see here that the form ID is different.
Remember that the function is specific to the form, so if its not getting the data it needs then it wont work.
For e.g here
https://toolset.com/forums/topic/wordpress-hierarchy-in-custom-posts/#post-1237346
As you can see the form ID's are different. Does the function still work for these forms?
Please let me know.
Thanks,
Shane
Hi Shane
I think it's a global issue as there are other similar forms that used to work and no do not..even when I change the form number...
Regards
Geoff
Hi Geoff,
That is strange as nothing was done to the site and it was working before. Usually in a case like this . I would go through one by one again.
Removing all the existing functions and testing each individually. The good thing is that we know what was causing your initial issue of the duplicates but now we don't know what is causing your functions to stop working.
So I would remove them again and test them. Secondly if you have installed any plugins or updated any plugins I would recommend disabling those as well while performing the test.
Thanks,
shane
Hi Shane
It's still not working...so I have drawn a detailed description of what I'm trying to do..perhaps you can tell me if you notice something not right...
I'm trying to do 2 things:
1. Create a parent of a child from an existing record
2. Create a parent of a child from a new record
Best regards
Geoff
Hi Geoff,
Sorry for the late response as my shift had closed.
Checking on this for you now.
Thanks,
Shane
Hi Geoff,
I'm tracing through the diagram and testing as I go along.
First thing I want to confirm is that the $user_will_url is this correct lien caché
That is just an example.
After filling out the form here.
lien caché
I was redirect as according to the hook that you have for this form, so this hook works.
So it seems from further checking, the id's from your diagrams are not the ID's of the forms. For e.g your Create new Guardian form here.
lien caché
The ID is 1797, in your diagram you have it as 1787. Then checking the corresponding hook based on the function name, this is what I see.
add_action('cred_save_data','func_update_parent_field',10,2); function func_update_parent_field($post_id,$form_data) { if ($form_data['id']==4049) { wp_update_post(array('ID' => $_REQUEST['child_post_id'], 'post_parent' => $post_id )); update_post_meta($_REQUEST['child_post_id'],'wpcf-adopted',$_POST['wpcf-adopted']); } }
Where the form id is 4049, however based on your forms the actual ID of the add guardian form is 2613
So it seems your ID's are not matching the actual forms based on the hooks being used. This is just one example of what I could find.
You're more familiar with this setup than I am so I could've just looking at the wrong Items but this is where I would start. I would ensure that the ID of the hook matches the ID's of the forms themselves.
Thanks,
Shane
Hi Shane
Thanks for getting back to me...
In answer to your questions:
Yes, $user_will_url is correct...This is the unique url of the users only CPT USER_WILL
And on this page lien caché
The form is ID: 1787 as in the diagram)I have attached a screen shot..the form slug is create-new-guardian
And the relating hook is as below: (I've just simplified it to one form for testing purposes)
add_action('cred_save_data','func_update_parent_field',10,2); function func_update_parent_field($post_id,$form_data) { if ($form_data['id']==1787) { wp_update_post(array('ID' => $_REQUEST['child_post_id'], 'post_parent' => $post_id )); update_post_meta($_REQUEST['child_post_id'],'wpcf-adopted',$_POST['wpcf-adopted']); } }
So it should work ....right?..But it doesn't
I shall look forward to your wizardry!
Speak soon
Geoff
Hi Geoff,
Something off is happening here.
Your layout is saying that the form is the "Create New Guardian form" with the ID 1787, however on the frontend the form's id is "2613" which is the "Add New Guardian" form.
Try your code like this .
add_action('cred_save_data','func_update_parent_field',10,2); function func_update_parent_field($post_id,$form_data) { if ($form_data['id']==1787 || $form_data['id'] == 2613) { wp_update_post(array('ID' => $_REQUEST['child_post_id'], 'post_parent' => $post_id )); update_post_meta($_REQUEST['child_post_id'],'wpcf-adopted',$_POST['wpcf-adopted']); } }
Please let me know if this one works.
Thanks,
Shane
Hi Shane
Ok this really is weird..The code you sent over pointing to both forms now works... So why is this happening...and what is the solution?
Also how can I find out what ID the front end form actually is?
Best regards
Geoff
Also Shane...when I try to repeat the step from page 'guardians' i.e. click 'Choose/Change Parent' to change to a new guardian I get different PEOPLE sent through...it alternates between:
lien caché
lien caché
So consequently the new parent doesn't get attached to the child
Here is the actual pattern of urls when repeating the step:
lien caché
lien caché
lien caché
lien caché
lien caché
lien caché
Hi Shane ..Hope you've had a great weekend.
Firstly apologies for the multiple posts to you..I've just been adding my additional thoughts since we last spoke.
Obviously there is still the problem of why I reference one form ID in the layout and get another form ID on the front end...but also I think the WordPress parent/child hierarchy is causing issues as mentioned above.
When on the Guardians page the a href link when choosing the child is created by the slug of the child selected..so for example this could be lien caché
However when a parent has been assigned the slug of the child has changed to lien caché
And I think this is what stops you assigning a new parent...I think I need to either display the slug without the parent extension or somehow remove the parent first before assigning the next..
This is something that I need to sort out fairly quickly as it is holding up an already delayed development timeline. Also this is a singular form but I need to repeat this parent/child adoption for many other variants of PERSON CPT e.g. Child needs a guardian, Pet needs an Owner, Gift needs a Beneficiary... Child, Guardian, Pet, Owner, Gift and Beneficiary are all PERSON CPT to allow me to create this parent/child relationship...
Is there a time of day when we can speak on the live chat to try and sort this out as waiting 24 hours each time between messages is taking too long..
Very best wishes
Geoff
Hi Geoff,
This is a very complex case and i'm not sure of the available times.
However i'm available for a chat now to check this for you. For the ID's of the form on the frontend all i do is check the page element.
Take a look at the screenshot where you see cred_2613, the 2613 is the ID of the form.
Thanks,
Shane
Hi Shane
Ok We will have to work through the problem piece by piece when we can..
So firstly the problem with why the front end for is displaying differently with the view...
Can you access the back end and take a look?
Best wishes
Geoff
Hi Geoff,
Let us work it through hook by hook if possible.
You can send me the page and the hook that is corresponding to the forms, from there I will have an idea of where to look.
Thanks,
Shane
Hi Shane
An example would be the page:
lien caché
Where it used the layout: People New Guardian and within the layout sits the form Create New Guardian (ID: 1787) - But on the front end it seems to use the form ID 2613
Perhaps if you could look at why this is happening first please...
Regards
Geoff