[Resuelto] Content less form with repeatable field groups

[Autor]

Mensajes

[Ljuba]

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

I need (not completely) simple Booking form without content (posts) creation and too much queries, same (similar) as it can be done with most popular 'forms creators' - Formidable, Caldera, Ninja, ....

I have such form created on my website, but I would like to avoid usage of third part plugins (a part from Toolset), for more than obvious reasons.

Can it be done and how?

[Nigel]

I'm not sure I understand this, you want a form "without content (posts) creation".

Other form plugins create posts when you submit a form, even if it looks like they are not.

If you use the default contact form that ships with Ninja Forms, for example, each form submission creates a new entry in wp_posts.

The difference to CRED forms, where you can specify the post type of the created post, is that the Ninja form is of a private post type, so you don't see it in the admin UI, except when you go to Dashboard > Ninja Forms > Submissions.

In any case Toolset Forms will always create (or edit) a post, or register (or edit) a user.

I'm not sure what you intend your content-less forms to do.

[Ljuba]

well, first, topic was related to Beda, as he asked new topic for it and for such reasons I didn't extended explanation.

But I'm interested on your remark to try to get it well. I have now Booking Form created with Formidable and there is NO ENTRIES FEATURE (so, even if you say how Formidable create post type, here hardly can be the case as nothing > any entry is saved from begin, from submission). So, can you please slightly more precise explain what you mean?

I ask this as I'm now wanted also to open another ticket related to way how to set as more is possible 'products', services',.... per other post types.

So, to repeat, you basically claim that if I will now enable onmy Booking form (created by Formidable) that entries will be saved, you claim that Formidable basically created 'Booking' CPT and that every entry is one single post, right?

[Nigel]

Sorry, you mentioned several plugins, I just happened to look at Ninja Forms.

Formidable may (well, does) have an option to not save form submissions, but CRED doesn't. CRED post forms always create/update a post. You could use the API to do other things as well once the form was published, even deleting the post just created, but the basic behaviour would be to publish a post.

Now, you could build quite a complex form with Formidable and disable saving the form submission. Presumably it too has an API whereby you can do something once the form is submitted.

You could create a form with an first section with various fields that would be used to create one post type, another section with its own fields to create a second post type, and so on.

You would handle the form submission entirely with custom code, publishing posts programmatically, adding custom fields to those posts programmatically, and, for example, using the Toolset relationships API to connect the posts as they are created.

I don't know anything about the Formidable API, but I expect they have documentation for how to respond to a form submission. That API may make the fields submitted with the form available to you, or you can probably just retrieve them from the $_POST object.

[Ljuba]

Well, Formidable let me do with collected data pretty much everything.

To not store it at all (so, to act just as data transmitter), to get list of Entries with particular (chosen) set of data collected by form, to get View of chosen set of collected data and use it to insert it via shortcode at frontend and finally even to create the posts within CPT for such kind of data (and than - ie to keep on to handle it with Toolset).

Thanks to Beda, my Booking Form now is also capable to act opposite and it 'pull out the data from Toolset fields/posts (ie depending on Hotel page/post, Room Selection field in Booking form is populated by Rooms that belongs to that particular hotel, cool, right?) and as you saw above in image, I will not store ANY SINGLE ENTRY (only will act as communication transmitter).

I submitted ticket to Formidable with question how they handle collected data if I will not decide to create the posts (ie only Views), as if that is server side optimized, I can enable much more Products for clients within Compras post type, than I can do it with Toolset. But, we should to see, as same set of data (about product) is same set of data, so .... However, I believe that there must to exist difference if I will use only Entries, only Views or complete Posts (they will explain).

However, this post is created for different purpose and especially for Beda, as he claim that he can do the same with Toolset (what i will prefer, but doubt).

[Nigel]

I'm not a Formidable user so I don't know the details, but if you submit a form with the setting "Do not store entries", well, no data would be stored, so you couldn't use the other Formidable features such as a displaying a view of submitted entries, and if you can, well, it's a logical contradiction and the "Do not store entries" setting is misleading.

Anyway...

I'm not sure what you need to know that I haven't already covered, you need Beda to get involved?

