This patch goes with the issue at:

#303286: Filefield configurable upload thumbnail size

CommentFileSizeAuthor
#15 imagefield-thumb-sizes-v6-and-widget-fix.patch5.86 KBMoonshine
#14 imagefield-thumb-sizes-v5-and-widget-fix.patch5.59 KBMoonshine
#2 imagefield-thumb-sizes-v4-and-widget-fix.patch5.56 KBMoonshine
#1 imagefield-thumb-sizes-v4.patch2.75 KBMoonshine
imagefield-thumb-sizes-v3.patch2.93 KBMoonshine

Comments

Moonshine’s picture

Moonshine commented
StatusFileSize
new imagefield-thumb-sizes-v4.patch2.75 KB

Updated version...

Moonshine’s picture

Moonshine commented
StatusFileSize
new imagefield-thumb-sizes-v4-and-widget-fix.patch5.56 KB

Ok, well this is a little mean, but I'm rolling a fix into this patch for the bootstrap.inc utf8 errors that happen when adding a new Imagefields via the latest CCK dev. I think they must have made some small widget changes.

Anyways, if you commit the patch, then be sure to add the last one at :

#303286: Filefield configurable upload thumbnail size

And then we'll have thumb sizing also!

I'm done baiting... :)

attiks’s picture

attiks commented

I have a related question, isn't it better to add support for imagecache to create the thumbnails, would be a lot cleaner?

Peter

Moonshine’s picture

Moonshine commented

As an Imagcache user, I would tend to agree. :) However, I approached dopry about that a few months ago he didn't want to go that route. I think he just wanted to make thumbs were available for everyone without adding Imagecache/Imageapi as a requirement on top of Imagefield/Filefield.

It could certainly be worked in as an "additional" option at some point, but would think this patch has a better chance of getting in first.

attiks’s picture

attiks commented

OK, but one final remark, is it possible to put the thumbnails in a separate directory, otherwise it's confusing if you use the files in IMCE for example? Can't be that hard to do?

Moonshine’s picture

Moonshine commented

I think it's done this way so that Imagefield can easily "count" on a unique filename for the thumb my just using the image filename (that has been verified/modified to be unique in the directory already) and attaching the thumbnail extension (.thumb.jpg) on it.

If all thumbs were stored in something like a central "thumbs" directory then the filenames would need to be checked for uniqueness on each thumb, and stored as data with the imagefield in case it had to be modified.

They could be stored in something like a thumbs subdirectory of the directory containing the originals, with some small modifications to the code. However that would also involve an "update" in the module to move all the thumbs people currently have into newly created subdirs, which may not be very exciting for the maintainers.

I haven't tried IMCE but it seems odd that it isn't limiting things to what's in the {files} table. But either way, I *think the easiest route would be for IMCE would just be to change its file matching pattern to exclude '*.jpg.thumb.jpg', '*.jpeg.thumb.jpg', '*.gif.thumb.jpg', '*.png.thumb.jpg'. Just a thought..

attiks’s picture

attiks commented

The idea was a thumbs subdirectory as a child, not a central one, but you're right updating can be complicated.

I'll check at the IMCE for exclusion patterns.

Thanks
Peter

zach harkey’s picture

zach harkey commented

Really depressed about this new 'thumb.jpg' in the same directory decision. It's like the Image module all over again. Uggh, such a step back.

Moonshine’s picture

Moonshine commented

Well, I think most people would disagree that the addition of upload thumbnails being a step backward :) Is this just IMCE picking them up? Seems to me like that may just be a matter of a one line filter added in the right place.

zach harkey’s picture

zach harkey commented

No thanks to any feature that doubles the number of images in my directory. IMCE is just one of many file browsers that this makes a mess of.

In my studio we actually mount our remote drives with a MacFUSE-based system that allows us to use Adobe Bridge, Lightroom, IView Media Pro and even Aperture to browse these files. Sure we can make a bunch of rules and filters to get around the mess but we shouldn't have to.

It also makes it a pain to rsync and backup these important directories, again, I realize we can make a bunch of exception flags, but this is just the kind of speed bump that makes these things painful.

The beautiful thing about imagecache is that it keeps all the expendable, reproduceable derivative files in a separate directory tree, with each derivative preset in its own directory, making it trivial include/exclude non-original files.

If all thumbs were stored in something like a central "thumbs" directory then the filenames would need to be checked for uniqueness on each thumb, and stored as data with the imagefield in case it had to be modified.

This is exactly the kind of stuff that imagecache cleanly mitigates. It stores no data and makes no assumptions. Very clean.

They could be stored in something like a thumbs subdirectory of the directory containing the originals, with some small modifications to the code. However that would also involve an "update" in the module to move all the thumbs people currently have into newly created subdirs, which may not be very exciting for the maintainers.

Speaking of update excitement, we should also consider the fact that the new 'thumb.jpg' feature provides no upgrade path from Imagefield 5.x (yet). In these cases, there is no existing .thumb.jpg so the path breaks and the admin form has no thumbnail at all. A quick survey of the issue queue suggests that this breaking of backward compatibility is already unnecessarily blocking many users attempts to upgrade to Drupal 6.

