Thank you for the details. Now, I see what you are talking about.
It is the same issue and can be fixed with the same solution, moving the modals out of the table. The following code did it:
(function($){
var table = $('#wpv-view-layout-52 table');
table.find('.modal').insertAfter(table);
})(jQuery)
AH! Perfect thank you Jamal!
I was being dumb and adding it to the wrong place!
One final question if I may, it's partially related and has been mentioned in the thread before, but now these are working, how can I pass these forms the current parent in the loop so that the relationship dropdown is preset to the current parent as it's default value?
Sure. It just needs to add the value argument to the relationship field shortcode. We'll pass the current post in the loop, which we can get with the [wpv-post-id] shortcode:
[cred_field field='@parent-child.parent' class='form-control' output='bootstrap' select_text='--- not set ---' required='false' value="[wpv-post-id]"]
That's it, I knew it was something like that, but I've been really struggling with your new documentation as it seems to have removed all of the finer details about how lots of these things work for some reason!
The only thing is that if the form is called from the archive page or anywhere outside of the loop, that then pulls in the id of that page so it populates incorrect data in those situations.
If the archive has an ID of 33, then surely I can just exclude it like this, right?:
[wpv-conditional if="( $(wpv-post-id) eq '33' )" ][cred_field field='@parent-child.parent' class='form-control' output='bootstrap' select_text='--- not set ---' required='false'][/wpv-conditional]
[wpv-conditional if="( $(wpv-post-id) ne '33' )" ][cred_field field='@parent-child.parent' class='form-control' output='bootstrap' select_text='--- not set ---' required='false' value="[wpv-post-id]"][/wpv-conditional]
That way if the ID is 33 it will generate the field without the value, and if it's not equal to 33 then it will generate the field with the value set.
I've only tried it once, and it hasn't worked, but it's late so I'll test it more tomorrow although if you can spot what's wrong I'd appreciate it in the mean time.
Thanks again for the help.
This is right The only thing is that if the form is called from the archive page or anywhere outside of the loop, that then pulls in the id of that page so it populates incorrect data in those situations.
But, I don't think that the conditional code where you check against the archive template ID is a good idea. There must be a better way. So, I need to ask, why would you put the same form in the archive template outside of the loop? I would expect that you will use a different form, why would you use the same form?
Can you give more details?
The simple answer is flexibility. At the moment we are gradually building up the functionality we want present in the system and a lot of functions will move around as we develop it. Creating a child post type against a parent is the most obvious solution, but it could also be useful to add this from a main menu for example.#
You're right, I could use a different form, but it would be a duplicate apart from that one value being pre set. So before creating a identical form with only one tiny difference, I thought I'd see if it was possible to manipulate this one to the situation as it felt more efficient to only have the one form that was more flexible so to speak.
Hopefully that makes sense. But like I said, things are still very early on and developing as we go.
I understand now. Thank you!
The wpv-conditional shortcode is not guaranteed to work inside a form in the same way it works inside views or content templates.
And the conditional system of Forms relies on custom fields rather than default fields(ID, status, type, date, etc.)
I would suggest building a custom shortcode that will detect if the form is inside the loop, an archive, or a regular page, and if it is not inside the loop, it should return an empty string. If it is inside the archive loop, it should return the post's ID.
To detect what is the context, you should rely on the post ID and the post type. An archive page, either if it has an ID when using Toolset archives, does not have a type. Does it make sense?
