[Resolved] Content less form with repeatable field groups

[Author]

Posts

[Ljuba]

I agree and website is done at hidden link (same credentials, but if you don't have it, open private post).

1) Unfortunately, I needed to add the relevant post types (empty), as I think that most likely will count (eventual functions), in what CPT form can to appear., especially, as they are not at 'same level' and also not necessarily with same 'parental' structure vs required fields (to pull data in form).

2) In meantime, I figured that there is no needs for more than two (2) CPT for forms (Formularios, should be 'repeatable' per form and 'Clientes final', should be single one per form).

FOR 'Formularios' and 'Clientes final' I DID NOT CREATED RELATIONSHIPS (you will maybe decide that should be used relationship forms, or whatever).

3) This form (what is important for clear 'global picture') have same schema for Alojamientos (Habitaciones), Gastronomias (Menus and Horarios), Compras (Productos) and Servicios comerciales (Servicios and Horarios). Form should to be also for Eventos (Horarios) and Lugares (Horarios). Only difference is that fields will be different (obviously).

In the above paragraph, there are in the brackets CPT's from which 'repeatable form' (Formularios) should to 'pull' data. So, for Alojamiento post, Booking Form ('repeatable part') should to 'pull' data from Habitaciones, but (ie) for Gastronomia, should to 'pull' data from Menus and Horarios.

4) For this form, I created four (4) fully functional 'real life' fields from where ('repeatable part' of) form should to 'pull' data. Demo posts for Negocios (1), Alojamientos (2) and Habitaciones (4 + 2 = 6) are also created (with populated fields) and connected.

5) For Clentes final CPT, I created only 3 basic fields, as this is not repeatable part of form ('second page' of form). RELATIONSHIPS ARE NOT CREATED.

6) I also created Content Template for Alojamientos, as there should to appear the form.

7) Finally, Formularios CPT, RELATIONSHIPS ARE NOT CREATED, as well the fields. It shoudl to appear on first Form Page and should be REPEATABLE (entire set of fields).

That 'repeatable part' of the form, should to contain fields:

• Entrada (Data Picker, could be generic field, your choice)
• Salida (Data Picker, could be generic field, your choice)
• Seleccione la habitación (select field type, populated from Habitaciones field = 'Tipo de habitación')
• Habitaciones (select field type, populated from Habitaciones field = 'Número de habitaciones (de este tipo)')
• Adultos (select field type, populated from Habitaciones field = '¿Cuántos clientes pueden dormir en esta habitación?')
• Niños (select field type, populated from Habitaciones field = '¿Cuántos niños pueden dormir en esta habitación?') > See 'tricky form'

RESUME

a) Form is example for form done by two CPT's (Formularios and Clientes final).

b) Form is example where one part of the form is 'repeatable' and second - not.

c) Form is example for form automatically assigned (connected as child posts) to the post where form appear.

d) Form is example of 'multi-page' form.

e) Form is example of 'repeatable' form with 'editable' form (to be possible to be 'fixed' or deleted - previously added item).

f) Form is example of form with fields populated by values from 'sibling' CPT.

g) Form is example of 'tricky form', as appearance of one form field should to depend from the value of the third part field in common parent post.

EXPLANATION

Common parent post (for Habitaciones and Formularios) - Alojamiento, contain field '¿Se pueden alojar niños?'. Demo posts are set that Demo Hotel 1 have YES like answer and Demo Hotel 2 have NO as answer.

Obviously, there is no logic that in Booking Form for Demo Hotel 2 appear field 'Niños'. I must to note, that same scenario I will get for some other fields, but one example is enough.

FINAL REMARK

Toolset can think to add that form for existing travel reference site (shoudl be easy, as contain similar structure), as in fact, it cover many scenarios and there is no online demos for ANY OF THEM. It will be also HUGE SAVINGS for support team, as will cover a lot.

[Beda]

Thank you, I will keep that post for later.

Now, we start to slim down this system

18 Post Types is too much, I think.
Try to use fewer Post Types, more Taxonomies and Fields.

I don't think "horario" is a Post; it should be a field, I guess.
It marks a schedule, a maybe repeating schedule, OK, but not a Post, it's a "quality" and not an "item".

Imagine you have Houses, that you sell.
In this case, you create as few Post Types as possible and classify those into type, add details (with fields) like location and rooms (as repeatable fields OR a separate post type if needed).

You should end up with more Fields and Terms than Post types.

Remember that WordPress just throws it all into the same table, posts, where all post types are stored at once.
So it's not improving performance a lot if you have many Post Types (it does, but not a lot).

In your case, I would look at what is your main item.
I think it is "Businesses". In general.
These Businesses can then be categorized (hence, taxonomy) into hotel, bar, pharmacy or club, whatever.

Later, custom Fields are used to add information to those Businesses.
The Fields may appear conditionally to the chosen taxonomy for example, or, you create a FEW (not many) post types to further classify the "Businesses".
But I would try to keep as least Post Types as possible for the "main item".

After you have that business categorized and enriched with data in the fields, you can think about eventually connected post types, which are either items or "actions" you want to perform related to this business.

That would (IMO) be "bookings". A post type that can be connected to a business and allows to set some variable data related to the business, and the user submitting the "booking".
So in this post type, you will SHARE most of the data of the Business (the fields and eventually taxonomy).
You will bind this to the (parent) post type business.
You will use the user object (of WordPress users) to classify the bookings into "clients".
OR, if you need full control, mimic the user to a post type (client) that is connected to bookings.

