I'm building a site using the latest Toolset plugins. I have two posts that have a one-to-many relationship. In the create version of the child form, the parent selector is hidden and I'm modified it slightly from this:-
[cred_field field='@posta-postb.parent' select_text='--- not set ---' class='form-control' output='bootstrap']
to this:-
[cred_field field='@posta-postb.parent' select_text='' class='form-control' output='bootstrap']
so that the child post is automatically assigned to the parent post via which it was created. Where I have added this shortcode:-
[wpv-post-title item="@posta-postb.parent"]
in a View and in email notifications, the custom field content isn't displaying and when I look at the child post in wp-admin, no details of the parent post are showing for the child post (and vice versa).
I've tested the child form on the front end with the parent selector visible and the correct parent post is automatically selected each time. I've checked the _toolset_associations table in my database and the child post is being associated with the correct parent post.
Oddly, when I perform the same exercise with a one-to-one relationship, I get the same results EXCEPT I can see the associated parent post when I look at the child post in wp-admin (and vice versa).
I'd love to provide you with links but this is a test site that's completely locked down and I don't have a live site using the latest set yet.
Please advise.
Hi, the parent post cannot be automatically detected - you must use either the value attribute or the urlparam attribute on the parent Form field to specify the parent post ID.
When you use the "Create Child Post" shortcode, the link generated by the shortcode includes the parent post ID as a URL parameter. See create-link.png. In this case, you must add the urlparam attribute to the parent field shortcode, and point to the correct URL parameter, like parent_posta_id. This parameter will vary based on your post type slugs, so you can click the generated create child post link to see the correct parameter appear in the URL. Copy that parameter name into the urlparam atttribute:
[cred_field field='@posta-postb.parent' select_text='' class='form-control' output='bootstrap' urlparam='parent_posta_id']
If you're not using the Create Child Post shortcode, you can use the value attribute to define the parent ID some other way. For example, if the child post Form is placed directly on the parent post page, you can set the value using the [wpv-post-id] shortcode:
[cred_field field='@posta-postb.parent' select_text='' class='form-control' output='bootstrap' value='[wpv-post-id id="$current_page"]']
Hi Christian
I am SO confused right now for a variety of reasons.
I have never ever had to add either a value or urlparam attributes to parent selectors. I'm using the 'create child post' shortcode in a view which selects the parent post type. When I select 'create child post link' as shown in your image, I've selected the option ' Set the parent according to the currently displayed content' and this is clearly working because the correct associations are set in the d/b table.
Nevertheless, I have tried it your way (both) but there's no change (the custom field values from the parent are still not displaying after a child post has been created).
Please advise
PS: Can you provide a link to the documentation about creating child posts on the front end please?
Thanks
Hi Christian
An update:-
I've set up a complete new install with minimum customisation and only toolset plugins plus recommended theme. Custom field values are displaying (in a View at least ; I haven't tried emails yet) so something's not right with my other install.
On the other install, the custom fields I'm using are 'post fields' from an older site which I exported using Module Manager (previous version) and imported via Module Manager (latest version). Do you think this could be why custom field values aren't displaying?
Many thanks
Not sure offhand, but I'll be glad to take a closer look. May I log in and create a clone of the site where you're experiencing the problem?
Hi Christian
I really appreciate the offer to look at the install. I've since taken that install offline and am working on a fresh re-build in its place (it's a dev site). I'm not importing anything I've previously captured using module manager or WordPress importer. I've set up a basic form and a view with a post edit link displaying the parent post title and this is working as expected now.
That's the good news.
I've just settled down to creating more forms and I've noticed that whereas ALL cred fields used to contain class="form-control", now they don't. It seems to be the radio fields that don't. Is this expected?
Hi again Christian
After working on this vanilla install further, I've reached a point where yet again the value from the parent post fails to display. This time however I've managed to work out that the issue is to do with the child post status. If this is set to pending when the child post is created, the custom field value from the parent doesn't display. In my install, the parent post status is 'publish' (I haven't checked to see what happens if it's draft or pending). .I've checked the database and the association between the child and parent post is set even though the child post status is pending.
It doesn't make sense to me that the parent post custom field value isn't displayed if the child post status is pending.To demonstrate this with a real-life example, if someone had a website where people could book one of two holiday homes and wanted the booking to show as 'pending' until deposit money was received, they wouldn't be able to show their customer which holiday home they had booked.
Can you escalate to have this changed please?
I have never ever had to add either a value or urlparam attributes to parent selectors.
You're correct - I was confused about this. My apologies. This scenario should work without using urlparam or value.
This time however I've managed to work out that the issue is to do with the child post status. If this is set to pending when the child post is created, the custom field value from the parent doesn't display.
Okay yes, there is currently a known issue where the Post Relationships API is not displaying information about parent posts when the child post status is anything other than "publish". Our developers have acknowledged this as a critical issue and are working on a resolution, but I do not have a timeline available just yet. I will be glad to update this ticket as that work progresses.
My apologies
No worries; we all have our 'off' days 🙂
there is currently a known issue
I couldn't find anything in the 'known issues' list. Can you provide a link to it please? When was the issue first discovered?
I've now noticed something else. I use cred_save_data hook to update the post title of the child post with the post title of the parent. Before the recent upgrade, when the child post status changed to 'publish', the post slug would update and be based on the child post title. Now though the child post slug is based on the cred-auto-draft slug. Is this being addressed too?
Have you been able to ascertain the situation re the cred field for radio types? (My post on June 8th).
Many thanks
Types 3.0.1 is now available, and includes a fix that should resolve the issue where you cannot access parent post information from within a pending child post. Please find the latest version at https://toolset.com/account/downloads and retest the issues related to getting or setting parent and child post information.
I couldn't find anything in the 'known issues' list. Can you provide a link to it please? When was the issue first discovered?
No erratum post, but this issue can be seen in the changelog for Types 3.0.1 https://toolset.com/download/toolset-types/#changelog. The first report I found of this issue was May 27.
I'm splitting your question about radio controls and the form-control class into a separate ticket now.
I'm splitting your question about radio controls and the form-control class into a separate ticket now.
Thank you - I'll wait for your input.
Thanks for advising me about the update to Types. It's so frustrating when an erratum isn't published; I have spent hours and hours re-writing my site convinced that, in the absence of an erratum and no other forum posts to suggest others were having the same issue, I must have got something wrong. If I had known the issue was 'known', I could have actually taken the weekend off instead of sitting at my desk. Everything feels so chaotic @ Toolset right now. I hope the lack of erratum is just an oversight on this occasion and not what we can expect in the future?
Sorry for the trouble this caused, I can understand how losing a weekend is frustrating. From what I can gather, the issue was not considered an bug. It was technically considered a new feature, for which we do not publish errata. The toolset_get_related_post API is built on top of WP_Query which by default returns only published posts. There were no parameters built into the original toolset_get_related_post API to override that default setting, so if anywhere, the oversight was in the original API plans. We don't publish errata for improvements or feature requests, so the only way this issue would have been noticed is if you had seen other information here in the forums.
Hi Christian
The official line may be that this 'behaviour' wasn't a 'bug' because it relates to a new method of data retrieval but we are essentially still talking about post relationships and that is not a new feature. IMHO if data output changes as a consequence of implementing an update, this will cause 'issues' and so the behaviour belongs on the 'known issues' list as a way of keeping us informed. It's just about good customer relations and ultimately means we're all being more efficient than if the information wasn't shared.
I've tested using types 3.0.1 and am pleased to confirm that custom field values from parent posts ARE now displaying even if the child post status isn't 'publish'.
I've noticed something else though:-
When a child post is updated via wp-admin, alerts/warnings appear as shown in the attached image. The fields referred to in the image are 'required' parent post custom fields. I noticed this in Types 3.0 but wanted to check again after upgrading to 3.0.1 . Please advise/let me know if you want me to raise a separate ticket.
Thanks
Let me know if you would like to keep this ticket open.
I'm putting back into this thread my response to your post #911950 in this topic:-
The official line may be that this 'behaviour' wasn't a 'bug' because it relates to a new method of data retrieval but we are essentially still talking about post relationships and that is not a new feature. IMHO if data output changes as a consequence of implementing an update, this will cause 'issues' and so the behaviour belongs on the 'known issues' list as a way of keeping us informed. It's just about good customer relations and ultimately means we're all being more efficient than if the information wasn't shared.
I've tested using types 3.0.1 and am pleased to confirm that custom field values from parent posts ARE now displaying even if the child post status isn't 'publish'.
Thanks for extracting the issue with the radio fields into a separate thread.
I'll close this now.
