Attempt on creating unfinished form saving for multi-page form

Gravity Support Forums » Plugin Support » Gravity Forms

Hody
Member

Hi everyone, our teams are implementing the unfinished form saving for multi-page form, which was topic mentioned by a few people before. We managed to create a few functions to create a draft of custom post which we use to store the form data, and updating the data when going to the next page. All the form fields are stored as custom fields in the custom post. The custom post will be published when the form is selected.

Now the problem we are facing currently is that, we can't figure out a way to repopulate these fields back into the empty form, I wonder if anyone who might have experience implementing similar function may help or pointing us the direction we can look.

Thanks heaps!

Hody

Posted 13 years ago on Thursday November 24, 2011 | Permalink
Chris Hajer
Key Master

I don't know of anyone who has done it. Sounds like a neat idea though.

When the visitor starts to fill out the form, the draft post is created. When they advance to page 2, values for page 1 are stored as custom fields in the draft post. Is that correct so far?

Let's say they stop at that point and come back later to return. How do they go about finishing their form submission? How do you get the ID of the draft post? Once you have the ID of the post, and you know the meta keys that are used, and your form is set up to allow dynamic population for all fields, you will have to pull the custom fields out of the post using get_post_custom which will return all the meta information stored. All you need is the post ID.

With that, you can use gform_field_value_$parameter_name and some code in your plugin or theme's functions.php to pre-populate the form with whatever information you have.

Neat idea. I'd love to see how it turns out.

Posted 13 years ago on Friday November 25, 2011 | Permalink
Hody
Member

We are generating an serial code at the first step of the form, which we use as the title of the custom post draft, therefore we can retrieve the post ID.

To make the plugin dynamic enough to inline with the form, we use the form field parameter_name (I presume you meant the "input_213", not the form filed label?) as the custom field name, so we can do the population later on. So from what you are saying, basically we just need to use gform_field_value_$parameter_name to populate the empty form? that is gform_field_value_input_213 I guess? Am I right?
Thanks a lot.
Hody

Posted 13 years ago on Friday November 25, 2011 | Permalink
Hody
Member

Oh hang on, the parameter_name is the label you put in when you checked the "Allow field to be populated dynamically"!

Now I get it. We will give it a try!

Posted 13 years ago on Friday November 25, 2011 | Permalink
Chris Hajer
Key Master

Sounds like you're on the right track. Please post if you need help.

I like the serial number idea. I was thinking they wouldn't even need to be custom posts, just posts, so you can use the postmeta, and could be a in category you never publish on the blog. Interesting idea.

Posted 13 years ago on Friday November 25, 2011 | Permalink
Hody
Member

Ye, the idea of using custom posts was so we don't have to show that in the backend to the client. And do you have any idea how can we instead of using gform_field_value_$parameter_name , we can some how use the form field ID? As at the moment I'm sure how we can match the form field ID custom fields with the $parameter_name.

Posted 13 years ago on Friday November 25, 2011 | Permalink
Chris Hajer
Key Master

What did you use for the parameter name for each field, when you checked the box "allow this field to be populated dynamically"? You have to populate all those with something. It should be populated with the same thing as the meta key (custom field name) I think, just to make it easier on yourself.

Posted 13 years ago on Friday November 25, 2011 | Permalink
Hody
Member

I was using $_POST to get all the form info. However I won't be able get the reference of parameter name for each field. that's why i have the field ID like input_253. Any idea how I can resolve that?

Posted 13 years ago on Friday November 25, 2011 | Permalink
Chris Hajer
Key Master

Are you talking about when storing the values or retrieving them? You lost me there.

Posted 13 years ago on Friday November 25, 2011 | Permalink
Hody
Member

The method we use to obtain the form data was through $_POST, therefore they look like this:

array (
'input_249' => '413',
'input_250' => 'e2583c21415fc11e6d111321ad69877b',
'input_201' => 'Option 1',
'input_2' => 'Mr',
'input_17_3' => 'hody',
'input_17_6' => 'hong',
'input_18_1' => '1/sdf/s ',
'input_18_3' => 'sdf',
'input_18_4' => '',
'input_18_5' => '12312',

the data wasn't identified with their parameter name, instead they have field name: input_2. The problem we have here we couldn't associate them back to the form.

Posted 13 years ago on Saturday November 26, 2011 | Permalink
Lucas Stark
Member

Check this out https://apply.ocean.edu/. This is a demo site for now, and is currently underdevelopment however here are the features we built for this:

Require logon, redirect to logon form ( user registration plugin ).
Allow Save and Continue functionality - If you begin filling out the form, move forward at least one page, your values are saved on the backend. If you navigate away from the form, close your browser, or log off / log back in you will be presented with the last entry you were filling out, and will be at the last page where you stopped at.

I've also written the add on so that it automatically does the pre-population on the fields, so users do not have to worry about remembering to check the box.

Let me know what you think

Posted 13 years ago on Monday December 5, 2011 | Permalink
dubmethod
Member

I'd love to see the code for the finished product. Someone actually posted a solution a while back but it required updating some of the plugin's files.

Many thanks,
Rebecca

Posted 13 years ago on Wednesday December 7, 2011 | Permalink
demember
Member

We implemented a sign up and save/return feature of a 12 page application - http://www.thielfellowship.org/applicant-login/

We close the app at new years and will need to reopen similar functionality for the next round. If there's any way we can contribute anything to the next release (which I'm hoping includes save/return function), please let me know.

thanks,
dave

Posted 13 years ago on Tuesday December 13, 2011 | Permalink
llooii
Member

I've nothing else technical to add here other than to mention that this feature is a fundamentally important one, and I for one really need this functionality for a site I'm building. I hope to see the outworking of this one yesterday - keep up the good work guys!

Posted 12 years ago on Sunday January 1, 2012 | Permalink
ixistudio
Member

I would also be happy to see the code for this, its a great idea!

Posted 12 years ago on Thursday February 23, 2012 | Permalink
GZA
Member

I love the sound of this idea and in some ways it will tie in with what GF has planned for 1.7, i.e. front-end editing.

The form I am planning to implement will have at least 4 stages (pages) and the one thing I haven't taken into account is you have no control over how long people take to complete forms.

Since there's not currently any support for front-end editing in GF I am now thinking of custom solutions.

Posted 12 years ago on Friday February 24, 2012 | Permalink
donaker
Member

Hi oceancountycollege,

I need to create a very similar save and continue functionality. Would you be interested in discussing how you accomplished this?

Thanks,

Don...

Posted 12 years ago on Wednesday May 30, 2012 | Permalink

This topic has been resolved and has been closed to new replies.