You still only have three post types at this point, shared conditional fields and condition-setting and classifying taxonomies (eventually also shared).

There is where we can start. This is the "core" of your idea, right?
Many "type" of business can "list" their offers and clients can "book" it.

I would like to demonstrate a simple structure of this, can I erase the current site structure and build on it?
(I already logged in as above seen I saw the structure, no need for new login details.)

[Ljuba]

Hi,

Nice that you started. Bad, there are some misunderstandings (HUGE).

1) I attached those post types (all are empty) EXCLUSIVELY to enable you better and more clear picture about what it should to be. In REALITY, for purpose of the Form, you have to focus EXCLUSIVELY on Alojamientos, Habitaciones, Formularios and Cliente final.

2) The is ZERO CHANCES to do it as you explained, as there are literally tons of reasons, why it is done as it is. So, if this will be EXACTLY Yelp like site, I most likely will agree with you in 100% of what you wrote, BUT IT IS NOT Yelp like.

3) However, I'm ready to listen what you think, but count, that here are (at least) two major problems:

a) You probably don't get exact idea what it should be. Example is Horarios, as there is about very complex composition of schedule related fields (of any kind). In fact, you can see all in main domain installation (as it works). Similar is with Piscinas (I'm wondering, can it be made more simple, as you should to count how it should to be repeatable, should to belongs to hotels as FREE service and should to belongs also for Commercial Services as PAYABLE SERVICE (ie some Water Park > just in Guayaquil are two parks with several swimming pools). Curiosity is also that Nigel spent many hours on Horarios and he will confirm you that it cannot be done too much different (in essence).

b) Second, yeap, there will be finally near 30 CPT, 300 fields and 100 taxonomies, what obviously will 'jump' out of the topic in HUGE PROPORTIONS. In main domain installation, you can see very clear how MOST OF THE FIELDS are repeated by groups per CPT and MAIN DIFFERENCE is exactly on taxonomies (per CPT's) and about 30-40% of specific fields.

BACK TO FORMS

"You will use the user object (of WordPress users) to classify the bookings into "clients"."

NOPE, HUGE MISUNDERSTANDING. Website owner clients are AUTHORS OF BUSINESSES (each business, one author/client), as they own the business, not owner of the site (so, huge difference from Yelp, more like Bookings). PERSONS (companies) who submit the forms are clients of the clients (that's why 'Cliente fineal' and not just 'Cliente'). There is VERY HIGH probability that posts will be set for automatic expiration (cleaning/destruction). From other side, 'Formularios' will be 100% sure set for automatic expiration/destruction.

Also, if you want, I can show you also how will look Form for Gastronomias CPT's (significantly more complex), but I set in essence very simple Booking Form as it cover ALL ISSUES.

[Ljuba]

==> Also, site is not (primary) about the business, rather information's (as domain say).

==> Nobody will not selling anything on the website (it is informative).

==> Post is named 'Formularios' as they are not (just) a Booking, or Booking at all. I have a post type as I can't see how to make form without post type, ans post it self will not connect anything or collect anything. It will be WIPED. For 'Hotels' it should to have 6 fields and (at least) 2 are generic (from the begin are not relevant to collect and record anything. If you can set other 4 also as generic (but to pull field values from other CPT fields), those 4 also can be generic, as I don't need any data from there (it will be WIPED).

So, as site will not sell anuything or collect any commission for 'Booking' (and other forms as well), idea to start to 'build' and/or to connect something on Booking CPT is fundamentally wrong, as I don't need it at all (by itself).

P.S. If you still doubt in something (or if you are confused by information's), I'm available to explain it to you in video chat, whenever and wherever you want (mean, Skype, Face Time, Hangout, Viber, ...).

[Beda]

I attached those post types (all are empty) EXCLUSIVELY to enable you better and more clear picture about what it should to be. In REALITY, for purpose of the Form, you have to focus EXCLUSIVELY on Alojamientos, Habitaciones, Formularios and Cliente final.

OK.
So it should be a website with 18 Post Types, but in reality, we will work only with 4 of them:
"Alojamientos", "Habitaciones", "Formularios" and "Cliente final"

Whatever the point in this is, it's up to you, I can focus just on those 4 Post Types.
It is almost exactly what I proposed so I am quite OK with it.

The is ZERO CHANCES to do it as you explained, as there are literally tons of reasons, why it is done as it is. So, if this will be EXACTLY Yelp like site, I most likely will agree with you in 100% of what you wrote, BUT IT IS NOT Yelp like.

OK, I do not know exactly what feedback I can or should give to this comment, hence I refrain from commenting.
(Acknowledged, ZERO Chances to make it simpler).

You probably don't get exact idea what it should be. Example is Horarios, as there is about very complex composition of schedule related fields (of any kind). In fact, you can see all in main domain installation (as it works). Similar is with Piscinas (I'm wondering, can it be made more simple, as you should to count how it should to be repeatable, should to belongs to hotels as FREE service and should to belongs also for Commercial Services as PAYABLE SERVICE (ie some Water Park > just in Guayaquil are two parks with several swimming pools). Curiosity is also that Nigel spent many hours on Horarios and he will confirm you that it cannot be done too much different (in essence).

- I had a look at Horarios (Piscinas does simply not exist in this site as a Post Type) and was surprised, did you not say that I should only focus on these 4 post types (Alojamientos, Habitaciones, Formularios and Cliente final.)? I am of course confused, it is contradicting
- I see you do not have any fields at all in the Post Type Horario, however, it's connected to several other post types. Fine, no issue with that. For me this looks like the simplest ever Post Type, I am sorry. There is not a single Field on it, and it's simple and just connectable to a few other post types, what is the problem with this?
- No post type "Piscina" or "Hotel" or "Commercial Services"
- No idea what Nigel spent time on the post type Horarios, sorry, it is the simplest ever post type I saw.

I conclude I do not know what I should feedback to you here, same as the comment above, I do not see how this relates to the issue, its resolution, or a problem description at all.

Second, yeap, there will be finally near 30 CPT, 300 fields and 100 taxonomies, what obviously will 'jump' out of the topic in HUGE PROPORTIONS. In main domain installation, you can see very clear how MOST OF THE FIELDS are repeated by groups per CPT and MAIN DIFFERENCE is exactly on taxonomies (per CPT's) and about 30-40% of specific fields.

OK.
We agreed to work on the problem on this site:
hidden link
That is where I do have access to, and where we will see to do what you require.
Right now I see a bunch of connected post types, a few fields, that's it.
Not sure what you want to do now.

Can we start with "Alojamientos, Habitaciones, Formularios and Cliente final."?
What do you want to do with those?

Can you show me a "chart" where you show what should be most general, what most specific (so we can begin to set relationships)
Then, let me know what each of those 4 post types should feature as Fields and Taxonomies (what quality, and what area, they have/are)

Please as well move out the Habitaciones (and all other post types) from hidden/submenu state if we need to focus on them.

Then, after we set up all this we may proceed.

Meanwhile, I am still awaiting your confirmation that I can manipulate that site as I like, or not:
https://toolset.com/forums/topic/content-less-form-with-repeatable-field-groups/page/2/#post-1094587

If not, I will proceed here with instructions.

[Ljuba]

1) I thought that will be more clear if you have entire 'picture', but it was mistake. Now, there is only 4 post types (all other deleted) and only one relationship (Alojamiento > Habitaciones). For Formularios and Clentes final I didn't set any relationship as I don't know how you think to do it.

2) All 4 post types are visible in admin menu.

3) "Meanwhile, I am still awaiting your confirmation that I can manipulate that site as I like, or not:"

==> Yes, you can do whatever you want, as it is demo site and data (nothing to be damaged).

4) "Then, let me know what each of those 4 post types should feature as Fields and Taxonomies (what quality, and what area, they have/are)"

