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.
Problem/Motivation
file_validate_extensions() incorrectly assumes that $file->filename is always the name of the file stored on the web server. This is not always the case. For example, the Media module allows users to change $file->filename, which has no affect on the actual file stored on the web server.
Example
- User uploads syllabus.pdf with Media module. $file->filename is "syllabus.pdf". The file name on the web server is "syllabus.pdf".
- User renames the file entity from "syllabus.pdf" to "2016 Fall Syllabus". $file->filename is "2016 Fall Syllabus". The file name on the web server is "syllabus.pdf".
- User references the file entity using a file field and FileField Sources. When file_validate_extensions() evaluates the $file object, the file will fail because $file->filename is incorrectly assumed to contain the file's extension.
Proposed resolution
For managed files, get the filename from the URI, which contains the actual file name from the web server.
For unmanaged files, the functionality is unchanged. (It's possible contrib modules could call this function to evaluate an unmanaged file.)
Remaining tasks
Create patch and maintainer review.
User interface changes
None
API changes
None
Data model changes
None
Comment | File | Size | Author |
---|---|---|---|
#26 | core-file_validate_extensions-2834958-26--complete.patch | 4.67 KB | huzooka |
#26 | core-file_validate_extensions-2834958-26--test-only.patch | 3.59 KB | huzooka |
Comments
Comment #2
Chris Burge CreditAttribution: Chris Burge commentedAttached is a patch for D7. I'm currently working on a D7 project but would be happy to write a patch for D8 if this issue gets some attention.
Comment #9
huzookaComment #10
huzookaComment #11
huzookaPatch in #2 is outdated and cannot be applied anymore.
Comment #12
huzookaComment #13
huzookaComment #15
huzookaComment #17
xjmThanks!
This would need to be fixed in D8 as well. D8 and D9 probably require separate patches. We should file the issue against the lowest branch that will receive the fix (which is 8.8.x for now and 8.9.x after next week) and just be sure to queue each patch's tests against the correct branch.
Comment #18
Wim LeersRebased #15.
Comment #20
alfaguru CreditAttribution: alfaguru at Figure W Limited commentedReroll of #18 for 8.8.
Comment #21
alison#18 actually applies smoothly for me on 8.9.x. Also, I think the directories/paths in #20 are one level off?
Anyway, at this point (with dropping support for 8.8 anyway, IIRC?), I think #20 could be hidden, and we can go with #18?
-------
MEANWHILE: #18 tested on 8.9.16 -- success!
In my case, I was able to save my media entity "edit" form, making a test change to the media "name" field, and the form let me save just fine. AND, it still blocked me from putting a JPG file on this media entity that only allows pdf/doc/docx/txt/xls/xlsx/etc. file extensions.
I'll leave it "Needs review" in case y'all want to wait for someone else to review, too, but meanwhile, "yay" and thank you all!
Comment #22
LendudeNeeded a reroll for 9.x, this won't go into 8.9.x anymore
Cleaned up the test a bit to match 9.x. Also gave its own method so we don't change any existing tests.
Comment #23
idebr CreditAttribution: idebr at iO commentedPatch work as expected, and includes test coverage so setting to RTBC. Thanks!
Comment #24
huzookaMany-many thanks for pushing this forwards!
Comment #25
huzookaThen we should use dataprovider (imho).
Comment #26
huzookaAddressed #25, the new test method now uses data provider.
Comment #27
huzookaComment #29
idebr CreditAttribution: idebr at iO commentedPatch work as expected, and includes different test coverage so setting to RTBC. Thanks!
Comment #31
larowlanFixed on commit
Committed b27e6a8 and pushed to 9.3.x. Thanks!
As there is little risk of disruption here, backported to 9.2.x