The thickbox module works on the assumption that all image derivative files exist.
However, the image module refuses to create derivative files if the original image is already smaller than the derivative size. No doubt this was done for reasons of space efficiency.
The attached patch compromises by creating the derivatives as hardlinks if they don't need to be resized. Hardlinked files don't take up any extra file space. For Windows installs where the link() function is unavailable, it falls back to a simple copy.
As a bonus, the resultant code is slightly smaller and simpler, and the image_get_derivative_sizes() function is no longer needed.
Comments
Comment #1
drewish commentedi guess you weren't following the queue when i tried to have it just copy files. people went nuts. and in the end i think they're right. you only create derivative images when you need them. if symlinks were cross platform i'd be into that approach but since it'd fallback to a copy it's a no go.
i'd like to get image.module with thickbox but this isn't the way to do it.
Comment #2
pillarsdotnet commentedSorry; I was following http://drupal.org/node/125610 where you said that it had been fixed.
In that issue, you hadn't retracted your claim.
I'm going to try and patch thickbox so that if the image it's looking for doesn't exist, it falls back to the original on its own. I don't think it's possible or practical to have it do a database lookup from the javascript.
(looking...)
Thickbox sets the size of the preview image once at the top of the page.. Could override on a per-image basis, but how? If there was a clue in the link attributes, that would be sufficient. But that would mean modifying or overriding the theme_image_teaser() function.
How about setting a class on the link if and only if the preview is the same size as the original?
Here's the least-invasive patch I'd need:
Associated patch for thickbox:
And for acidfree:
Tested and working here: http://www.kbsystem.com/albums/products/woods
Comment #3
jennycita commentedI think this is the root of the problem. It should be using the excellent
image_fetchfunction instead. It allows you to access any form of the image you want like so:image/view/$nid/$derivative-- and also handles substituting the original image for any derivatives that don't exist.Here's a patch that's working for me. There are a few things that could probably be done better (it'd be nice if thickbox didn't require an extension to recognize an image, for instance), but I've spent enough time on it. In order to support pathauto, an image.module patch is also necessary.
Comment #4
Renzy commentedWhat is the outcome from this thread.
There appears to be two solutions/patches presented. Can some clarification be given as to the best way to go here?
I am having the same issues, where the thickbox is working with image module, as long as the derivative images are being re-built.
TIA,
Renaee.
Comment #5
sunIf Thickbox wants to display a certain image, it has to make sure that the image actually exists.