==> I don't understand as I think that I already explained all at https://toolset.com/forums/topic/content-less-form-with-repeatable-field-groups/page/2/#post-1094091 (I even 'mapped' the fields there and 'by the way', for me looks that you didn't read the reply, rather immediately after first paragraph went to website). So, 'mapping' meant that there is written 'line per line'/'item per item' what fields should to have the form (Formularios and Clentes final) and from what fields should to pull data each form field. What is the other way to explain it more clear?

==> Formularios is 'repeatable' part of the form and it NOT CONTAIN data, it PULL EXISTING DATA (from parent Alojamiento adn sibling Habitaciones).

==> Cliente final is NOT REPEATABLE second part of the form with 'fresh' by visitor newly created entries.

==> There is no Taxonomy.

==> What you mean with "what quality, and what area, they have/are"?

Formularios should to have 6 fields and EVERY FIELD IS SPECIFICALLY EXPLAINED AND 'MAPPED' (from what field they 'pull' data). From six (6) form fields, two (2) fields are possibly 'generic' and four (6) fields are specifically 'mapped'. ONE FIELD IS CONDITIONAL (from grandparent post field value).

So, if you don't understand something from my replies, you should to ask SPECIFICALLY what is not written clear, as I don't know what is not clear from generic remarks.

[Ljuba]

I forgot. Additional (main) reason for my confusion is simple fact that you have FULLY FUNCTIONAL FORM (done by Formidable Pro) on main website (hidden link where you have also full access with same credentials), only problem with that form is fact that it is 'supplied' from static post (instead from dynamically found).

Entire topic is started as you claim how Toolset can make exactly the same (exactly, more or less). In other words, you have only 4 post types, only 6 fields (plus irrelevant second page) and fully functional prototype (what should to be done).

So, for me is seriously and obviously hard to be clear what you really ask me.

[Beda]

Yes, I think I replied to
https://toolset.com/forums/topic/content-less-form-with-repeatable-field-groups/page/2/#post-1094091

I read that again and analysed the site provided for testing, and I think I understand more parts, better now.

For example, you want a Form(Booking Form), that creates/edits an Alojamientos ('repeatable part') with data 'pulled' from Habitaciones.
It, however, shouldn't save its data. It should just be a form, and eventually create other contents, but not the post itself it acts upon.

Now. We face some logic issues here.

1. When that Habitacion you want the data from does NOT exist yet, you cannot pull its data.
This cannot be solved in any case of course, as the data simply would not exist. Code, in general, cannot "guess".
2. If instead such Habitacion exists, you can as I instructed in past use the Forms API to update that form's data with data pulled from other posts.
==> Or, often you can as well call related data of those posts using shortcodes, but that does not always work (due to the nesting of Shortcodes in ShortCodes).

