Since the Drupal 7.29 security update:
- The user selects an image file with the "choose file" button in the upload tab.
- The user clicks the "upload" button. The image file uploads as expected.
- The user clicks the "next" button and receives an error: "Upload a new file field is required". The selected file has been removed from the field.
This error occurs for any image field with media widget. It does not occur if the default image widget is used.
If the user chooses the image file then clicks "next" without uploading, the error is bypassed and the image uploads normally.
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | file_entity-remove-field-status-check-2308737-9.patch | 962 bytes | jday |
| #5 | file_entity-remove-field-status-check-2308737-9509141.patch | 961 bytes | topicus |
Comments
Comment #1
johnpitcairn commentedThis is being addressed in #2305017: Regression: Files or images attached to certain core and non-core entities are lost when the entity is edited and saved
Comment #2
coredumperror commentedThe patch that appears to be the accepted one for that issue does not resolve this bug. I'm going to see if I can find out what's really wrong.
Fortunately, I've found two workarounds (or of which is really ugly):
1) Give users the "Bypass file access control" permission from File Entity. This is ugly.
2) Train users not to click the Upload button. If you select a file and immediately click Next, the upload works fine. Clicking Upload before clicking next gives the "Upload a new file field is required" error.
Comment #3
coredumperror commentedI delved through the file entity code, and I found something curious: Why is
$file->status == FILE_STATUS_PERMANENTchecked in the last few lines offile_entity_access()? Taking out that check fixes this bug, but I have no idea why that check is there, so that may be a bad idea.Ultimately, though, you're right that this is actually being caused, at least in my case, by a deficiency in the core File module. My site uses S3 File System, so the uri schemas for my files are s3:// instead of public://. The File module assumes that files without a public:// schema need to be checked for download permission, which leads to
file_entity_access()being called unnecessarily on the temporary file that's been uploaded as part of the media upload workflow. Since it's a temporary file, thatFILE_STATUS_PERMANENTcheck mentioned above causesfile_entity_access()to return FALSE, and thus the file is tossed on the ground, which triggers this error message.I'm going to update s3fs to have it register itself in that new
file_public_schemavariable that the patch from #2305017: Regression: Files or images attached to certain core and non-core entities are lost when the entity is edited and saved added. But since that patch isn't official yet, that won't work for everyone.Comment #4
steinmb commentedLooks fishy, I suggest we move this to file entity though it should have a better title.
Comment #5
topicus commentedI ran into the same issues working with file entity and remote files. I'm submitting a path to remove the FILE_STATUS_PERMANENT check.
Comment #6
steinmb commentedComment #8
justaman commentedWe are having the same issue. I would love to contribute.
What is the status of this issue?
Comment #9
jday commentedUpdating the patch
Comment #10
steinmb commentedComment #11
lhumphrey commentedHas this been fixed yet? I tried the attached patch but it doesn't seem to work. Thanks!
Comment #12
joseph.olstadthis was caused by a core regression that is fixed in recent versions of D7 core. (newer than 7.30) , if you experience this issue, please upgrade your core to 7.54 or higher / newer.