Home › Toolset Professional Support › [Resolved] Error: The parent must be a post ID or a WP_Post instance
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 |
---|---|---|---|---|---|---|
- | 7:00 – 14:00 | 7:00 – 14:00 | 7:00 – 14:00 | 7:00 – 14:00 | 7:00 – 14:00 | - |
- | 15:00 – 16:00 | 15:00 – 16:00 | 15:00 – 16:00 | 15:00 – 16:00 | 15:00 – 16:00 | - |
Supporter timezone: Europe/London (GMT+00:00)
Tagged: Post-relationship
This topic contains 9 replies, has 2 voices.
Last updated by davidS-53 6 years, 5 months ago.
Assisted by: Nigel.
Problem 1: I have a view set up that shows a number of posts of type "safety-check".
WIthin the content template for the view results, I have a cred form called "log-item-add-new" that pops up in a modal. This creates new posts of type "log-item". Each "safety-check" can have many "log-item" - this is set up in the new relationships system.
I'm automatically setting the "log-item" parent to the current post in the view using this:
<div class="form-group"> <label>Safety Check Log Items</label> [cred_field field='@safety-check-log-item.parent' select_text='--- not set ---' value='[wpv-post-id]' use_select2="never" class='form-control' output='bootstrap'] </div>
You'll see in my attached screenshots that it's correctly selecting the right post parent.
However, when I hit submit, I get an error 500, the site goes to a url ending in &_tt=153068958, and I get an error in my server log "Backend fatal error: PHP Fatal error: Uncaught InvalidArgumentException: The parent must be a post ID or a WP_Post instance."
Problem 2: (probably minor so have included it here) On the form that pops up, the datepicker icon has disappeared.
Any ideas? Cheers!
Languages: English (English ) Spanish (Español )
Timezone: Europe/London (GMT+00:00)
Hi David
I have a simple version of something similar on a local test site. I'm not using modals, I'm just listing parent posts in a View and directly beneath the title for each I have inserted a Form to create a child post of that parent.
The cred_field shortcode is essentially the same as yours.
I couldn't reproduce the error that you describe, though I did find that it didn't seem to work correctly if I used ajax to submit the form.
Could you try a couple of things.
Test without ajax submission, does it submit correctly without errors?
Can you remove the attribute use_select2="never" (it should be redundant if your value is preset).
Any changes?
It would be helpful if you create a new test version of your View similar to mine, where you just output the safety-check title, and beneath it include the child post form.
That way we can abstract from—and rule out—and issues arising from your use of modals for the form.
Thanks for getting back to me Nigel.
Test without ajax submission, does it submit correctly without errors?
- I wasn't using AJAX to begin with, so rules that out.
Can you remove the attribute use_select2="never" (it should be redundant if your value is preset).
- Done, tried creating another one- no deal.
That way we can abstract from—and rule out—and issues arising from your use of modals for the form.
- Already on it- i've got the form directly in the content template for the safety check post type as well.
Also, strangely enough, now it isn't auto-populating the field in the modal popup, but it populates fine in the content template.
If it's any help,here's how I got told how to achieve this a while back (I have a personal account and a work account with you guys): https://toolset.com/forums/topic/automatically-set-post-parent-in-post-form-from-url-parameter/page/2/
Funnily enough I have a Boats -> Safety checks relationship that works perfectly fine...
Shall I send you a login? Cheers.
Languages: English (English ) Spanish (Español )
Timezone: Europe/London (GMT+00:00)
I had a quick look at that other thread, I'm not sure why you should need to add some code to make the post connections when that is precisely what the parent select field is for.
Yes, I'd better take a look at your site, let me mark your next reply as private.
Languages: English (English ) Spanish (Español )
Timezone: Europe/London (GMT+00:00)
I was struggling a little with the backend of your site so I'm taking a copy so that I can work on it locally which will be easier and quicker, and I'll update you again soon.
Languages: English (English ) Spanish (Español )
Timezone: Europe/London (GMT+00:00)
OK, I've hit an odd bumper here.
On your site it looks like it is working (parent is pre-selected in the parent field of the form) but is not (the parent isn't saved).
I made a simplified page and View to do some testing and I found—which I replicated on my own test site—that when using the table output format for the View if you include the cred_form shortcode within a td tag in the output template the parent selection works, but if you move it outside of the td tags (because you are opening the form in a modal) then it does not.
There is no logical reason I can see for this, so I've had to escalate this to get another set of eyes on it. I'll keep you posted.
You can go into a safety check and you'll see the log item form below it- that's the same form and last time I checked it wasn't working there either. The modals are bit of a pain to have- if it was up to me I wouldn't have any but unfortunately the guy im building the site for wants them.
Keep me posted- cheers!
Languages: English (English ) Spanish (Español )
Timezone: Europe/London (GMT+00:00)
My colleague took a look at this and confirmed my findings, that the parent-post selector in a CRED form is broken if you insert the form shortcode outside of the td tags when using table format for Views output, but that it works if you move the form shortcode within td tags.
That was on a vanilla test site, and I found the same when testing on your site.
So, the Form in question is "Log Item - Add New".
It is inserted in the View "Safety Checks". I experimented with moving the cred_form shortcode inside one of the existing td tags.
I inserted the View on a test page "Toolset Test", and I also switched theme to twentyseventeen to facilitate a clean test, and I was able to submit log items without problem. (Ignoring how ugly this looks, not using the forms in the modal.)
I then repeated the test switching to your child theme, and this time I got the problem you initially reported, which is a fatal error in the log, and the page stuck with the tt URL parameter.
I then repeated the test after switching to the parent theme, and this time it worked fine, as with twentyseventeen.
So, the fatal error you describe comes from your child theme, you'll need to revise the code you have added there to see if you can identify/isolate what might be the cause.
And then there is the other issue I stumbled across about forms outside the td tags.
You might need to see if you can still get your modals to work if you include the cred_form shortcode inside td tags. That issue has been reported and the developers will look at it, but I would expect it to take a while before any resolution is published.
The real issue you have—the one reported—is with the error generated by something in your child theme.
If you find something there that you think we need to look at, let me know.
Languages: English (English ) Spanish (Español )
Timezone: Europe/London (GMT+00:00)
I have two bits of feedback, one from the developers that it should not be expected to work, another from a colleague that you can try where it might work.
The issue arises because the form is being inserted in a table row, but outside of the td cell. The only HTML-valid content for table rows are th and td cells. The form inside a td cell inside a row is valid. The form outside a td cell inside a row is invalid.
Each browser has its own means of attempting to fix this broken HTML, which is further complicated by the use of JavaScript libraries (such as select2) which are used for certain form fields, such as the parent post selector.
The short answer is it won't work.
That would be the end of it but a support colleague thinks it may work if instead of grouping the fields in a content template that the Loop Output inserts, you include all of the required fields directly in the wpv-loop block. The official position is that it doesn't work, but you are welcome to try that.
So, what you can do instead is find a different solution than the modals for the forms, or continue with you current solution but instead of using a table-based output, use a grid output with necessary CSS adjustments to achieve a table-like layout that doesn't actually use table HTML elements.
Hi Nigel,
Sorry, has taken me a little while to get back to you. Here's my update: I have gotten rid of the modals- that's not a problem. The forms now exist on the content template pages (see screenshot).
However, the post relationships still don't work properly.
Here is the problematic block of code:
add_action('cred_save_data','func_custom_post_title',15,2); function func_custom_post_title($post_id,$form_data) { if ($form_data['id']==243) { toolset_connect_posts('boat-safety-check',$_POST['@boat-safety-check.parent'], $post_id); } if ($form_data['id']==302) { toolset_connect_posts('safety-check-log-item',$_POST['@safety-check-log-item.parent'], $post_id); } }
With that code commented out: the post form submits & redirects, but the relationship isn't saved.
With that code active: the post form doesn't submit correctly, returning The parent must be a post ID or a WP_Post instance error.
I then swapped the site over to 2017 to test the form without any of my custom code: post form submits & redirects, but relationship still isn't saved.
I've then disabled all plugins apart from the toolset ones, and it still doesn't save the relationship. I'll leave it in that state so you can take a look and work out what the issue is?
Cheers!