Further, that Form's part should be repeatable.
So that means you want to end up with ONE Alojamientos on which the Form acts upon, but it should add repeatable items populated with the data of those other Posts, to the ONE Alojamiento. Those other posts are the Habitaciones (which of there may be many in turn again)

So you need a form that creates Repeatable Form Groups, or at least does create them with code, as there is no way to create (in one form) post AND RFG at the same time WITHOUT code.

So that would mean if you want to create one Alojamiento, and with the SAME Form, add repeatable items to that one Alojamiento, populated with the data of those other (Habitaciones) post, then this data should pull data from Habitacions. From EXISTING posts. OR from posts that you AS WELL would create on the fly, with Custom Code, hooked to the Form you use.

You can get close to that with a Form that creates Repeatable Field groups for example.
Toolset Forms allows you to:
- choose a post it belongs to (your Alojamiento) (you would need to create at least the Alojamiento ahead)
- populate the fields either manually, or populated with Shortcodes that call other posts data (Habitaciones that exist), or with Custom Code using the API (since these are normal Post Forms, not Relationship Forms). Custom code would in theory even allow to:
- submit form
-- hiddenly create Post of Alojamiento Type
-- hiddenly create Habitaciones
-- hiddenly get back those values
-- hiddenly update RFG with those values for the Repeating instances.

We speak about a few hundred lines of complex PHP code.

For example when you say:
Formularios is 'repeatable' part of the form and it NOT CONTAIN data, it PULL EXISTING DATA (from parent Alojamiento and sibling Habitaciones).

That Post type is not featuring any fields, not even post title.
So, any form that acts on that post type will typically not show any fields either.
If you now need a form that applies on that post type and has fields you need to use generic fields, because well, there are no fields otherwise to enter to the form and use later (or not use later).
I created such a Form here:
hidden link
See the inline comments.

Now, this form will not add Alojamientos or Habitaciones (yet). It adds Formularios Posts.

It could however gather data and pass it to Form's API so to:
- delete the post after submit (as you do not need it)
- pass data to Alojamiento so to create RFG's

So, if you want just one form that does all this, it will require massive custom code work.

If you prefer to use less custom code, you would have to start working with several forms redirecting to each other, and would not do all with one Form/Acting on one post only.
Still you would apply some code here and there, to adjust what you save to the posts (or not save).

Now, I also studied the Form on hidden link and IF I get it right (maybe I do not) that form, does NOT create content, but just fires an email.
Its fields are populated with data from other posts (which I have to say, is made NICE with that Plugin).

Now, apart from the fact that I wonder for what you want to use such a form, as it explicitly does not save its data
(other than for Emails notifications or leading the data to other apps)...
I see no purpose in doing this, BUT, you could do that with Toolset Forms as well.
Just use generic Fields, and apply a wp_delete_post() later on the post Forms created (as instructed earlier)
https://toolset.com/forums/topic/content-less-form-with-repeatable-field-groups/#post-1091057

The thing is, there is no way that this is gonna be easier in Toolset Forms than with your current Plugin, I apologise if I made that impression.
I admit, the plugin you use there is simply much easier to use when you want to create such form.

Toolset Forms requires you to add content, that Plugin doesnt.
Forms will require you to apply Custom Code to populate a field dynamically or at least wait until Toolset Views (next release) is out, where you will be able to use Views to populate such fields, bringing the dynamic part in the forms.
That Plugin even lets you chose the dynamic content yourself.

However, this all does not remove the fact, taht you NEED to know (with Toolset, or even Formidable Forms or wahtever other plugin) from WHERE that data has to come.
So if you need to get it from any other but the current input in any form, you need to pass that in the API (which we did in your live site's form)

We can dynamically call the ID of that Post, if we know by what "rules" to call it.
That means, you might be able to get the ID dynamically for example relaying on another input in the form or whatever restrictuon you apply tot he query to return thta post id or object.

This is not else in Formidable Pro or others.
It is simply not possible to "guess", in Code.

With this I think we could finally conclude, that this is better done with your plugin, as it provides better management of dynamic and especially "not existing" content (or, let's call that "trigger content")

Both (Toolset Forms and your plugin) require code to get/post the data from related content and will need code to do "several operations" at once.

Unfortunately we cannot provide the code needed for this, but you could use less cod by using more forms and steps in your process, and saving more data.

[Ljuba]

Dear Beda,

It is kind of hard to understand what you wrote, primary, as you started to guess too much (and all wrong), despite the fact that scenario is quite simple (there are all data/posts/fields/values). However, it could be ALL MY MISTAKE. Maybe I set it to looks complicated. So, let's try different.

1) THERE WILL BE NO SITUATION THAT WILL NOT EXIST AT LEAST ONE ROOM (Habitacion), as simply will not be permitted creation of Accommodation without at least one room (make sense, right?).

It also mean that

2) THERE WILL BE NO SITUATION THAT WILL NOT EXIST all values for all by form required four (4) fields (to pull data from it). In other words, you can see also by yourself very easy, that Habitacion CPT have four (4) fields and all 4 are required for publishing room (room cannot exist without those values).