With CRED you *always* publish a post (one post), but the API let's you do things after the post has been published, including delete it immediately, or use the form content to programmatically connect this post to other posts, create other posts (e.g. child posts) and connect those, whatever... You would be limited only by the code you write.

[Ljuba]

You are right, there is nothing what you didn't covered, especially as topic is created for Beda. So, yes, please 'drop' the topic to Beda to see can we (Beda and me) proceed where we stopped in the last topic.

[Beda]

Hi Ljuba

In WordPress, or better, in any electronic device, you either store data or don't.
There is no in-between.

To solve the point where you want a Form, that collects some data, but does not store that data, the form becomes 100% obsolete, UNLESS you do something with the data entered in that form other than with the form (so for example you pass that data to an API).

This, is 100% possible in Toolset and it's easy, the only difference to your mentioned plugins seems to be, that you'd need to add a single code to the Form, which make sure the Post which our plugin creates anyway is deleted again after submit.

Other than that, if it doesn't bother you that a single Post with title is saved in the database, you could use Toolset Forms with just generic Fields and then, listen to those fields with whatever custom code you want to use Hooked to the Forms API.
Then you'd get a form where you can input whatever you want but only post native data would be saved.
Generic Fields are elaborated here below, with the Forms API you are already familiar as I instructed it's usage previously I believe, if you need details on that let me know:
https://toolset.com/documentation/user-guides/inserting-generic-fields-into-forms/

If you want the post to be deleted (means, NO content submission, only form fill out), then you add a custom code snippet that deletes the post to a Forms API Hook (cred_save_data).
You will use wp_delete_post:
https://codex.wordpress.org/Function_Reference/wp_delete_post
Make sure, the form does NOT redirect to the post, as that post will already be deleted by then.

That will leave you with the same exact product as a form, that does not save data.
Combine this with Generic Fields, and no data ever will be saved, only submitted.

[Ljuba]

Unfortunately, I should to remind you that EXCLUSIVE reason to make form with Formidable (to show you what about it is) was REPEATER and fact how visitor first should to select and repeat fields which belongs to 'child post' and just after that to fill the fields of actual (parent) post (post where form is stored and shown on front-end > Accommodations).