I can appreciate not wanting to add the imagecache dependency, but, as I stated in a previous thread

Imagecache provides such an elegant way around this kind of mess. We should use Imagecache to create these thumbnails or not do it all.

- If you don't have Imagecache installed, your thumbnail is simply the original file, optically scaled to look like a thumbnail. This should be perfectly acceptable for the kind of beginner level user who doesn't have Imagecache installed.

- If you do have Imagecache installed, you can specify a derivative to use in the field settings form. Or Imagefield could just automatically generate a derivative for this use.

This would also mitigate the problem of all the missing ".thumb.jpg"-style thumbnails after attempting to upgrade from Imagefield 5.x. As it stands now, these image paths are completely broken in the admin form.

Moonshine’s picture

Moonshine commented

I can feel some of your pain. :) However, as I mentioned above, I already tried to convince Dopry to go the Imagecache route, but (at least at that time -- this spring) it wasn't an "acceptable" route. Your suggestion:

- If you don't have Imagecache installed, your thumbnail is simply the original file, optically scaled to look like a thumbnail. This should be perfectly acceptable for the kind of beginner level user who doesn't have Imagecache installed.

Is what D5 Imagefield does, and unfortunately is *exactly what he wanted to "fix" without adding requirements as I recall.

In any event, you're preaching to the choir here with regards to imagecache thumbs. :) I actually used my own homebrew version of Imagefield/Imagecache/Inline in D5 for that reason, as I could never push all the necessary patches though the projects. For example, Imagecache needed a modification to work with temporary/preview images, as as new uploads aren't in place yet until the node is saved:

#146861: Issue with "previews" and imachecache content

but I lost interest waiting on prerequisite patches like that, so my d5 imagecache thumb patch never even saw the light of day. If dopry/drewish are ready to go that route now, I'd be more then happy to help. But seeing that this small patch for size options hasn't gone far, I doubt thumbs are a priority.

As for d5 upgraders, that should be pretty simple to patch/fix if someone cared enough... :/

Roulion’s picture

Roulion commented

just a question before trying the patch. Is therea croping functionnality or, if you entre a 100x100 size, the picture is rezied to that without respecting the proportion?

Moonshine’s picture

Moonshine commented

There is no crop functionality for this patch. However this is just concerning the thumbnails used on the node add and edit forms. If you are looking for general thumbnail creation for display then you're looking for the Imagecache module. (Which does offer cropping options)

Moonshine’s picture

Moonshine commented
StatusFileSize
new imagefield-thumb-sizes-v5-and-widget-fix.patch5.59 KB

re-roll against latest HEAD to go with the filefield patch.

Moonshine’s picture

Moonshine commented
StatusFileSize
new imagefield-thumb-sizes-v6-and-widget-fix.patch5.86 KB

re-rolled for new filefield patch that sends field_name and type_name into the $file.

quicksketch’s picture

quicksketch
he/him
commented
Status: Needs review » Needs work

I'd be fine with making this a configurable option. I'm also not real pleased with the creation of *.thumb.jpg files, I'd prefer we stuck them all in a single directory similar to ImageCache and maintained the original file hierarchy. But regardless, that's not really the focus of this issue.

This patch has a problem where it won't update images to the new thumbnail size if the size is changed after several images have already been uploaded. Perhaps we could add a check on the existing thumbnail when a node is being edited to check that the thumbnail is the right size (and exists at all).

attiks’s picture

attiks commented

I created a patch against the latest beta that allows you to use imagecache for the thumbnail previews, see #402014: Use imagecache for thumbnails

quicksketch’s picture

quicksketch
he/him
commented
Status: Needs work » Fixed

This is *sort of* fixed with #307503: Move *.thumb.jpg files to a separate directory. There is now a "hidden" variable for "imagefield_thumb_size" which defaults to 100x100. You can change this with the devel variable editor or hand-coding it in settings.php. I only left it as a variable so that I wouldn't have to clutter the UI and because there wasn't a very good place to put a global setting like this for ImageField.

Instead I'd like to focus on attiks's patch in #402014: Use imagecache for thumbnails and make ImageCache presets an option for thumbnails instead. That setting will actually be exposed to administrators, so they'll be able to configure the thumbnail size that way.

Moonshine’s picture

Moonshine commented

Hey, sorry for the lag here... I'm just completely buried finishing up a project here. :/ Filefield/Imagefield have changed quite a bit since I was working with them last, and I have some heavy customization in this currently project, so it will take me a little bit to get my head around changes and be working w/ the latest code. My bad, but it had to be done at the time ;) I will catch up here once things are live and I have some time. Thanks for the addition though, I'll be sure to check it out!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

ari-meetai’s picture

ari-meetai commented

I agree making ImageCache handling the thumbnails for ImageField would be the best solution here. Mostly because both are making their way into D7.

Cheers.