==>Tipo de habitación*
==>Número de habitaciones (de este tipo)*
==>¿Cuántos clientes pueden dormir en esta habitación?*
==>¿Cuántos niños pueden dormir en esta habitación?*

So, no fields values mean no Rooms, mean no Accommodation and 'vice versa'. This is (very simple) 'equation with all known values' and there is NOTHING TO GUESS (contrary to your reply, full of something to guess).

3) FORM SHOULD NOT TO DO ANYTHING FROM WHAT YOU WROTE (as -- hiddenly create Post of Alojamiento Type, -- hiddenly create Habitaciones, -- hiddenly get back those values, ....). EVERYTHING ALREADY EXIST (you also have demo posts with values to see that everything already exist).

You went so far with theory of Alojamiento creation, that you missed elementary initial fact ==> FORM MUST TO BE PLACED ON EXISTING ALOJAMIENTO POST FRONTEND. So, how you think to place form to 'hiddenly create Post of Alojamiento Type' on that same Alojaminto (as it not exist)??? There is nothing about what you wrote. Alojamiento exist and room(s) exist and fields values are WELL KNOWN (as required for room creation).

4) Instead of all this scenarios (any applicable here) what you wrote,

==> I thought that you created form (and you did > 'Add Formulario') and simply created 6 fields (or 4 simple selectable fields, as arrival and departure are irrelevant for topic), connected with fields from 'sibling' CPT Habitaciones and ABLE TO PULL VALUES FROM EXISTING FIELDS VALUES (already created in demo posts). To shows how data values can be pulled, as THAT PART FAILED for Formidable (remember that code provided by you not working, as it pull data from STATIC POST ID, instead from dynamically retrieved post ID?).

So, I expected that if Toolset cannot 'feed external plugins' with such dynamically retrieved data, that it can be done within Toolset. But you didn't show it (prove it), as I can't see in your created form four fields with values populated from EXISTING POSTS (not some non existing posts).

Material fact is that such examples not exists on any Toolset reference site and/or documentation (that is why topic exist ==> you claim that it can be done and I can't see how).

==> I thought that I will be able than to see how those four (4) form fields will be able to be repeated (added/edited/deleted) in frontend and in real time. So, not in theory, as such example do not exist in Toolset reference sites and/or documentation.

==> I expected also some other aspects (already wrote before) of the form, to be seen, but they are less important.

RESUME

P.S. - Do you create or not Formularios posts by form, I don't care (it is irrelevant here). Equal is for 'Clientes final' CPT (second form page).

P.S. 1 - I repeat. There are created six (6) DEMO HABITACIONES (so, nothing is non existing or hidden) with field values and they BELONGS to two (2) DEMO ACCOMMODATIONS (so, nothing is non existing or hidden). there is CREATED Content Template (Plantilla para Alojamientos) for those DEMO ACCOMMODATIONS, as that is the PLACE WHERE FORM SHOULD TO BE PLACED AT FRONTEND (so, nothing is non existing or hidden).

SIMPLIFICATION

To cut this theoretical topic, I created 'Booking' form and I added form to template and you can see on screenshot how on Demo Hotel 1 is visible Form (mainly visually 100% identical to existing on website). I also create in Formularios 4 selectable fields for purpose to be populated by dynamically retrieved data from sibling Habitaciones post. Data fields in form are generic.

So, form don't need ANY THEORETICAL FIELD AND CODE (what you did).

QUESTIONS

1) QUESTION IS SIMPLE. Can you 'map' those four (4) fields in that form, populated by EXISTING VALUES FROM 'sibling' Habitaciones posts (so, page where form appear is page of existing Alojamiento with ALREADY ASSIGNED ROOMS and rooms fields values), for purpose to show how it can be done by Toolset (as there is no live demo about it)?

This part didn't worked with Formidable. Can it works within Toolset (or not)? Please, just simply make it and show it and prove it. Simple as it could to be.

2) ALSO SIMPLE QUESTION. Can you show how that set (group) of those four (4) fields, can be in REAL TIME repeatable (create/edit/delete), for purpose to show how it can be done by Toolset (as there is no live demo about it)?

P.S. In form I duplicated Submit button for purpose to visualize form, but I doubt how it can be the same input type (submit). From other side, I also can't see what else to use to get in 'second form page' and to make 'repeaters' as well.

P.S 1 - Also to repeat 'mapping':

'Seleccione la habitación' form field pull data values from ==> 'Tipo de habitación*' (Habitaciones CPT field)
'Habitaciones ' form field pull data values from ==> 'Número de habitaciones (de este tipo)*' (Habitaciones CPT field)
'Adultos' form field pull data values from ==> '¿Cuántos clientes pueden dormir en esta habitación?*' (Habitaciones CPT field)
'Niños' form field pull data values from ==> '¿Cuántos niños pueden dormir en esta habitación?*' (Habitaciones CPT field), BUT DEPENDS ON VALUE OF '¿Se pueden alojar niños?*' (Alojamientos CPT field) ==> MEAN if in Alojamiento is set answer 'NO', than Habitaciones field '¿Cuántos niños pueden dormir en esta habitación?*' will be EMPTY and SHOULD NOT TO BE SHOWN in form.

For this reason, Demo Hotel 2 is set with 'NO' for children.

[Beda]

1, 2 Great
Please stop mixing the Post Types from technical to translated language.
Let's talk about:
- Alojamiento
- Habitacion

