Patch adding save draft feature

Thanks, I'll take a look at this functionality. The code just needs some minor cleanup, but we'll definitely need to write an update hook if this gets into the main version of webform. It'll also likely only be added to the 2.x version of webform, since I'm trying to shift away from 1.x which will not be ported to Drupal 6.

Marked http://drupal.org/node/176598 as duplicate.

Here's a forward port to 5.x-2.x-dev, with an upgrade path.

Re-roll against new version plus some small bug fixes.

Marchingy what version is your re-roll for? It doesnt seem to work with the current one. Anyone have an updated copy of this feature? Its just plain awesome.

Richard

I hope someone implement this function in to webform core in the next version.

This is definitely planned for the 2.1 version of Webform. The 2.0 version had been in beta for so long, I wanted to get it out the door before adding this feature (which very well may introduce new problems). When I get some free-time I'll integrate it for the next version.

This patch has gotten out of date. A few additional comments:

- A large chunk of code in this patch is changed by unnecessary nesting of IF statements, we should put together if ($submission && user_access('access webform results')) { and if (!$is_draft) { into a single IF statement.
- Why is "#no_validate_on" needed? I don't see how this is any different from using the $_POST['op']
- If we can change both "allow_draft" and "is_draft" columns both just to "draft", that'd please my desire for consistency and short column names.

Is this a Save Draft patch for the stable Recommended for 5.x version (5.x-2.0)?
Saw the last patch here is updated April 11,2008, and Webforms 5.x-2.0 was released May 09,2008 so not sure.

Thanks,
Ari

PS seems like doesnt work, last patch updates successfully but always get this warning on each page, seems like cant find webform.module and therefore display webforms i created earlier today:

* warning: include_once(./sites/all/modules/webform/webform.module) [function.include-once]: failed to open stream: Permission denied in C:\Program Files\Apache Group\Apache2\htdocs\drupaltest\includes\bootstrap.inc on line 512.
* warning: include_once() [function.include]: Failed opening './sites/all/modules/webform/webform.module' for inclusion (include_path='.;C:\dev\php\PEAR') in C:\Program Files\Apache Group\Apache2\htdocs\drupaltest\includes\bootstrap.inc on line 512.

hey marcingy,
just wondering if this patch is for the current stable release or for dev one?
didnt work with the stable branch.
Thanks for any info

Tried spending part of today trying to get the Save feature to work via the previous patch released. Looked at each change in patch file with very very few mods (comments mostly), and modified code manually for each change.
Thought i got close. but for some reason, even though $validate is off, some fields still try to validate when click on Save Draft.
Attached is what i have so far (note: i echo some variables at top just to make sure validation is off).

Yikes, armyofda12mnkeys, could you contribute your changes using diff and patch?

http://drupal.org/patch/create
http://drupal.org/patch/apply

Patches allow me to easily review the changes, as well as apply them as long as the exact lines of code don't change.

Here is 3 patch files (remember database needs allow_draft and is_draft)

So to duplicate, make a simple form with a mandatory file (or as i observed mandatory grid component also does the trick).
I just made simple non-required yes/no quest, required file, and required textfield.
Since its a draft, the required fields shouldnt make a difference. but the upload field does complain its not filled out when saving draft.
Any idea where it invalidates the form so can add a if(!$is_draft){//then validate file/grid/others? fields}
Remember to go into the webforms Advanced Settings to Allow Draft.

I just tried to port the old code over, maybe too many changes were made for it to work.
PS dont even try to test page breaks seems like save draft breaks that currently hehe.

* btw i got forms without those certain componants to save, so let me know why those fields try to validate.

I noticed i was calling web_client_form without the 6th parameter is_draft in a few places (the three webform_menu items that call it and webform_view).
Changed those former items to
'callback arguments' => array('webform_client_form_'. $node->nid, .... , FALSE, FALSE, $submission->is_draft),
and latter to:
$form = drupal_get_form('webform_client_form_'. $node->nid, $node, $submission, $enabled, $preview, NULL, $is_draft);

(btw I also added some code to results so drafts dont get included in the Analysis, and other places in that Results tab ill get that code up later when basic stuff is more working :) )

got a bit further...

This line 'could' be set to in addition for setting all required fields set to 0, to not check the custom validate functions (ill give some reasons why this is not perfect later)...
if (!$validate) {//if validate is false, set not required
$parent_fieldset[$component['form_key']]['#required'] = 0; //change this so loops over the $parent_fieldset[$component['form_key']] for required fields to set to 0
unset( $parent_fieldset[$component['form_key']]['#validate']); //unset other required functions here; however would be nice to still validate certain things, like a file is valid. more info later
unset($form['#redirect']);//guess this does something good :)
}

This will 'work' for the upload field but for the grid componant, it has a standard required field, but in a array level below $parent_fieldset[$component['form_key']]. so you could instead of that 1st check, loop over the array for the required field and unset it as i mentioned in the //comment above.

So then file uploads and grid componants wont be checked for validation, however for file fields....
they can upload then invalid files, like if i change the value of the file field to c:/somefakefile.txt it will create this fake file on server.
To get passed this, possibly change function names of these kind of validations, like _webform_ALWAYS_validate_file so that we can check the callback name for that function set in #validate for _ALWAYS_ and see if that validation function should really be unset at this stage.
and another side effect of this is when they get back to the form, a hidden field is not set to the current filename.
This would be useful as when you now submit the form, if a hidden field is set to a filename already, there should be code to validate against that file, and not the blank file field.

Anyway, I'm messing with it, will post if get anything meaningful. Hardest part i think is adding the hidden form field validation for already uploaded files (from saving before).

Almost there I think: I set a function to recursively get rid of required fields if saving (good for grid componants which are nested), and also if saving look through validate to unset all functions except those which have a 'ALWAYSCHECK_' in function name (like file existance should still be validated but not requiredness so you need this new way to validate).

Only thing now is to change the validation so covers all those darn saved filename all scenarios when resaving or submitting....
EDIT:

<?php
if(saving)
{
	if( is there a file already uploaded for this question?)
	{
		delete old file
		upload new file
		validate new file (since saving should only do the ALWAYSCHECK_ functions)
	}
	else if uploading brand new file or no file which will result in no error if required
	{
		validate new file (since saving should only do the ALWAYSCHECK_ functions)
		upload new file
	}
	else if didnt pick a file
	do nothing, dont worry bout it until u save.

}
else//submitting
{
	if( is there a file already saved/uploaded for this question?)
	{	
		if(submitting with that same file saved from before, so basically didnt choose a file via Browse)
		{
			validate old file (since saving should do all the function validate checks now )
		}
		else//resubmitting new file
		{
			delete old file
			upload new file
			validate new file (since saving should do all the function validate checks )
		}

	}
	else if uploading brand new file
	{
		validate new file (since saving should do all the function validate checks )
		upload new file
	}
	else didnt pick a file 
	validate file, will error by validation checks if required field.

}
?>

There is other code in there too, like validate file for some reason acts very funky when submit non-system url path, like pretend accientally typed in file textfield 'asdf' instead of 'C:/real_file.txt' via browsing for file. So instead of 'return;' in that file validate function, I think u need to do a check in there.
Like in IE5 it wont even submit surprisingly (buttons dont work unless valid filename lol), and in FF, it will not validate bad files, and saves (sometimes i think creating a 0kb junk file on server which i also check for).

I dont have time to do a diff since my cygwin diff and even my linux diff just copies all the old module, and then all the new module. My last diff i did manually for each file via a Win program called ExamDiff. Could this be related to windows line breaks basically saying the whole new file is different since each line ends with windows linebreak and old file has unix newline? looks like this:
-whole webform.module file start
-etc
-whole webform.module file end
+new webform.module file start
+etc
+new webform.module file end

Testing this on 5.2.1.1 btw.

Then testing and seeing if can get multi-step forms to work with Save Draft feature.

Yes, Windows will cause funkiness with line endings. Make sure you use a text editor that is smart enough to understand line endings and saves the new document in the same format at the original. Webform uses all UNIX line endings (\n).

Hey,
i think this works unlike previous example i uploaded, but didnt test for Multiple page forms which prob will break this (but file uploads seem iffy already with mult page forms as i remember). Anyway I'll test that part tomorrow.

I messed with old save patch and got it working to where i want it. Also changed so Required file uploads get a '*' too via some javascript since file doesnt using drupal's #required validation and its own validation functions. also when saving, #required is unset so drupal doesnt error on us, but to do this, if there is an error like file validation fails on a save(bad filename or extension), then page wont have the '*' for any field, so i also added some javascript to add that just in case that scenario occurs.

Its pretty HACKISH since i dont know the whole module and sometimes how to pass things around. One feature i added which might not be usable is where all file downloads goto $nid/$sid but like i think the way i did it was ugly so probably convert code back to regular way in _submit_file() and _insert. aka go back to old way of naming files in generic /webform folder.

I added some stuff so user editing/view his own webform can look at the file he submitted (before after you upload it, and save/submit form, you cant look at the file you submitted and only those with 'access webform results' can, booo), worked really nice with file uploads in drupal set to private.

I also added code to results so drafts are accordingly seen as Drafts in Submissions and Table and not included in the Analysis results yet.

Might want to add code to Delete the current file attached to a question if you are webform admin type or editing own webform, (and if so set it back to is_draft in database possibly if the field is required since webform wouldnt then be complete and let user know with drupal_set_message ).

I dunno why but both linux and windows cygwin, and my windows diff prog, give me problems with linebreaks doing a diff patch, so can someone run a diff on both current 5.2.1.1 module folder and this zip folder attached?

if you can i can take a look and clean up the bad stuff like whitespace changes in the diff file.

this ISNT production ready!!! use at own risk! i have a feeling the naming structure of directories change will be asked to be removed from my changes.
EDIT:
in file.inc, pass change all setFileComponantError() to setFileComponantError($form_key), including the function definition, just realized the code to 'redden' file fields wasnt being called.
Also i think i had a variable $filename i didnt use in _file_download function in webform.module right after i declare the global $user;

heres the patch. figured out I needed to run diff with --strip-trailing-cr for windows/linux line differences...
Can anyone let me know how it is?

only thing i am not sure about is _webform_submit_file/webform_insert functions and how they handle creating directories based on nid/sid, like if its gaurenteed to create unique dir when 2 people submitting at same time. can take that out and use old code if you want. rest seems fine.

if you want to know what something does in the changes, just shoot me a message here or my account

changed the status to needs review cause i dont see any activity here. anyone lol?

I'm discouraged by the path this patch has taken. The original patch was 26K, worked, and was immaculate in code style. What happened here that made it go so far off course?

I'd like to reinforce that any code developed in Drupal should follow coding standards: http://drupal.org/coding-standards. Right now I wouldn't accept this patch under any circumstances because I'd spend hours just cleaning up all the code-styling issues.

On top of the aesthetic issue, anything that feels hackish probably is worse than it looks. I'm not going to make the mistake of accepting a patch that is going to cause a plethora of bugs and reliability problems, after everyone gets in their changes I'm the one maintaining it for the foreseeable future. Please continue the efforts, but I think this patch has gotten out of control with fixes on top of fixes.

sorry im not that great of a developer, just thought id try my hand at it. I have tested it and it works for me at least, but i understand why not willing to accept patch. just thought someone could look through and improve on it.
Again sorry. it does seem hackish mostly cause file uploads are handled a bit differently so it is like you said, fixes ontop of fixes. like the drupal core bug that you have to check required-ness differently for it. ill look into the coding standards.

I don't mean to be entirely discouraging. I'm still looking at the patches every time they're updated. This patch just needs a lot more work before it'll be added to the project.

Thanks for directing me to this post, Quicksketch. I really did search, but didn't find it on my own. Development is not my strong point, but I'm learning. I'll take a look at the patch above and see if I can help.

Joy

an updates since your last attachment, armyofda12mnkeys ? I'll help out in dev

lefnire, kinda still messing with original posters attachment. i think the last attachment was usable for that version.

i just started last week porting changes to drupal6 and think its functioning almost there (have a few bugs if you want to help out lefnire, private message me if you want). i do feel some of the hacky stuff is still needed and itll prob just be a patch versus included in the module. Like I'd rather the user know a file is required with javascript hack versus try to mess with drupal's core file/validation functions.

sidenotes:
i'll look over some changes i made in drupal6 and post those so maybe so the drupal5 patch can be updated. (like when admin submits previous users submission i think i accidentally used the $users->uid to update submission, when it should be the $node->uid.
maybe some functions where i pass in something like bleh($form, $form['submitted']) and 2nd param not needed.
Also in the drupal5 module, i rethinking the file_download path i think i used something like: /webform/$nid/$sid/$file.doc since i think it might be not safe for $sid when many users submit forms at once. /webform/$nid/$file is probably fine enuff.
and with drupal6 i was a bit vague when to use $form_state versus when $form available, (and $_POST :), for example i didnt see the 'op' variable in anything other than $_POST, so i just use where i saw the variables were available. Have to pick up PDD6 book to really get into drupal6 soon ).

working on new drupal6 patch, on closer inspection needed more work done. will update soon. will appreciate if can improve my code so i can learn from it, as i am learning Drupal by messing with this module hehe.

For my site running Drupal 5.10 - Is there a complete patch that I can put on a current production site? I can't tell from above if its safe to do so or if work halted on a 5.x patch before it was completed. Thanks!

No work is being done on 1.10, nor will any features be added to it. I'd highly suggest you upgrade to the 2.x version of the module, which will eventually gain this functionality.

Anyone would like to test out, I went into more detail making sure everything worked as i expected it to.
Sorry if patch is too large... I put alot of comments in on many lines explaining what/why I did to help myself. Plus the changes needed for implementing such a big feature like saving drafts is going to take up more space than original patch as it was more limited in scope. Plus my coding isnt the most efficient :).
The code isnt really elegant, for example I think new theme_webform_view_messages() could be cleaned up and shortened possible quite a bit (thats an understatement), and hook_file_download too (the messages are pretty detailed just to make sure perms and everything working correctly but bleh i know it could be made better by a better programmer).
Biggest help to me is to show me how to do certain aspects better, like bad things i did in programming/drupal module development. P.S. ran Coder on it already

