Closed (won't fix)
Project:
FileField
Version:
6.x-3.7
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Anonymous (not verified)
Created:
29 Nov 2010 at 15:18 UTC
Updated:
19 Jan 2016 at 17:55 UTC
Jump to comment: Most recent
Comments
Comment #1
quicksketchHmm, my preference when saving files programmatically like this is to call the transliterate functions directly before saving the file. As a programmer I expect my files to be renamed unless I ask them to be renamed.
Comment #2
Anonymous (not verified) commentedWhen I made this, I was thinking in consistency. Actually, isn't the better way because if I just used the file API, it would not transliterate the filenames also and would it only if the core were hacked.
I thought FileField would be the better place as other modules could use it to submit files programatically in migration tasks.
Because the way Transliteration works (using
hook_init()to transliterate the filenames), it seems too much to require this consistency from FileField. However, how can I transliterate the$file->filenameif thestdClassobject is created insidefield_file_save_file()? In a migration task, I would need to prepare the files, maybe copying and renaming but for larger and complex migrations, this could be a very time consuming task.A simpler approach would be an extra parameter for the filename. I don't know if extra parameters make your taste but seems more affordable to me than making a change full of side-effects like I did in my patch.
Comment #3
quicksketchI think the simplest approach is simply manually calling transliteration_clean_filename() if you want it to clean the file name before you save the file at all. There's no point in adding a parameter to to FileField when it doesn't do anything but call a function in Transliteration module.