This is what you saved and what will be used.
Not Rooms or Accommodations. These post types do not exist on your install, these are translations of Spanish words, and it puts a heavy layer of difficulty to handle an issue when we need to workaround translations of (translations probably).

So, you have Habitaciones, those got 4 fields, all required.
The Habitation so you say MUST exist if you create an Alojamiento. So Habitacion is your primary Post Type like it or not.
It is the one that determines all the rest.
No Habitacion, no field in habitacion, no Alojamiento.
So this is where we need to start.

The first step in whatever workflow will be to FIRST create this Habitacion with it's required fields.

The reason I have to guess is that your explanations are not clear, to no one of our support team, so I do not think it is only my problem, but I do not work to discuss this, I want to solve the issue you report.

Finally, we seem to have tight facts:
- Habitacion has 4 required fields, and Alojamiento only can be created if Habitacion exist (and has 4 fields filled, of course)

3. OK; I see you created the "dummy" content (Habitaciones, with fields, and Alojamientos, connected to the Habitaciones)

Previously we spoke about how to create those, however, if those can be assumed as "already existing" (maybe you will put them there manually, who knows), then we can add to the previous conclusion, that:
- The Habitaciones with fields and their connected Alojamientos will already be existing.

That kind of means we actually do not need to discuss how to create them or what will be required for creating them as you state, EVERYTHING ALREADY EXIST.

The form you mention, to be allocated in an Alojamiento, is the form that creates "Forulario" (but the form is called booking)

4. See, you start to mix again facts.
While previously you stated repeatedly that EVERYTHING ALREADY EXIST, in this point you went back to "I thought that I will be able then to see how those four (4) form fields will be able to be repeated (added/edited/deleted) in frontend and in real time" and similar, but those fields, as you state, are required, and exist, because Habitaciones already exist.

This is not me being confused, it is not clear what you want.
I repeat, not only to me.

However, we started with facts that I will not change due to this point 4, which can if any, be subject to a later discussion in regard, but surely not on the same level as "EVERYTHING ALREADY EXIST" and "Everything needs as well to be created first".
This does not make sense, sorry, I apologise, if I do not get it. I am not the only being unclear over these changes of mind.

The rest of #4 is clear, you want the Form named "Booking", to create Formularios and pull the data from (Existing) Habitaciones and Alojamientos. That form should live on an Alojamiento.

To get data from Habitaciones that are related to this Alojamiento, you need the API.
I explained in past already how to get data from posts either with WordPress or/and Toolset API, how to use that in a Forms API and how to push back that data to the Database, so the Formulario Created by the Form has the data pulled from the Habitacion and Alojamiento, I provided example code as well, this is as far as we can go.

Now, whether with ACF, with Formidable PRO, Ninja Forms, Toolset Forms or even future not yet built technology, you will NEVER be able to craft a code, that pulls data from something that does A) not exist, or B) not defined.
So, this means, if you want to pull data from any post of type x, and populate any post of type y with it, you SOMEHOW need to do two things:
- make sure that data exists
- make sure the code that gets the data, knows where to get it

You are left with some code that will ALWAYS ask you to pass for example a GIVEN post ID, which you can get in DIFFERENT ways, but at the end, the code ALWAYS, ALWAYS will need to act upon ONE item, one only, and a precisely determined one.
How you get that item, if you get many of, and "loop" thru them - is a totally different story and this is what allows you to make the process dynamic (dynamic pulling of the related post)
But you need to tell the code, where to look for

So - either you pass a hardcoded Post ID, or you get the Post ID somehow else, for example, with a query for all posts of type x, and then you filter that query, by value y, and once you are satisfied with the post returned, you act on it with the code you want to apply on.

We do not help with learning PHP and WordPress API, and here you NEED to understand and apply those massively.
Whether with Toolset, ACF, or what else you pick.

I explained and gave a proper example on how the API works, made a working example of data pulled from another post, and all that is needed is to pull the exact post you want (current, or related, or whatever)
Related posts can be received with our API as shown, and getting randomly or arbitrary or else posts is done with PHP and WordPress.

We can conclude that yes if you have existing posts (Alojamientos, Habitaciones), you can pull that data, you can populate new data with it (Formularios).
If you have no existing posts or do not know where they are / what they are, you cannot do this.

Given your explanation we do have the data, in Alojamientos and Habitaciones, we need to pull it from there and create Formularios with, using the Booking Form.

The form and Formularios Post asks for the fields:
Seleccione la habitación
Habitaciones
Adultos
Niños

You ask fro two things:
A) These to be populated with values of other posts (possible, by calling those related posts and their data with our API, then, for example, returning that in a ShortCode and populate the Generic Fields if the Bookings Form that creates Formularios
B) Those values of those fields to adjust on the fly when you choose the first field, the others should adapt
This is not possible with Toolset forms unless you use extensive Custom Code (for example you could try to play with Select2 fields, but not sure that works, and refire the Toolset API with AJAX each time you change value.... very expensive process by the way)

Not possible, unless you invest a lot in custom code.

To do this with Toolset You need several forms.
You always will be able to act on those values BEFORE or AFTER the form is rendered or submitted, but less "during" filling it out.

You need a form that creates Formularios (the Booking Form)