So, I should to repeat that my question (how to do it in Toolset?) on what you answered that it can be done, is not done for ABSOLUTELY ANY OTHER REASON, only because I really need it (not just to not want to use another plugin, it is also some new issues about using Formidable for that > not subject here, but just to let you know > Formidable repeater not works with '$parent_post = get_the_ID();//Parent', as "When a repeater is added, it is done with ajax. During an ajax call,
you are no longer inside the WordPress loop, and there is no post to get.").

Back to subject, so, even if I will use generic fields for 'second' form page (as I don't want to save any data), problem remain with first form page and set (group) of data which should to be repeated and which should to belongs to child post, as I can't see that there I can use generic fields as I can't see how generic fields set can be repeated in Toolset, as Toolset don't have repeater itself (as Formidable have).

I can't see any other issue to create same form, except that (repeater), but I also don't have any idea how to solve it and do it, as there is (as far as I know) no way to repeat anything until sort of form will not be created for post where firm should to appear/belongs > to Alojamientos.

So, please be kind and help me with explicit explanation how to do it.

[Ljuba]

To be more precise, you probably get (citation part above) how Formidable support basically claim how your code from previous topic ("Pull data") is not correct as not 'feed' external tools when they are not within WordPress loop. That is for 'get', but I tried all what you suggested and some other methods and no way to get it to work.

In other words, I really need Tolset to do this form.

To repeat, I agree with you and I know (there is zero problem) to make the form if I will first record actual (parent) post (Alojamiento) data and just than in next sequence (tab, page, whatever) to add the 'repeater'.

But my case is opposite. First should to be 'grabbed' 'repeater(s)' and just than the rest.

I will be faced with exact same issue also for food orders, product orders, appointments, ... as always visitors should first to select the food(s) and to repeat it, and just after that to insert other data.

[Beda]

Maybe repeating fields of Types can help you, I am not sure, they are a little different and can be added directly in a Form where you are creating a new post (so the post does not need to exist yet).
Those repeating fields are basically any kind of field (unless a few) that you can set to be having many instead of just one value.
You are however limited in their usage as always only ONE field a time is repeating.

Not like in RFG's where you can repeat the entire set of fields.

To create ANY kind of RFG (wether in the backend of WordPress or in the Front End with Forms) you NEED to have a post.
You can however fake this post.

For example you can use a Form that edits or creates a "dummy post" where you can add all your required "child data" since that post exists.
After, with code hooked to the Forms you either remove, or reset, that dummy post, and port the data from it to any other object.
You can even actually create a post for each interaction, use a nonce as a title, delete it later when you got all data you need to create subsequent data which then MUST be connected ANYWAY to ANYTHING as other wise it will be simple useless enter of data.

So, this will require just as much Custom Code as with other Plugins (well, since those plugins aren't able to connect posts, right?)
It will even be easier with Forms because you will be able to do it all in PHP and WordPress API.
Toolset API will hook your code at the exact point you need it and get data from dummy posts, remove dummy posts, eventually create other objects on the fly so to be connected to the child data entered against the dummy post.

For such extended custom code we can give examples, lead to documentation and consult.
We cannot code it for you

For this, we refer to excellent freelancers:
https://toolset.com/contractors/

The process will require you to work extensively with these WordPress functions:
Insert Posts: https://developer.wordpress.org/reference/functions/wp_insert_post/
Delete Posts: https://codex.wordpress.org/Function_Reference/wp_delete_post

You will need to get familiar with the Posts Object of WordPress and different ways to retrieve it:
https://codex.wordpress.org/Function_Reference/$post
https://codex.wordpress.org/Class_Reference/WP_Query
enlace oculto

You need to be familiar with the Toolset Relationships API (for which we can as well assist), so you can either connect, disconnect, get related posts (includes RFG!)
https://toolset.com/documentation/customizing-sites-using-php/post-relationships-api/

Last but not least you need to know when best to hook all these actions to Forms, which is elaborated here and we can assist with:
https://toolset.com/documentation/programmer-reference/cred-api/

The whole complex workflow cannot be created with just GUI methods using Toolset.
I am quite sure, but do not want to pretend I know, that with other Plugins that won't be any different.

I apologies if the impression surged that you can do all this without code.

[Ljuba]

I spent entire day and I can't see how this can to work.

1) Repeating fields are not the option (there are better options, but still not acceptable).

2) I don't care about the posts, as I will "Enable Automatic Expiration of Post options for CRED Post Forms". So, 'dummy" or not, trough posts or not, irrelevant. Also, no needs for any kind of 'fake' posts.

3) Also, I'm fine to get 3 post types:

==> Initial (parent) > 'Formulario de cliente' without field(s) (somehow should be set automatic publishing - How? On what event? > Nothing is clear here for me???)

==> Subjective (repeatable) > 'Formulario de reservas' with fields related to repeating (one to many < ie Room Type + Number of rooms + Persons ) > Could be also RFG, but I think that it is bad idea. Here is also unclear how to set repeating feature (specifically as there is needed 3 different buttons > Agregar, Editar/Borar, Continuar). Here is also problems how to connect posts and get values in fields.

==> 'Closing' (one-to-one with Formularios) > 'Formulario para destinatarios' with fields of visitors data. It is more simple than to have multi-section form (Formularios) and there are some potential other advantages. However, main issue is related to redirects, what is in this case impossible to implement, as there is no multiple pages, moreover, it is on 'collapsed' section of another post (parent).

CONCLUSION

1) I doubt that anybody can claim how this is simple (or less complicated than with Formidable).

2) I also doubt that basic structure can be more simple. I was very precise with separate forms in 3 posts, as that could be only way to use it for all post types (business types, events, ...). Initial and final are basically universal, only middle form (also repeater) is something what should to change depends on original parent post 9where is located).

However, I don't have any idea what to do to go further (if there is further).

So, please help.

[Beda]

1. OK

2. OK

3. NOK:

3a. Also, I'm fine to get 3 post types: (OK)

