Op dinsdag 20 juni 2006 18:10, schreef Derek Wright:
On Jun 19, 2006, at 10:58 AM, Fabio Varesano wrote:
Should the munge_filename function became a file api?
it should, yes, but that's complicated. part of the upload_munge_filename() stuff depends on a whitelist of approved file extensions. those are handled as a setting from the upload.module. so, to make munge* a separate function in file.inc that didn't depend on the upload.module, we'd need to put those settings somewhere else, too. since the existing munge stuff was done in the heat of the moment to get 4.7.2 out, no one felt like doing that much additional work to make things generic, moving all this code into the file API, etc...
Same here, Drupals file apis should be more general.
but, it's a pain in the neck for those of us trying to make contribs more secure using this stuff, since now our modules will depend on the upload module, even if they don't the regular upload form element, etc. we should definitely consider reorganizing this code in 4.8. sadly, i'm going to be unavailable for drupal hacking until mid july, so i can't spearhead this effort (at least not until at least the end of july).
I think nearly all of us agree that: * upload.module is a beast that has far too much low level code which should be APIS * file.inc is both limiting as limited in what it can do for you. Limiting: It makes some assumptions that it should not make, but let you (the coder) decide. Limited: it needs a lot of love. Though all of us seem to agree that Something Needs To Be done, none of us really set down to develop it. I never got further then a GRand PLan, a design for how it should work. But as said: never got into actually developing it. In a very very summarised way, betterupload will work like: v --> file hooks modules [file.inc] <--> [upload/insert modules] | ^--> [download/file presentation module] | ^--> [file storage module] v | [file storage] <-----| [file database] Or in words: Any upload or insert module can upload or insert (from anywhere) files. Download, or presentation modules (such as image galleries, or even simpler a "dowload" link with a node) can use apis to present files, without knowing anything about these files. File storage modules offer stuff like "store on remote FTP", or like "dont store the actual file, just store a link, but let Drupal think it has a real file". Or simpler stuff like "store files under files/users/Ber/filename.png. These modules are optional, because file.inc is smart enough to provide a very simple default. File storage and file database are default low level things to make it all work. No ordinary module should have to worry about this when up or downloading. File hooks modules: Any type of module that wants to hook into the lifecycle of a file. Since files are treated as low-level-nodes (please dont start that thread now again!) the same lifcycle is available. Handy to make all your thumbnails greyscale. Or to read the ID3 tags from audio etc. Grand Plan: http://www.webschuur.com/node/246 Bèr