The Booking Form that creates Formularios, should have generic Fields that get their Data from a Custom ShortCode, which pulls data from the habitaciones, that are related to the Alojamiento, where the form is inserted.
This means you can apply toolset_get_related_posts on the CURRENT post ID (usually in the global $post) since you insert the form on the alojamiento.
So you are lucky, it will get you all the related Habitaciones Posts of this Alojamiento, just as we did in the Formidable form!!

However, this values can be loaded only by the PHP, if you need that on the fly, only AJAX, JS and other custom code can help you

Concluding, either you use a Plugin that allows what you need (it does probably not exist in one package) or you simplify the process, or you add more steps to the process (not just one form)

I am sorry that this is as far as Toolset and it's support reach.

[Ljuba]

Dear Beda,

FIRST > DISAGREE

A) Visitor makes reservations 'from Hotel' and not 'from Room'. You 'mix' fact that visitor should to be able to repeat room reservation (mainly because of the room type) with the 'subject' (post type) with who such form (post type) or visitor, by this submission of the form is in relation. Visitor not reserve the room from room, rather room from hotel.

B) I could be unclear with explanations (and I'm probably), but it will not change the fact how you can see in demo site how THERE ARE ALREADY ALL DATA, as they already exists. So, for me is unclear why you all the time insist on some 'unknown variables'. Let it put in other way. How can be possible to have hotel without rooms? How can be possible that I ask you to 'pull out data' form something what not exists (existing room types to pull out if they already don't exists???)?

So, form is on the page of the hotel (obviously hotel exist, what mean also rooms) and that is the FACTUAL SITUATION also in demo site (there are demo hotels and demo rooms). So, why you talk about it? However, you wrote "This does not make sense, sorry, I apologise, if I do not get it.", despite that you can see in demo site how there all data and all what you asume that not exists, already everything exists.

SECOND > ANSWER

That is what I thought and claimed from begin (previous topic) > It cannot be done.

So, to remind you, you claimed that it can be done and you asked demo site. I make it. I fill it with data and created (as design) the form. On you was 'only' two thinks (what you claimed - and for what - BTW - don't exists any documentation and/or reference site/demo):

1) To populate form fields with EXISTING DATA from EXISTING POSTS.

2) To show how works that 'famous repeater'.

Well, if that is out of the scope of the support, you shouldn't claim it (that it can be done) and asked for demo site.

[Beda]

A) We talked about Habitaciones, required fields, and Alojamientors, + Formularios.

The statements I made here stand:
https://toolset.com/forums/topic/content-less-form-with-repeatable-field-groups/page/2/#post-1108135

B) Yes, the data is there, in the site, and I provided the solution on how to pull data from the database, when you need Toolset related data, here:
https://toolset.com/forums/topic/pull-out-data-from-toolset/page/2/#post-1080228

You will need to decide of which post you will get related data from, and in your case that will start wih the alojamiento, as that is where you will insert the form, and that is the global $post (ID), which is provided by WordPress.

You can use that code in a Toolset Forms API cred_save_data for example to udate with data from those related posts.

C) What cannot be done is having Field A change on the fly, when Field B changes value, as for example it is possible in a Views Custom AJAX search.
That, is not possible in Forms (well, if you apply advanced Custom Code even that is possible)
I am not sure, as mentioned, there is any plugin that offers this out of the box.

It was never mentioned to achieve on the fly or ajax updating of select fields in a form depending on data of posts related to the post where the form is inserted to.

Since it is, I can answer we cannot assist that.

I claim it is possible to get values from related data and update what you submit (or even other) with that data, using PHP

I showed how to do that, as linked.

Thank you.

[Ljuba]

Dear Beda,

You obviously don't get the point of the topic.

FIRST - TO CLEAR

1) It is not the problem to insert the code provided by you in previous topic, issue is something else (next chapter).

2) Sorry for for 'chained fields' I thought that it will not be the problem, but you are 100% right = that was not the topic. So, forget.

SECOND - ISSUE

1) I didn't tired code provided by you as you suggest exact the same as it is for Formidable, but that not works there and I logically assumed how will not works neither here. I can try is it working, but ... (see next).

2) Here (topic) is about the simple fact how we talk about the COMPLEX FORM (more precisely, forms > plural), as here is about the several 'chained forms' (first page are 'repeatable forms' and second is 'one time data form'), which should be 'grouped as one form' (mean also sent via email). If you add the issue how there are the real life situations that visitors will want to edit/delete 'repeated forms', we talk about something quite complex and Toolset DON'T HAVE ANY SIMILAR EXAMPLE or documentation how to do it. ==> I can't see how Toolset can to do it.

SUGGESTION

We spent 30 replies for ZERO outcome. Let's be pragmatic. Forget for 'pulling data' (let the fields as they are now) and try to show me in practice how to make such functional form with repeaters, as I see much more problems (some exposed above), than you even think (at least looks for me).

That's sounds at least as bare minimum of for what we initiated all this, right?

[Beda]

1. 1) I didn't tired code provided by you as you suggest exact the same as it is for Formidable, but that not works there and I logically assumed how will not works neither here. I can try is it working, but ... (see next).

That code does work.

I will not discuss this anymore, the ticket will be closed if we will discuss again the "code does not work" without a clear mentioning of error.
The code, works, I provided a working snippet on the system + explanations how to use it

Thank you

