I have 10 file fields, all mandatory. When a user try to send the form without compiling all the 10 fields, all the fields values are resetted :-(, there is any way to avoid this behavior and to left the fields filled with the data the user did put inside?

Moreover, it's a possible feature to add an ajax upload system for the webform file fields?

thanks for the attention.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

quicksketch’s picture

Title: File submission » Provide AJAX-based file uploads

HTML does not allow you to set default values for file fields, so it is impossible to handle after a page load. The only solution would be to provide JavaScript validation to prevent the user from trying to go to the next page at all. Or, as you suggest, use and AJAX loading system. I'm updating this title to just be ajax uploading of files.

quicksketch’s picture

Version: 5.x-2.1.2 »

I wrote an AJAX-upload widget for Drupal 7, which I don't have any plan to backport. But at least we'll have a nice solution for the 3.x version in Drupal 7.

d.sibaud’s picture

good to know, thanks for sharing :-)

derjochenmeyer’s picture

Version: » 6.x-3.x-dev

Maybe the esiest way to make AJAX Uploads possible in Webform for D6 is to use Upload element Module.

From the README.txt of Upload element Module:

Usage
-----
The base usage can be as simple as:

## To add the element to the form
  $form['image'] = array(
    '#type' => 'image_upload_element',
    '#title' => t('Image'),
    '#default_value' => $node->image, // {files} object
  );

## And to handle the submission

  // in hook_insert or somewhere
  // $node->image is a {files} object
  // If you handle this yourself, make sure that you check
  // the property submit_action to see if the object has
  // been flagged as deleted.
  $image_id = 0;
  if($node->image) {
    $image_id = upload_element_save($node->image, 'dest/directory', FILE_EXISTS_RENAME, 'imagecache_preset');
  }

Part 1 is easy

/**
 * Implementation of hook_form_FORM_ID_alter().
 */
function YOUR_MODULE_NAME_form_webform_client_form_NID_alter(&$form, &$form_state) {
  if (module_exists('upload_element')) {
    $form['submitted']['image']['image']['#type'] = 'image_upload_element';
  }
}

But where should the file saving be handled? Which function could be a good place to implement this?

yanceyworks’s picture

Title: Provide AJAX-based file uploads » Provide AJAX-based file uploads\Progress Bar for uploads
Version: 6.x-3.x-dev » 7.x-3.x-dev

A gentle nudge to see if this is any closer to availability now with the D7 version of Webform.

It is an important feature for the larger files I need to handle.

Thanks!
Rich

ajaysolutions’s picture

From an implementer (not programmer) perspective, I'm also looking for a way to perform AJAX file uploads for Webforms in Drupal 7. Is there currently a way to do this, has anybody discovered?

EDIT: Having discussed this at length offline, I realised that AJAX file uploads only make sense for multiple files. Single file uploads don't need an AJAX file upload, but what would be very useful for usability are two things (which could be combined):

1. The option to disable the Submit button once a Webform is submitted.
2. The option to display a progress bar when the Webform has a file upload field.

These could be combined to replace the Submit button on a Webform with a progress bar. But I digress. These would be nice options though!

jamix’s picture

As per quicksketch's request, I'm reposting here my small module that adds a JavaScript progress bar to Webform forms that contain file components. Hopefully it will be useful to someone. More details here.

niels.sterckx@gmail.com’s picture

Is it possible to change the color of the upload progress bar?

quicksketch’s picture

@sterckx: As I noted in #1162654: Progress bar for Webform file uploads, Webform module does not have a progress bar for uploads *at all* currently. You're asking your question in the wrong place. In any case, you use CSS in your theme, just like you'd use to change the color of anything.

Nico Heulsen’s picture

I created a (raw) module "webform_managed_file" which creates a new webform component (based on the existing file component). I didn't follow the basic structure to move the component-code in a directory "components", because of "undefined validation functions" (1). I got this works (with progressbar - after applying patch #70 of #935208: PECL uploadprogress bar doesn't appear.), but only for the default drupal extensions.
When I include for example mp4, the file isn't uploaded. After some debugging I found that for some reason the file_save_upload is called twice. The first time the extensions array is empty (so it falls back on the drupal default extensions, mp4 isn't included, so there is an error thrown. Second time, the validation is handled correctly but the form has an error so it displays this error (2). I don't know which submit/validation handler calls the file_save_upload the first time. Even when I remove all validation handlers of my element, the function (file_save_upload) is called.
At this point it is a seperate module (because of the dependency and not following the default webform component structure), but I think (when fixed), it should be a part of the webform module.