So in summary, the changes i made...
1. Should be able to save now. Made these changes into Webform 6.2.2, but saw 6.2.3 was released pretty soon after, and merged those changes into mine
(multipage pages though i havent tested very thoroughly but they are tricky in original webform anyway. Wouldnt recommend multipage if using fileuploads)
2. hook_file_downloads checks for rights to the file, ie original author can dl his own files he uploaded if has access to it.
This may be good when he saved a file in a draft, and before submitting it later, wants to know if file he uploaded was latest revision.
This function can be improved, it looks long and messy but gets the jobs done.
3. Most componants when saving if they are required dont need validation. Files however need validation even if saving (make sure valid file/extension etc), so we validate it by naming validate function in special way. Other componants can use this, but I dont think any would except files.
To save, have to loop through form and unset #required for all componants, and unset #element_validate for all componants except 'file' componants special '_CHECKALWAYS_' function. Not sure how to make it so more elegant, but gets job done.
4. Can now delete a file you uploaded if have access to do so.
Will delete as much info as can do, i.e. delete from {files}, {webform_submitted_data}, unlink file. This could use cleaning up as i wasnt sure how to delete and set corresponding appropriate error message on why something could/couldnt be deleted.
5. File validation is a bit stronger i think. For example now makes sure no php file errors. In one case before, a silent file upload error happened (because of internal php.ini filesize limit) and only php seemed to know about it. Drupal somehow missed it. Also IE6 had a case where uploading a file that doesnt exist (like accidentally changing name of file in the file's textfield), and checking for filesize=0 seems to find that edge case. P.S. FF/Opera just find this case before even submitted via AJAX i think.
6. Required files, because of core drupal bug, dont have '#required' set, and therefore, dont have "*" next to their question i remember. A javascript hack is added to make up for this, by dynamically adding it. Not sure of better way to do it, but better than not give user feedback at all.
7. Usually when an error occurs on file componant, an error class is set on it, but some browsers (FF3 i think, and FF2 is very light red versus IE and Opera which are ) dont seem to respect border-color on file form element. I added code so if error set on form element, also add error class to the

Thanks for your continued work on this armyofda12mnkeys. The code is improving with each iteration.

It seems like this patch is taking on A LOT more than just adding drafts. All these listed changes don't seem to have anything to do with saving drafts:

2. hook_file_downloads checks for rights to the file, ie original author can dl his own files he uploaded if has access to it.
This may be good when he saved a file in a draft, and before submitting it later, wants to know if file he uploaded was latest revision.
This function can be improved, it looks long and messy but gets the jobs done.
3. Most componants when saving if they are required dont need validation. Files however need validation even if saving (make sure valid file/extension etc), so we validate it by naming validate function in special way. Other componants can use this, but I dont think any would except files.
To save, have to loop through form and unset #required for all componants, and unset #element_validate for all componants except 'file' componants special '_CHECKALWAYS_' function. Not sure how to make it so more elegant, but gets job done.
4. Can now delete a file you uploaded if have access to do so.
Will delete as much info as can do, i.e. delete from {files}, {webform_submitted_data}, unlink file. This could use cleaning up as i wasnt sure how to delete and set corresponding appropriate error message on why something could/couldnt be deleted.
5. File validation is a bit stronger i think. For example now makes sure no php file errors. In one case before, a silent file upload error happened (because of internal php.ini filesize limit) and only php seemed to know about it. Drupal somehow missed it. Also IE6 had a case where uploading a file that doesnt exist (like accidentally changing name of file in the file's textfield), and checking for filesize=0 seems to find that edge case. P.S. FF/Opera just find this case before even submitted via AJAX i think.
6. Required files, because of core drupal bug, dont have '#required' set, and therefore, dont have "*" next to their question i remember. A javascript hack is added to make up for this, by dynamically adding it. Not sure of better way to do it, but better than not give user feedback at all.
7. Usually when an error occurs on file componant, an error class is set on it, but some browsers (FF3 i think, and FF2 is very light red versus IE and Opera which are ) dont seem to respect border-color on file form element. I added code so if error set on form element, also add error class to the holder of file componant so makes sure user sees it.
8. Results page show if submission is in saved draft state and the Statistics page, doesnt take into account unsubmitted drafts to calculate it's data.
9. Modified webform page to allow user to look at his previous submissions.
10. I use popup help text within webform. Like in my question I use: "Hopefully you know this worddefinition?". and if click on 'definition' superscript, it will look in question's div container for an element like help, and show/hide it appropriately. In order to do stuff like this, the question description is run through full html so can have those attributes. then i use jquery (as a webfrom 'markup' type, to hide and unhide as needed). Security should be fine since content editor is making up the webform questions and regular users need them interpreted, hence filter access bypass. If not, go back to old check_markup.
Could also setup description field yourself as format type, and store the format. but this seems like hassle/more complicated.
11. Some code I modified so uses Drupal6 file ID (fid), instead of filepath, for quicker lookups.

I'm not saying these aren't problems that should also be fixed, but we should create new issues for each one of these problems rather than bundling them all into a single patch. I have some better solutions to the required file fields specifically that we can use, but I'd prefer to discuss them in new issues rather than this one for adding drafts.

Also, you can save yourself a huge amount of work by installing and using CVS instead of downloading tarball files. Since there is new code already in CVS since 2.3, doing this will help keep you up-to-date inbetween official releases.

okay sounds good. i'll try to separate them and add as separate issues. any duplicates? or you'll mark it duplicate after I input

Hello there,

firstly thank you for the great work!

Is this patch only working for version 6.x-2.3 or also for the current version 6.x-2.6?

And if not, is it possible to downgrade from 2.6 to 2.3 version of the module without problems, because I really would need this feature?

About an answer I'd be really happy!

Best Regards

sdk

It is for version 2.3 with some 1 or 2 other patches included in it that were critical to my site (getting files to upload inside of fieldsets).
I havent really worked on it lately but there is a more updated version than one posted here. I just didnt see a way to cleanly separate all my changes.

I've taken this back to basics... I went to the patch in #4 and got it working in 6.x-2.3. Perhaps without all of the new features and patches being jumbled together we can get this feature tested and added into the code.

@ #38 (libelulahmk)

Great work! I've applied the patch to Webform 6.x-2.6 and it works perfectly. My testing has been somewhat limited, but so far the patch works as expected with no undesired interactions.

One related feature I'd like to see included here is the ability to "Save and Continue" when paging through a multipage form--even for anonymous users. I don't mean that anonymous users should be able to retrieve and edit their submissions. Rather, I'm looking to get a lead even if they don't complete the whole form. In terms of conversions, I think most folks would like this functionality. I'll try to look at this myself over the weekend.

Thanks for your work on this. I'll be doing a lot of testing over the next week, so I'll post back if I do find any issues.

~Joy

Update... immediately after applying patch, everything worked as expected. However, upon exiting the system and logging in again, there appears to be interaction with Webform permissions and/or tabs. When logged in as user1, the "edit" and "results" tabs have gone missing. I can, however, browse directly to the edit or results pages using node/nid/edit. Reverting to Webform 6.x-2.6 sans patch resolves the issue. Unfortunately I haven't had the time to investigate further, but wanted to post this in case anyone else experiences something similar.

~Joy

I am also looking for a way to have "Save and Continue" type functionality. My plan was to have the Next and Previous Buttons "save as draft" and move to the next/prev page. Since I'm also working on non-linear navigation that provides links between pages, I had planed on simply redirecting to the next/prev page using a query string variable after the values were saved.

I am having issues with $form_state not getting set, presumably because I am not moving to next page using $form_state['rebuild'] = True. This causes me to blank out the values if I "Save Draft".

So I'm wondering how and where I load up the values already submitted and in the database into $form_state in order to make this work.

- Matt

http://3281d.com/node/19 (subscribe)

Subscribing

Moving to the queue for Webform 3.x. I'd like to fix the problem with required fields not showing as required (basically the same problem as #266287: mandatory components interfere with previous page button ). I plan to work around this problem with #469782: Provide a Webform-specific Form Element Theming.

following

I tried the patch in #38 in 6.x-2.7. So far it is working fine.

I noted one problem with the upgrade: The fields allow_draft and is_draft were not added to the database tables. The problem is that the function webform_update_6206 puts SQL commands into a $ret, but doesn't return $ret, so the upgrade function does nothing. Solution: make line 50 of the patch read "return $ret;" or add that to the end of the webform_update_6206 function after applying the patch, but before running upgrade.

Subscribing

Here is another solution to the required field problem. Currently, webform removes the required marker so that Drupal does not complain when required fields are empty:

$parent_fieldset[$component['form_key']]['#required'] = 0;

Instead, mark each field as already having been validated, thereby stopping _form_validate() from doing the required field validation:

$parent_fieldset[$component['form_key']]['#validated'] = true;

The attached is a slightly cleaned up version of the patch from #38 that

a) removes some of the left overs from the Drupal 5 patch, including unused menu items and theme functions and

b) reworks the update hook to use the Drupal schema api.

