I just noticed that derivatives (= preview and thumbnail) are deleted + regenerated on every node (or gallery) view, even if they're already found in the current default image path.
That is, recently viewed images are always on top of a "sort by date", in that particular folder.

Dunno if that's a different issue from derivatives being generated into the current default image path if they're not found there yet.

They shouldn't be generated at all if they're
1) found in the files.filepath path, and
2) the image.module settings haven't changed
or, alternatively,
2) the files on disk are the same size as listed in mysql under files.filesize.

Thanks!

CommentFileSizeAuthor
#1 image-galleries-bug.jpg62.95 KBHetta

Comments

Hetta’s picture

Hetta commented
Version: 5.x-1.2 » 5.x-1.x-dev
StatusFileSize
new image-galleries-bug.jpg62.95 KB

A very dirty fix:

in image.module, comment out this bit (lines 391-397):

  // special images
  if (empty($node->images['thumbnail'])) {
    $node->images['thumbnail'] = $node->images[IMAGE_ORIGINAL];
  }
  if (empty($node->images['preview'])) {
    $node->images['preview'] = $node->images[IMAGE_ORIGINAL];
  }

This will fix
1) regeneration of derivatives on every view
and
2) regeneration of derivatives into the current default image path on every view.
That is, with this commented out you can have folders in files/images/.

However, this very dirty fix breaks things:
3) the image gallery module doesn't show all thumbnails (11/15, 3/4 and similar).
4) the thumbnails are cut off at the bottom: portrait images show square images, landscape images are missing the bottom 1/5 or so.
Ditto for previews, on single image node pages.
5) for some (but by no means all) preview files, I get a popup: "You have chosen to open $filename, which is a: BIN file from: http://localhost. Would you like to save this file?".
6) I get the same popup on most (but not all) original images -- but not every time.

Screenshot of 3-4 attached.

I hope this helps in pinpointing the cause of the problem.

Hetta’s picture

Hetta commented

My apologies, I did another run and derivatives are still generated in the current default image path on every view. I have no idea why the module didn't do that half an hour ago.

drewish’s picture

drewish commented
Status: Active » Fixed

i think what you need to do is open up the image settings form and saving it.

if that doesn't fix it then there's probably an issue with your server loading the images' modification time stamp. go a head and re-open this issue.

akash_m’s picture

akash_m commented

I observed that this happens only to images that are attached to other nodes ! any idea why this happens ? is it a bug in image attach module ?

Hetta’s picture

Hetta commented

Dunno if image gallery images are "attached to other nodes" or not, but it happens to them, wether attached to other nodes or not.

hd’s picture

hd commented
Priority: Normal » Critical
Status: Fixed » Active

I have got the same problem after upgrading to Drupal 5.1. Actually the problem is even worse than just always getting regenerated thumbnails and previews (and other sizes I have defined). Each time I have a new additional file being created with an incremented version counter like for example whatever-name.preview_99.jpg or even more strange whatever-name.preview_133.size300.JPG.

Gradually I am running out of disk space and besides needing a fix for this bug I will have quite a job at hand to fix this mess, means deleting these thousands of unwanted file versions. I am running CentOS 4.5.

I have changed the status to active, priority critical. Just opening up the image settings form and saving it does not help.

hd’s picture

hd commented

More info:

Besides the default image sizes thumbnail and preview, I have size200 and size300 defined. I have changed neither the width nor height when upgrading to Drupal 5.1. I typically see new filenames like:

whatever.preview_6.size200.size300.gif
whatever.preview_0.size300.jpg

It is concatenating the labels ...

In the Drupal DB, in the the image nodes, it still shows the old normal filenames for the images.

I am using $Id: image.module,v 1.209.2.24 2007/06/12 05:02:53 drewish Exp $

For the time being I have commented out the regenerating as described in post #1

drewish’s picture

drewish commented
Status: Active » Fixed

Helmut Debes, you need to upgrade to the latest -dev release: http://drupal.org/node/105536 make sure to follow the upgrade instructions.

yelban’s picture

yelban commented

http://drupal.org/node/105536 is Not Work!
still "had missing derivative image which has been regenerated"

>>Helmut Debes, you need to upgrade to the latest -dev release: http://drupal.org/node/105536 make sure to follow the upgrade instructions.

1. Make a backup of your files and database before beginning.
2. Use the Site maintenance setting (admin/settings/site-maintenance) to take your site off-line.
3. Update the module files.
4. Run the update.php script. To prevent the possible loss of image files, it is important that you do this before viewing any image nodes.
5. Check that your images display correctly.
6. Bring your site back online.

yelban’s picture

yelban commented

Does this problem relative with module i18n ?

hd’s picture

hd commented

I have updated the module to : July 8, 2007 - 12:06 version as recommended on my test system, following the steps as outlined (which look pretty normal and standard to me anyway). update.php found some things to do, but I do not remember the details.

Things do look better now! I do not get these unwanted image files generated anymore. Thanks for your help.

However, it is still regenerating all the derivatives saying "The image ... had missing derivative image which has been regenerated.", although these derivatives did exist. But it does that only once per image displayed, which means it should come to a rest once all images have been displayed. These messages about regenerating derivatives are displayed even to anonymous users, although error reporting is configured to write to the log file only.

I would not know why it "thinks" that the derivatives are missing, and I am not aware of having changed any settings.

I do not use the i18n module.

Hetta’s picture

Hetta commented

For files/image/$subfolders:

If you touch the default image path setting, all derivatives will be regenerated into the default image path (while originals will stay in their various subfolders); once that's over and done with, regeneration stops.

If you so wish, you can then move the derivatives into their correct subfolders under /files/images/, update files.filepath (in the drupal database), and leave the default image path setting alone after that.

(That's with a dev file from a few days ago, but things shouldn't have changed on that front since.)

It's entirely possible that derivatives will be regenerated again, if you touch the default image path again ...

drewish’s picture

drewish commented

after saving the settings the derivative images need to be rebuilt. it's pretty wasteful and at some point i'll change that so it only regenerates when the sizes are changed, but for now it's operating correctly.

Anonymous’s picture

Anonymous (not verified) commented

Now I understand why my images was regenerated twice in the past days. First I have installed the update (v1.4) and yesterday I've changed the option for original images.

Anonymous’s picture

(not verified) commented
Status: Fixed » Closed (fixed)
jsg’s picture

jsg commented

In my case, the problem was a surplus trailing slash in the default image path at /admin/settings/image. It took me weeks to find, though.