Nico Heulsen’s picture

Sorry, forgot the module

mstef’s picture

@jamix: I tried your module. The file doesn't attempt to begin downloading until the submit button is pressed. By then, it's too late and the page reloads, and we're back at the same problem, with it missing after the failed validation. Is that happening for you? It would be nice if the upload started right away, and the submit button was disabled until it was done. Think that's possible?

jamix’s picture

mikestefff, that's right, the upload starts when the submit button is pressed. On my end, however, the page doesn't get refreshed until the upload finishes and there are no validation errors.

mstef’s picture

Well, the main problem I'm having, is that if the form doesn't validate, for whatever reason, the page is reloaded and the file is no longer uploaded and attached to the form. That's what I was hoping this module would solve.

Bcwald’s picture

Following the steps in #11 I was successfully able to get the progress bar working, however, there is one issue.

when the form is submitted, it does not move the file from my /tmp directory to site/default/files directory. I have identified the function that moves the file to be PERMANENT and it matches the file.inc inside the normal webform module. I am not sure what this is happening?

Has anyone else experienced this?

quicksketch’s picture

Status: Active » Needs work

Thanks @Nico Heulsen for the module! I'd love to see this as a total replacement for the existing file.inc (as a patch) for the Webform core module.

Wolfgang Reszel’s picture

Subscribe

quicksketch’s picture

Title: Provide AJAX-based file uploads\Progress Bar for uploads » Provide AJAX-based file uploads/Progress Bar for uploads
Status: Needs work » Needs review
FileSize
27 KB

I've written this patch targeted at providing this feature directly in Webform module. Testers would be highly appreciated. This patch seems to make more changes than needed, but trust me, the whole thing is needed for this functionality. Changes it makes:

- Adds support for the #type = 'managed_file' file upload element (which includes the code for AJAX-uploading and progress bars). Completely replacing the old file component.
- Because #type = 'managed_file' can upload anywhere this patch also provides support for *private* file uploads on a *per field* basis. So you can lock down any individual file component for privacy if needed without changing the site-wide setting.
- Makes Webform start properly using the 'file_usage' database table (which is required to for the managed_file element).
- Provides an upgrade hook to migrate all the existing 'file' components.
- Provides a second upgrade hook to add all entries for existing files into the file_usage table.
- Rewrites hook_file_download() to use the new, faster database table for granting access to files.

This patch adds awesome functionality and also fixes a bunch of other problems, I'd like to add it as soon as I get confirmation that it works well.

As with any patch that runs update hooks, please test this on a backup of your site.

quicksketch’s picture

FileSize
26.95 KB

Well even after all this work I hadn't even enabled the progress bar! This patch provides option for enabling the progress bar instead of the throbber. Note that you must have APC or uploadprogress PECL extension enabled. There's more information available on your Drupal install under the status report (admin/reports/status) which you can use to confirm upload progress is available. The option to use a progress bar is only shown if your server supports it.

Additionally, upload progress only works in Drupal 7.10 or higher, thanks to this long-standing bug: #935208: PECL uploadprogress bar doesn't appear.

quicksketch’s picture

FileSize
27.46 KB

This version is same as the last one only it uses a db_merge() instead of file_usage_add(). It may seem counter-intuitive to use a direct SQL query when an API function exists, but this change will make the update "double-run" proof.

trentl’s picture

quicksketch - First, thanks for this patch.

I installed the patch provided in #20 and received the following error when I went to check "reports > status" or if I select "configuration"

Re-ran the patch and re-installed, updated database, and all seems fine now. Not sure where the glitch occurred. Will post if I find any issues. Thanks again for the work on this!

quicksketch’s picture

FileSize
27.43 KB

I found some pretty grievous errors in the update hook I'd included in #20.

If you've installed this patch and run update.php, I *highly* suggest restoring a database backup. The mistakes aren't catastrophic, but the patch in #20 didn't actually update existing file components correctly, which means that all of the file components would need to be edited manually and resaved.

This bit of code is the obvious mistake:

+function webform_update_7317() {
+  $result = db_select('webform_component', 'wc', array('fetch' => PDO::FETCH_ASSOC))
+    ->fields('wc')
+    ->condition('type', 'date')
+    ->execute();

The code condition('type', 'date') obviously isn't going to update "file" components. :P

This patch fixes the update hooks and also updates the numbers so that it doesn't conflict with the performance patch that was committed in #1352572: Add (or use existing) indexes for the Webform results page.

quicksketch’s picture

Status: Needs review » Fixed

Now that I've had adequate time to review everything, I think this patch is good to go. I've committed #22 to the 7.x-3.x branch. This patch is a huge improvement to our file handling and keeps Webform up-to-date with all the file handling in Drupal 7. Considering everything is dependent upon the "managed_file" element introduced in Drupal 7, we won't be seeing a back port to Drupal 6.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Augusto182’s picture

Thanks for the patch...

1) What webform vesion is used?
2) I need aditional modules to run this aplication?

:)

Augusto182’s picture

Viewing your patch i see:

@@ -55,8 +52,11 @@ function _webform_theme_file() {
  * Implements _webform_edit_component().
  */
 function _webform_edit_file($component) {
+  dsm($component);
     $form = array();
     $form['#theme'] = 'webfor

dsm function is no defined in drupal 7...

:3

Augusto182’s picture

dsm() <=> drupal_set_message() ?

?????????????????????????????????

Augusto182’s picture

I set drupal_set message for dsm... but seems like a debug message...

In the other hand... i cant validate mi form because "my file exceeds 800 bytes" !!!

I set the max upload size to 2 MB, without result

:(

Augusto182’s picture

:(

I get this ajax error:

Fatal error:  Call to undefined function webform_expand_select_ids() in /home/siieecom/public_html/Proyectos/HappyBox/includes/form.inc on line 1764
ReadyState: undefined

:(

Augusto182’s picture

FUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU

Augusto182’s picture

Status: Closed (fixed) » Active
quicksketch’s picture

dsm function is no defined in drupal 7...

Yes sorry that was a bit of debugging code. dsm() is from the devel.module. It's intended to make it easy to inspect a variable, sort of like a super-print_r() function.

I'd suggest downloading the dev version of Webform rather than trying to apply the patch. This isn't yet in a final release of Webform (it'll be in 3.16).

cmoad’s picture

Is there any possible way to estimate when 3.16 will be out or request that it be cut as soon as possible? This feature is critical for a site we are deploying and we would like to avoid using a dev version of the module.

Thanks.

quicksketch’s picture

Status: Active » Fixed

Is there any possible way to estimate when 3.16 will be out or request that it be cut as soon as possible?

Before making the 3.16 release, I intend to include the feature request for translation: #245424: Make Webform multilingual (i18n) aware through contributed modules

And I need to make a pass through the whole issue queue for any bugs that have patches that need reviewing.

stano.lacko’s picture

Title: Provide AJAX-based file uploads/Progress Bar for uploads » When will be patch #18 inserted into production version of Webform - broken private file download from node
Version: 7.x-3.x-dev » 7.x-3.9

I'm unable to download file stored in node as private file, because
webform module function webform_file_download() produce in PostgreSQL error for cast error, where is compated f.fid with wsd.data where f.fid is integer and wsd.data is text type.
Problem is, that webform module make this error, and this file (stored as field_file) have nothing to do with webform, so it's webform problem.

When cache condition to f.fid::text = wsd.data, everything is working as on MySQL. ProgreSQL is more strict, so please make something, I don't want to patch every next versions of Webform module.

vernond’s picture

Title: When will be patch #18 inserted into production version of Webform - broken private file download from node » Provide AJAX-based file uploads/Progress Bar for uploads
Version: 7.x-3.9 » 7.x-3.x-dev

@stano.lacko : please do not change issue titles, it makes it difficult to find the real issue again.

As mentioned in #23, you can get a version with this change implemented at http://drupal.org/node/730862. See #34 regarding next release version.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

attiks’s picture

FYI: I just discovered this breaks webform multi file, see #1525580: Breaks webform file upload component

geneescober’s picture

Version: 7.x-3.x-dev » 7.x-3.19

Hi, my Drupal hosting provider does not allow PECL uploadprogress to be installed, but according to the post from December 9, 2011, APC (Alternative PHP Cache) can be used as well? Can someone please confirm and provide supported versions? Thanks!

Well even after all this work I hadn't even enabled the progress bar! This patch provides option for enabling the progress bar instead of the throbber. Note that you must have APC or uploadprogress PECL extension enabled. There's more information available on your Drupal install under the status report (admin/reports/status) which you can use to confirm upload progress is available. The option to use a progress bar is only shown if your server supports it.