It works in a very limited webform installation I needed it for, but probably needs a bit more work to be generally applicable to all webform installations.

Attached is a new version of the save draft patch. I started with the patch in #38. I added the fix to the upgrade problem mentioned in #46. This version gets around the field validation problem using the technique mentioned in #48. As a result, when users click Save Draft, they are taken back to the original form with a “Draft Saved” message set, rather than to a confirmation page. This patch is rolled against 6.x-2.7.

I have applied the patch from #38 and it works great but I seem to have a problem with receiving the emails of completed forms. If the save draft button is used and then later the webform is submitted, I am not receiving the completed form by email. If the save draft button is not used, the submitted form is arriving in email without issue.

@Liam
Do you think you can re-roll your patch against HEAD (6.x-3.x)?
That is the release where this will be implemented eventually, as it will not make it into 6.x-2.7.

Awesome work so far on this feature!
Good to see movement in this direction.

I have encountered the same problem. Any from that was saved as a draft does not get emailed when it is finally submitted.

Liam's patch @#50 works great, I have been thoroughly testing it and the only bug I have found is with default values. they are not working after a draft is saved. If however you have changed the default value before you save draft there is no problem.

Aaron

Patch at #50 looks like it'll apply against 6.x-2.8 without a problem. Looking forward to it, thanks :)