2. Here (topic) is about the simple fact how we talk about the COMPLEX FORM (more precisely, forms > plural), as here is about the several 'chained forms' (first page are 'repeatable forms' and second is 'one time data form'), which should be 'grouped as one form' (mean also sent via email). If you add the issue how there are the real life situations that visitors will want to edit/delete 'repeated forms', we talk about something quite complex and Toolset DON'T HAVE ANY SIMILAR EXAMPLE or documentation how to do it. ==> I can't see how Toolset can to do it.

- is about the simple fact how we talk about the COMPLEX FORM
Please read this your first post:
https://toolset.com/forums/topic/content-less-form-with-repeatable-field-groups/
Then, read thru all the posts. Then, thru all the tickets.

No, it is not a simple fact, and yes, it is a complex form.
But no, not simple.

And no, we do not talk about a complex form in THIS Thread, but I know that ultimately, you want to create a complex form
However, this ticket handles the Form "Bookings" for Formularios, which should (and cannot as it's not possible) have fields updated on the fly as per values chosen and related to.
Toolset Forms cannot do this, we found out.
Toolset Forms can do that, but only in PHP, means, it requires you to submit the form, then it will act in PHP and get data, but it will not update the Select Fields or similar in the Form, it will update Posts created or manipulated by that form

As well, here there is nothing to add, it is how toolset works.

Sorry if I made the impression it could.

- as here is about the several 'chained forms' (first page are 'repeatable forms' and second is 'one time data form')

as said, repeating forms are something not possible in Toolset Forms.
You can have one Form, that creates or edits several Posts, but not at the same time, unless you apply custom code, and you cannot add repeating items as the same way as used in the backend.

- which should be 'grouped as one form' (mean also sent via email)

This is not related to either the ticket, either to each other, or any to whatever we talked about.

No comment on the section.

- If you add the issue how there are the real life situations that visitors will want to edit/delete 'repeated forms',

Ok, yes, if we add real life, things always get complex.
Computers do not understand real life.
They need sometimes certain "paths", to hold on.
One such thin is the data you feed to an API.
No data, no output.

About edit/delete 'repeated forms':
- you cannot edit or delete repeating things that in some way are added by repeating forms or single forms either.
- you can however add Posts, Repeatable Fields, Single Custom Fields to Posts, Users, and their Fields and Posts terms, with a Form, that each time, will create (by default) one Post or User.
That is what Toolset does.

It cannot create several ... repeating things in repeating ways.

And for sure you do not want to edit or delete "Forms".
You will use Forms to edit and delete Posts or useres, but not forms.

This is however not possible:
- create any repeating thing in one form (unless repeating fields, but as said, those are single simple fields belong to one post)
- create many connections on one form
- do whatever interaction with repeat, or many, you need many forms or steps.

- we talk about something quite complex and Toolset DON'T HAVE ANY SIMILAR EXAMPLE or documentation how to do it. ==> I can't see how Toolset can to do it.

I can only remind you of your own words a few lines above:
"is about the simple fact how we talk about the COMPLEX FORM"

- We spent 30 replies for ZERO outcome. Let's be pragmatic. Forget for 'pulling data' (let the fields as they are now) and try to show me in practice how to make such functional form with repeaters, as I see much more problems (some exposed above), than you even think (at least looks for me).
That's sounds at least as bare minimum of for what we initiated all this, right?

I keep telling you, repeatable things need many forms, not one.
I explained to you, connecting many things needs many forms, several steps, not one.
I explained you, how you can get data, you are not happy with that and now, last, changed plans:
No more data from those posts, now it is about... something totally differnt:
try to show me in practice how to make such functional form with repeaters, as I see much more problems (some exposed above), than you even think (at least looks for me).

I can only answer:

It is not possible with Toolset, I apologise deeply if you whre under the impression it to be, and if I made this more - I apologise again, I do hope that you can still use Toolset for a part of the site and use Custom Code for the Complex Forms.

Thank you, I apologise.

[Ljuba]

Dear Beda,

As I don't think that we should to argue (and that is certainly not my intention), I basically will not reply on your statement (my answers are related to other goal - to be productive).

1) I started previous topic with other goal and we finished in this topic related to your reply https://toolset.com/forums/topic/pull-out-data-from-toolset/page/2/#post-1086520. So, I just would like to pay your attention on couple of simple material facts:

==> Fully functional form done by Formidable Form is 'alive' (present on site) over 2 months.

==> That form from point of view of Formidable is EXTREMELY SIMPLE (15 minutes of work).

==> However, I was clear in previous topic how such form CANNOT BE DONE with Toolset (or if can, it will be VERY COMPLEX), primary because of 'repeater' (see title > "...form with repeatable field groups ").

==> I did not start this topic to provoke you (to argue, or whatever else), I simply thought that you are right and I'm wrong. It is simple situation. My interests are to try to get the form with Toolset (if I can).

2) FINAL QUESTIONS

==> If I get you well, I should to open new ticket regards the code from other topic, right?

==> Using generic fields (see title > "Content less form ..." or using 'custom fields' (new CPT), by "puling data" or without "pulling data" (so, just 'generic values' in form field options), CAN WE AGREE how 'repeater' functionality present the DECISIVE OBSTACLE to get such form done by Toolset Forms?

P.S. - 'Decisive obstacle' in sense that also if eventually such form can be done, it will be irrational to do it (complex, or whatever).