Skip Navigation

[Gelöst] Parent post field value condition

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.

This topic contains 3 Antworten, has 2 Stimmen.

Last updated by Ljuba vor 3 Jahre, 5 Monate.

Assigned support staff: Nigel.


==> Tell us what you are trying to do?

I have some fields in parent posts with values of importance for child posts. Example > Hotel in Policy section have question "Hotel accept children?" what should to determinate in grandchild post of the Beds (child is Room) availability of the fields (entire set of fields) related to children.

Toolset approach to conditional logic is quite complicated (complex) and I already found the problem with backend of the grandchild conditional logic ("fields act as the want" > sometimes display sometimes hide???).

So, I have idea and I need advice. Obviously, here are two kind of issues:

1) First must to be created parent and grandparent posts.
2) Fields logically should to be mandatory, but ... (here is idea).

Question is related to fact that clients will not have access to backend.

So, if I will disable mandatory of the fields, for me looks that I can theoretically to 'cut the road' (quit the queries) related to backend relationships and conditional logic, and to use conditional logic only in CRED (where I can also to set mandatory for not mandatory fields).

Can it working or not?

P.S. Thinks are much more complex as here will come also if Hotel have family rooms or any of Family Taxonomies, so ......brrrrr (huge headaches)



Languages: Englisch (English ) Spanisch (Español )

Timezone: Europe/London (GMT+00:00)

If you have a workflow where your users will have already set the field value on a grandparent post ("accept children?" on a Policies post) before then submitting grandchild posts with a CRED Form, then you should use a wpv-conditional shortcode in your CRED Form wrapped around the section with the fields you want to conditionally display.

So as the form is in the process of being built on the server before being sent to the browser, a check is made for the value of the field on the grandparent post and the dependent fields will either be included with the form or not.

You will need to write a custom function or custom shortcode for use in the wpv-conditional shortcode that tests the value of the field on the grandparent.

If you are doing this kind of thing a lot, rather than writing lots of individual functions or shortcodes you can try and write a more generic one, passing arguments as shortcode attributes, for example.

That gets more complex as you go back through grandparents (great grandparents?) etc., but looks like what's required.

I don't think you can have just a JavaScript-based solution because with CRED you need separate forms for each post type, the fields for "accepts children" won't be in the same form as the group of fields on the grandchild post it is intended to affect.


OK, I get it. However, some solution, I must to find and it is probably best way to redesign it.

what about the concept - Hotel > Room > Bed > Children, where via CRED I should to be able to control did entire post type will be enabled or not, only by single value in grandparent (Hotel policy)?

f I'm not wrong, in this way I should not to relate directly fields from Children CPT with value in Hotel field (complex conditional), right?

Enough should be to add option to display link for adding a child in form page (use form with title "Child policy") what visibility in form will depends on conditional display related to value of Hotel question about allowed kids, right?

Moreover, I should to be in position to easy add also eventual additional conditions to display child form for kids (ie, if family rooms are enabled, or whatever). Briefly - controlling the child post visibility/availability and not the fields within post itself.


I solved the issue by changing (simplified) the workflow.

I quit from concept (policy per beds/product) and decided to go with generic CPT Children (as I will need it for other CPT's vs Policy).