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.
During the update process I encountered the following errors
Notice: Undefined index: module in _field_info_prepare_instance_widget() (line 386 of /modules/field/field.info.inc).
Notice: Undefined index: module in _field_info_prepare_instance_display() (line 354 of /modules/field/field.info.inc).
Updates were attempted. If you see no failures below, you may proceed happily to the administration pages. Otherwise, you may need to update your database manually. All errors have been logged.
Front page
Administration pages
The following updates returned messages
webform module
Update #7318
File components updated to support AJAX uploading.
Update #7319
Webform file entries created in the file_usage table.
I checked one of my forms and tried to upload a file and got the folowing error.
Notice: Undefined index: previous_balance in file_ajax_upload() (line 270 of /modules/file/file.module).
Notice: Undefined index: #suffix in file_ajax_upload() (line 279 of /modules/file/file.module).
Comment | File | Size | Author |
---|---|---|---|
#16 | webform_file_managed_draft.patch | 620 bytes | quicksketch |
Screen Shot | 85.12 KB | chubbell |
Comments
Comment #1
quicksketchThanks for the report. Are you also unable to upload files if you create a new form with a file upload? Or does this only affect existing file fields? If it's the latter, you may try simply editing and resaving your existing file components.
Regarding the errors during the update... I'm not sure how that would occur because Webform does not do anything with the field.info.inc file or call those functions (even indirectly) during the update. The only thing it touches on is the database records, so how these functions are getting called during the update is not clear to me. Did you run other updates at the same time?
Comment #2
chubbell CreditAttribution: chubbell commentedIt did mention several updates a the time however they all seemed to be webform related. I created a new file component in the same webform and it functioned perfectly. It seems the bug is limited to previously existing file components only. I do have the mailchimp for webform module installed I'm not sure that it's related.
Comment #3
quicksketchIf that's the case, does editing the component and saving it again fix the problem? That might indicate our update function that updated the settings for the existing file components may have a bug.
Comment #4
chubbell CreditAttribution: chubbell commentedIt does indeed fix the problem. Thank you.
Comment #5
quicksketchUnless we get more confirming reports of this problem (I can't reproduce it at least), I'm going to mark this fixed. Anyone else who experiences this problem, please reopen and provide any information you can about the configuration of your file components before and after the upgrade.
Comment #6
IronAlan CreditAttribution: IronAlan commentedConform this bug.
It happens when I get page break.
Scenario:
Page 1 - text
Page 2 (conditional) - file upload
error
Undefined index: speech_f в file_ajax_upload() (line 270 /modules/file/file.module).
#suffix в file_ajax_upload() (line 279 /modules/file/file.module).
Some details
Durpal 7.12
Webform 3.17
Page break has rule.
Comment #7
Squawk CreditAttribution: Squawk commentedI don't know if this is related, but I upgraded from 3.15 when I upload files and click save draft, the links to the files are not displayed when I visit the form again...(I think they're not saved) even though the files themselves are saved
Comment #8
TheodorosPloumisI have the same problem when I use AJAX for the webforms.
If I disable AJAX I can upload a file normally with webform...
Comment #9
TheodorosPloumisMaybe the error is with mandatory file component. When I disable this requirement it works.
But it was warking fine before this update.
Comment #10
quicksketchHow are you "using AJAX" on your forms? Are you using a module to enable some kind of AJAX functionality?
I can't confirm a problem when working with file uploads on single or multiple page forms, even if the the file component is marked as mandatory.
Comment #11
TheodorosPloumisYes I use webform_ajax and also tried with webform_ajax_submit. But I had no problems with webform before update.
Comment #12
quicksketchIf you're using Webform AJAX and it works when it's not being used, that module will likely need to address the problem. Webform 3.16 added ajax-based file uploads, which is probably where the problem is being encountered.
Comment #13
David Stosik CreditAttribution: David Stosik commentedOK, so we'll need a lot more information on this bug. It seems like many people are reporting many very different issues here...
Here is what I tested (I am using Webform 3.17 and last dev release of Webform AJAX):
Sounds to me like the "Save Draft" button alone does not save uploaded files, as behaviour is strictly the same, wether Webform AJAX is enabled or not. As Squawk said, files are saved on file system, but not attached to the Webform submission.
If other problems are experienced, please open a new issue and describe it as precisely as possible.
Regards,
David
Comment #14
quicksketchThanks very much @David Stosik for the extensive testing, much appreciated.
Comment #15
quicksketchI've been able to reproduce this problem. In addition to David's testing, I also observed that the file appears to upload/save properly when you click the "Save Draft" button (with or without clicking "Upload" first), but if you leave the page and come back the for file upload is lost.
Comment #16
quicksketchLooks like the problem is merely the file components lack of properly saving values. When using the "Save Draft" button, certain validate handlers are skipped, but the _webform_submit_[component]() hook is still called. We can use this hook to make sure that the proper File ID is saved. This patch corrects the file upload handling in my testing, though confirmation would be appreciated.
Comment #17
quicksketchActually considering this patch is unlikely to have any negative impact (if $value is already the FID, there's no change from the current behavior). I've committed this patch to the 7.x-3.x branch. Please try out the latest dev version after the tarball is rolled tonight or use a git checkout to test these changes.
Comment #18.0
(not verified) CreditAttribution: commentedremoved internal hosting paths