I see at line 129 of webform_report.inc, it uses the string " draft". I think this should be translatable, and there's a coding standard thing about braces, so this might be better for that snippet:

    $draftstring = '';
    if ($submission->is_draft) {
       $draftstring = t(' (draft)');
    }

Also, there's a comment at line 1820 of webform.module that reads

  // If saving a draft, return redirect to confirmation page (no email processing).

I'm pretty sure from the code that follows it that it actually just displays the "Draft saved" message and doesn't redirect. Would this be a nice place for another option about what to do on saving a draft? Similar to the options for what to do on form submission?

Again, thanks for the patch, I'm about to apply it and if I run in to anything I'll give some more feedback.

Okay, ran in to a problem with the patch from #50 on 6.x-2.8. It looks like the code to override #required fields isn't working? At first I thought the patch was placing the code in the wrong function but now I'm not sure. Any input?

Finally tracked it down to some kind of conflict with the ahah helper module. This could be me using ahah incorrectly or something else specific to my setup since I was unable to figure out what caused the hangup.

Still looking for rollout of this patch for latest 2.8 version as well as fix to emails not being sent out once the save draft version is submitted. I would like to upgrade to the latest secure version but need an upgraded patch.

When the module maintainer moves branches and explains why they're doing it, it's considered bad form to move to a different branch. Please don't do that.

