Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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.
Comment | File | Size | Author |
---|---|---|---|
#22 | webform_ajax_file2.patch | 27.43 KB | quicksketch |
#20 | webform_managed_file.patch | 27.46 KB | quicksketch |
#19 | webform_managed_file.patch | 26.95 KB | quicksketch |
#18 | webform_managed_file.patch | 27 KB | quicksketch |
#11 | webform_managed_file.tar_.gz | 5.66 KB | Nico Heulsen |
Comments
Comment #1
quicksketchHTML 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.
Comment #2
quicksketchI 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.
Comment #3
d.sibaud CreditAttribution: d.sibaud commentedgood to know, thanks for sharing :-)
Comment #4
derjochenmeyer CreditAttribution: derjochenmeyer commentedMaybe 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:
Part 1 is easy
But where should the file saving be handled? Which function could be a good place to implement this?
Comment #5
yanceyworks CreditAttribution: yanceyworks commentedA 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
Comment #6
ajaysolutions CreditAttribution: ajaysolutions commentedFrom 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!
Comment #7
jamix CreditAttribution: jamix commentedAs 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.
Comment #8
niels.sterckx@gmail.com CreditAttribution: niels.sterckx@gmail.com commentedIs it possible to change the color of the upload progress bar?
Comment #9
quicksketch@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.
Comment #10
Nico Heulsen CreditAttribution: Nico Heulsen commentedI 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.
Comment #11
Nico Heulsen CreditAttribution: Nico Heulsen commentedSorry, forgot the module
Comment #12
mstef CreditAttribution: mstef commented@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?
Comment #13
jamix CreditAttribution: jamix commentedmikestefff, 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.
Comment #14
mstef CreditAttribution: mstef commentedWell, 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.
Comment #15
Bcwald CreditAttribution: Bcwald commentedFollowing 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?
Comment #16
quicksketchThanks @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.
Comment #17
Wolfgang Reszel CreditAttribution: Wolfgang Reszel commentedSubscribe
Comment #18
quicksketchI'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.
Comment #19
quicksketchWell 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.
Comment #20
quicksketchThis 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.
Comment #21
trentl CreditAttribution: trentl commentedquicksketch - 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!
Comment #22
quicksketchI 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:
The code
condition('type', 'date')
obviously isn't going to update "file" components. :PThis 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.
Comment #23
quicksketchNow 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.
Comment #25
Augusto182 CreditAttribution: Augusto182 commentedThanks for the patch...
1) What webform vesion is used?
2) I need aditional modules to run this aplication?
:)
Comment #26
Augusto182 CreditAttribution: Augusto182 commentedViewing your patch i see:
dsm function is no defined in drupal 7...
:3
Comment #27
Augusto182 CreditAttribution: Augusto182 commenteddsm() <=> drupal_set_message() ?
?????????????????????????????????
Comment #28
Augusto182 CreditAttribution: Augusto182 commentedI 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
:(
Comment #29
Augusto182 CreditAttribution: Augusto182 commented:(
I get this ajax error:
:(
Comment #30
Augusto182 CreditAttribution: Augusto182 commentedFUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU
Comment #31
Augusto182 CreditAttribution: Augusto182 commentedComment #32
quicksketchYes 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).
Comment #33
cmoad CreditAttribution: cmoad commentedIs 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.
Comment #34
quicksketchBefore 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.
Comment #35
stano.lacko CreditAttribution: stano.lacko commentedI'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.
Comment #36
vernond CreditAttribution: vernond commented@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.
Comment #38
attiks CreditAttribution: attiks commentedFYI: I just discovered this breaks webform multi file, see #1525580: Breaks webform file upload component
Comment #39
geneescober CreditAttribution: geneescober commentedHi, 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!