3b. Initial (parent) > 'Formulario de cliente' without field(s) (somehow should be set automatic publishing - How? On what event? > Nothing is clear here for me???)

I do not understand.
In above sentence you mention you have:
- A Parent post, without Fields attached.
- You want this parent post to be published automatically?

If so, open ONE ticket, ask how you can publish Posts automatically with Toolset Forms, and I will answer, it is not possible, because no tool in the world will publish posts automatically for you unless an AI.
What can be done, are workarounds like trigger a certain WORDPRESS (not toolset) code on certain TOOLSET hooks (explained in our doc).
I hope this is clear, we can otherwise discuss this in light in another post - where we will discuss how to automatically insert posts - but you will need to tell me based on what automatically should happen this.
I cannot guess the event for you, you need to tell me "I want a post published when I click that button".
Then, I can tell you if it's possible and how.
Usually you will hook your WordPress Code to the cred_save_data and hook that to the Form where you want it to happen.

3c. Subjective (repeatable) > 'Formulario de reservas' with fields related to repeating (one to many < ie Room Type + Number of rooms + Persons ) > Could be also RFG, but I think that it is bad idea. Here is also unclear how to set repeating feature (specifically as there is needed 3 different buttons > Agregar, Editar/Borar, Continuar). Here is also problems how to connect posts and get values in fields.

This process has to be as outlined:

- create upmost parent post OR
- create first child of this upmost parent and with Code insert as well a Parent on the fly.
- no matter what later insert CHILD posts to the above middle posts, one by one, with Toolset Child post Forms.
Data from parent can be get by the ID of parent and ID attribute of ShortCodes and PHP.

If you do not understand how to get information from parent posts on a child post form:
==> ONE new ticket, ask me how, and I will reply exactly how you can access the information of parent posts in a child post form (Hint: https://toolset.com/forums/topic/displaying-data-from-parent-post-type-in-cred-form/#post-602522,)
However I do to think this was the difficulty here.

Repeating here is a bad approach, I agree.
Child Posts instead should work fine.

3d. ==> 'Closing' (one-to-one with Formularios) > 'Formulario para destinatarios' with fields of visitors data. It is more simple than to have multi-section form (Formularios) and there are some potential other advantages. However, main issue is related to redirects, what is in this case impossible to implement, as there is no multiple pages, moreover, it is on 'collapsed' section of another post (parent).

I do not unterstand.
What is collapsed? What has that to do with Toolset?
Redirects to multiple pages are simply impossible, no computer will redirect you to multi page.
If you refer to dynamic redirect, sure that is possible with Toolset Forms, as stated, you apply the API:
https://toolset.com/documentation/programmer-reference/cred-api/

I still do not know where the issue is of "I cannot crate forms that save no data", or "content less" forms.
I have seen 0 reference above to making any effort of following my steps outlined here:
https://toolset.com/forums/topic/content-less-form-with-repeatable-field-groups/#post-1091057

CONCLUSION

1) OK

2) I also doubt that basic structure can be more simple. I was very precise with separate forms in 3 posts, as that could be only way to use it for all post types (business types, events, ...). Initial and final are basically universal, only middle form (also repeater) is something what should to change depends on original parent post 9where is located).

If you want to load forms conditionally, means, depending on where you come from you see this or that form, this should be possible with a simple step:
- create several forms that do what they need to do each in a single post type
- create a page insert the forms
- wrap them in HTML conditions that listen to a URL parameter (any of your choice)
- to any link that leads to this page, or any form leading to id, append the correct URL parameter either with Code or with HTML.
- that will then dynamically show the forms

However, I have no idea how this relates to creating forms that do content less automatic posts.

So, please help me to understand if you require help.

[Ljuba]

Hi and thanks for extensive reply. As here is 4:30 morning, my concentration is on zero level and I will go to sleep. However, as you will be back only for Tuesday, I will review it anddo my best. In meantime, please comment this two thinks:

1) Yes, I also thought about that how is probably impossible to have that initial post publish automatically and on unknown event. I let it under the question only as I thought that maybe is possible to do that by click (event) on first (any) of the field of the child (repeater) post (so, child post by click is not published, but it is kind of event).