I ported Liam Morland's patch in #50 to the 3.x branch and revised it a bit. I also couldn't get the skipping of validation to work properly, but after learning the #validated flag could be used to skip it I got things working my moving the normal Drupal validation from form.inc into Webform's custom submit handler. The great thing is this also fixes #588354: no validation for prev button.

I also corrected issues with e-mails, though the default values are still busted. I've opened #680960: Default values do not work when resuming from drafts (Component system refresh) to deal with that problem, since I feel it may require significant reworking.

Anyway, I've committed this patch. Thanks to everyone for your efforts and patience!

quicksketch, thank you very much for porting the patch. I wanted to do it, but my project was complete and I couldn't get the time for it. Thanks again.

Hi,
This is my first message to drupal forums.
I want to know if I can apply the #60 patch on the actual 2.9 version of webforms?
Thank you very much!

Hi, was anyone able to apply the patch to the 2.9 webform?

We've tried apply the 6.x-2.9 save_draft.patch on webform 6.x-2.9 version and #60 on the 3.0 beta. Either of them do not seem to apply properly.

Maybe its my knowledge of patch that's wrong given that we're simply putting patch < save_draft.patch in the sites/all/modules/webform directory and the same for #60. Is it just us or someone else have the same problem?

Attached is a small snapshot of us trying the v2.9 patch. Any help would be most appreciated.

You don't need to apply anything to the 3.x version, these patches have been included in the 3.x version for months. I would HIGHLY suggest upgrading to 3.x instead of trying to apply this to 2.9. I can't possibly provide support on patched versions of 2.x.

subscribe

We're running Webform 6.x-3.2. I have the option to save a draft enabled but there is no "Save Draft" button. Any suggestions?

Me too...

I am using Webform 6.x-3.2. I have enabled the option to save a draft but still there is no "Save Draft" button. Any suggestions?

This is an awesome plugin altogether and being able to same drafts is very useful, especially on large forms.

I've installed Drupal 6.19 and Webform 3.4 and when I create a webform I configure "Webform" -> "Form settings" -> "Advanced" -> "Allow users to save a draft", but the form that the user gets has no "Save draft" button :-(

Am I doing something wrong?

I have discovered that "save draft" only appears if you a have a form comprising of more than one page. You can also check it out by introducing a page break in your form.

Hope this works for you.