Hi Ljuba
On the basis of trying to reproduce something similar to the booking.com form, I'm working with a highly simplified concept to illustrate some of the points.
So, let's say I'm publishing hotel listings, and it has certain fields (ignoring whether these are taxonomies, related posts etc.), like so:
:: Simple fields (name, address, website, phone, email)
:: Province ( north, south, east, west )
:: Climate ( inland |mountain | lakeside | coast | beach-front ) - options depend on what's chosen for province
:: Has restaurant Y/N
:::: Y -> add restaurant
:::: Restaurant name
:::: Description
:::: Gastronomy
:: Has pool Y/N
:::: Y -> add photo(s)
Looking at this in isolation, some observations/clarifications.
I mentioned earlier that for fields you may want to search/filter by there was a preference for using taxonomies, because they are optimised for queries.
But, as you have found yourself, conditional display works for custom fields, and does not work for taxonomies.
And as you also found out in your ticket with Beda, conditional display refers to display only. A user can choose one option which reveals certain choices, make those choices, then change their first choice so that these choices are no longer relevant, but they are still submitted, potentially leaving you with unintended data attached to your posts.
So, that's a basic problem that argues against the preferred taxonomies (no conditional display support) and a second problem that complicates the use of custom fields.
Anyway, let me walk through what filling in the form might look like.
The form itself will submit a Hotel post. (It could be a child post of something else, but we'll abstract from that here.)
We add the simple fields for the name, phone, email etc. (which could be repeating fields, i.e. more than one phone number could be entered).
Now we select a province region (one of north, south, east, west in my fictional example). Ideally this would be a taxonomy.
Now we display the climate type choice. The way we want this to work is that certain provinces have certain possible climates, and we don't want the user to be able to choose "mountain" if they are in the eastern coastal province, for example.
Here we run into the problem that conditional display using taxonomies isn't supported, so province couldn't be a region. If province were a custom field we still have a problem, in that we might show or hide the selector for climate, but we don't have a way for the fields available in climate to respond to what was chosen in province, even if they are both custom fields.
(There is a custom code work around for that, which involves writing both custom PHP on the server to generate an array of the possible climates for each province choice, which gets passed to the front-end using wp_localize_script, and custom JavaScript that takes that array and manually updates the options in climate whenever province is changed. You could do that equally whether province was a taxonomy or a custom field.)
On to the next field, has restaurant?
Choosing yes exposes additional fields to add details of the restaurant. I included a gastronomy field where the values might feasibly depend on a previous choice, e.g. certain gastronomy options are only available in certain provinces, I'm not sure if that could be a requirement.
Now, in terms of data, it seems clear that restaurant would be a child post type (although it could also be a repeatable field group, which under the hood works much like a child post).
The issue here is that one form can only submit one post, and this form is submitting a hotel. To publish a restaurant that is a child post of this hotel, you would need to provide a link to a separate form that publishes the restaurant (and you wouldn't want to link to that form from this hotel form because you haven't finished submitting the hotel yet, the workflow for publishing child posts (or repeating field groups) would be to finish publishing the hotel post and then link to a form a add a child restaurant post, which isn't the kind of workflow envisaged here.
Also, if the gastronomy field options diddepend on the value of an earlier field in the hotel form, that would similarly require a bespoke custom code solution.
Lastly, I have a yes/no field for a pool, and if there is a pool the user can submit photos of it. That is simple enough with a repeating field where the user can add a photo, then another if required etc. It would be nice if there were support in forms for repeating field groups so that they could submit photo and a text caption field, as many times as required, but currently that requires the workflow as described above, linking to a separate form to add a new set of repeatable fields. (Support for this will come, I just can't say when.)
So, if we look at this from the perspective of a user submitting a form, we see various problems that affect our preferred data model.
Any solution is going to inevitably involve
- writing custom code (possibly quite a lot when you expand beyond this fairly simple example), or
- simplifying your requirements.
If you want my honest opinion, I think you should not let the limitations of our forms dictate how you put this together.
You are going to need a fair amount of custom code whatever you decide to do.
So, if it were me, I would use Types to create the data structures that make sense for the project, and Views to output the content wherever and however I need.
And then use whatever forms product is best able to give you the kind of front-end user experience you require, with a bespoke back-end solution for managing the form submission, using a combination of standard WordPress functions and the Toolset APIs to populate the database according to the content of the form submission.
Then instead of having multiple forms, with one main form for the hotel, and separate forms that can only be used after the hotel has been posted to add child posts for restaurants etc., you include everything in an attractive multi-step form with well-supported conditional content, and use a PHP script to handle the form submission to create the child posts, set field values, set taxonomies etc. Something like formidable pro, maybe.
It is quite a lot of work, but it is a complicated project and there is no getting away from that, and you should use your energy where it makes sense instead of trying to bend a tool to do something it is not really capable of.
