Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Posting this here as it's dependent on a filefield patch...
This adds configurable upload thumbnail sizes (ie 100x100, 300x200, 0 <- don't thumb).
It also gets rid of a little thumbnail logic quirk where only height *or* width are checked. Thus currently if you upload a 5000x50 image it doesn't get thumb'd.
| Comment | File | Size | Author |
|---|---|---|---|
| #14 | filefield_303286.patch | 2.36 KB | drewish |
| #13 | filefield-thumb-sizes-v6.patch | 1.81 KB | Moonshine |
| #11 | filefield-thumb-sizes-v5.patch | 1.77 KB | Moonshine |
| #9 | filefield-thumb-sizes-v4.patch | 1.88 KB | Moonshine |
| #3 | filefield-thumb-sizes-v3.patch | 2.4 KB | Moonshine |
Comments
Comment #1
Moonshine commentedUpdated patch that checks if an image toolkit is active...
Comment #2
drewish commentedif we're going to break the compatibility with the core functions i'd just as soon make the field the first parameter and make sure that we pass it to all the file save functions and hooks consistently.
could you move the imagefield fix into it's own issue?
Comment #3
Moonshine commentedUpdated patch with $field as first parameter. Did not update "all" hooks. Will wait until until we're sure that's the best route.
This patch goes with:
#305621: Imagefield configurable upload thumbnail size
Comment #4
Moonshine commentedUg.. keep forgetting about status.
Comment #5
Nibor-1 commentedWhile the patch does what it says on the tin it breaks node tokens as created with the FileField Paths module.
As a result, using the token [nid] will cause the files to be saved in a directory called [nid] .
If the FileField Paths module is working properly once the node is submitted the directory will be renamed from [nid] (or whatever tokenname you are using) to the correct nodal value (in this case the node id number).
Currently can't actually work out why :(
Nibor
Comment #6
Moonshine commentedHmm... off hand I can't imagine how it would come from this patch. Did you trace it back to it in some way?
There won't be a NID for a new node until the node has been saved, so I think you are just seeing that Filefield Paths doesn't have this token information yet for previews.
Comment #7
Nibor-1 commentedYeah Sorry -
I had previously applied "filefield_295620.patch" as found in Call to undefined function field_file_load() and hadn't realised the functionality had been broken for a while.
Apologies if I wasted your time.
Nibor
Comment #8
dopry commentedI do not want to break the hook_file signature under any circumstance. I like the idea of cleaning up the thumbnail behavior, but hook_file_* is in D7 core and I don't want to break compatibility between D6 and D7 by adding features or variables that will not be supported in D7's implementation.
Comment #9
Moonshine commentedHow about this...
Only $file sent into the hooks, 'thumb_resolution' just rides along in the $file object if it's available. field_file_save_upload() takes in $field, which I'm assuming is "ok", otherwise we don't have enough information to get at the field instance.
Also updated the corresponding patch for Imagefield at:
#305621: Imagefield configurable upload thumbnail size
Comment #10
dopry commentednext pain in the butt nitpick.... can this be done with hook_file on insert if that is set? Type specific processing doesn't belong in file_save_upload.
Comment #11
Moonshine commentedReworked using a file validator... no hooks changed :)
Comment #12
drewish commentedlooking better but rather than just sticking the one setting in there i'd rather keep it generic and stick the field name in there rather than the thumbnail size. then imagefield (or what ever) can implement the file_insert hook and see what field created it.
Comment #13
Moonshine commentedreworked sending field_name and type_name into $file...
Comment #14
drewish commentedhere's more what i was thinking... i'm not sure i want to put the type in because we can determine that from the field name and i'd like to minimize what we stick in there.
Comment #15
Moonshine commentedCan we really get at the type by just knowing the field name though? The field can be in more then one type, and all we'll have available is the field name and the other parts of $file. Not sure if I'm overlooking something...
Comment #16
dopry commentedlets stick type_name in there or pass the entire field through... the extension are instance specific so type name is necessary. I'd say go for moonshines' patch.
Comment #17
drewish commentedmoonshine, you can totally find the type based on the field name... names have to be unique and the can only have one type.
that said i think dopry's right on either doing the name or the whole field.
Comment #18
dopry commentedI committed a variation to HEAD that assigns $file->field to the entire field structure. Why should we have to look it up if we already have it... php5.2 does copy on write so we should have issues with duplicating the structure in memory unless it's modified. at least I think that is true... :)