So, just answer on that > is it that possible or not. If not, I will probably for each kind of the complete forms, place at least one field. Example, for Booking (this form), I can move Entrada and Salida from 'repeater form' to 'initial form'. In that case, I think how data selection should be good choice for event what trigger the publish action.

2) I thought that my 'initial post' could (should be' be 'upmost parent post', but it looks that I didn't get the concept. Please some more links and/or explanations.

ALSO COMMENT

3) "I have seen 0 reference above to making any effort of following my steps outlined here:"

I thought that I followed it, only that I quit from 'content less' and thought that is easier to go to concept of 'post expiration' (especially as there are some positive potential benefits).

4) "However, I have no idea how this relates to creating forms that do content less automatic posts."

I agree (above I explained), but I seriously couldn't see (or understand) how that can be done with Toolset. For that reasons I decided to apply concept:

==> Initial post (basically should to act as "dummy" as no data should to be grabbed/saved). However, it is 'initial post' and parent post for other (below described) two forms/posts.
==> Second is related to main page/post where form appear, should be repeatable and to change content depending of 'host' post (ie menu for restaurants, products for shop posts, ...). Data could be removed by 'expiration feature'.
==> Final form (should be second page) is recipient data form and potentially could be interested to collect data. Zero repeating fields.

'SMALL' REMARKS (nothing personal, targeted to Toolset, exclusively)

For you understandable looks weird if somebody hardly understand Toolset logic, but I'm 100% positive that I in practical form example (on this case), demonstrate to you how other tools using complete different logic/approach and for users who are familiar with that approaches, Toolset is kind of difficult to understand. Formidable form I created in one hour, Toolset maybe I will not be able to make neither after 5 days (or ever). So, it is also kind of frustrating (what affects entire process as well).

From other side, material fact is that Toolset don't have ANY SINGLE example (reference site) of ANY OF ELEMENTS in this topic:

==> A) Repeater Form
==> B) MULTI-PART/PAGE Form
==> C) "Dymmy" Parent Form (in sense of topic > to get event for child post form)
==> D) "DATA PULL" form (whatever, from parent and/or child)

Hopefully, my remarks will be understood in right way.

[Beda]

1. Sure. With code, you can do whatever you like on machines.
Hence this is possible.
Both with PHP or AJAX.

We cannot, however, provide such code.
Here is what you will need:

- Either a JS code that listens to button clicks binds an AJAX event that creates a post in the database on the fly.
- Or, a button that triggers some PHP to be executed for example by submitting of a form or loading a template.

According to whatever data you collected let's say from the $_POST form variable you populate what your code inserts.

2. I am not sure what you refer to?
What your first post is; depends on what you want to do with it and how you want to relate it to others.

Let's say you want first to create a child post type and connect it, that logically means ahead of this you already need a specific parent as otherwise there will not be anything to connect with.

3. OK, I still have no idea where in the entire process you failed and need more information or what the issue is.

4. This is majorly OK; but let me clarify that in Toolset Forms, EACH form acts upon ONE type and cannot be used for other types.
You cannot have ONE form that depending on its parent TYPE loads a differnt post type form (only the content of the form could change, but surely not its type, not without extensive custom code)
Hence you need several forms; there is no way to address dynamically post types in one forms without code (extensive code)

Sure, I understand the remarks and now I think is time to move on.
I am playing for some time with an idea to solve this - because we keep spending time understanding each other, rather than to explain/solve.

My idea is:
- if possible for you, prepare a small website with whatever tools you want/need for it, where you show our logic.
==> Note, it does not need to "work" - It is enough to prepare pages, which have a context like:
- here a form to book a room should appear, and it should contain these inputs:
- etc
- etc
- then the form is submitted, and should:
- etc
- etc

Once done, share that with me.
Note again; it does not need to work, but needs to show the process and data requirements and steps as precise as possible.

Then, if things are unclear on what you plan to build we can agree upon a Google Hangout call to clarify:
https://toolset.com/toolset-support-policy/ask-support-video-call/

After, I will do everything possible to instruct you how to / if you can build that with Toolset.