Instead of rebuilding every single image node's derivative for that changed dimension (which on a site that I run with several hundred images always brings the server to a crawl, at which point, I stop apache, start apache and let each node be rebuilt as it is viewed/needed) why not just let the derivative become stale? It will be regenerated anyhow upon the next view.

And even if someone wanted to regenerate all their images (what server can regenerate the derivative images of several hundred 5+ MB images without taking a performance hit?) all at once, they could go into admin/content, filter by image module, check all the boxes and hit the rebuild button.

The way I see it, either this functionality can either be removed or made optional.

Please let me know what you think.

Thanks!

(Applies to both 6.x-1.x as well as the 5.x series)

Comments

dman’s picture

dman commented

Isn't that the current behaviour?
When you change the settings, a timestamp is flagged.
Next time the image is requested, it's rebuilt only if detected to be stale. It doesn't actually make the changes on submit of the settings, just queues them.

You want the performance hit only to happen when needed. It does ?

PS, you can't check 'all' the buttons on the admin/content screen if you are serious about hundreds of huge images. I'm doing the same. It's just painful. I'm now using views_bulk_operations to manage my process.

Brian@brianpuccio.net’s picture

Brian@brianpuccio.net commented

Hi dman,

Right now, when I hit the submit button on the settings page after I've entered a new size and view top for my server, I see a whole bunch of convert processes appear right then. I try to let them run, but the server slows to a crawl and top slows in its updating. While this has happened, the screen still hasn't finished loading in my web browser.

At that point, I stop apache, then start it again, then type in the URI of an image. I see one or two convert processes for about a second, but then the page loads in my browser. I can regenerate a few images at a time in the content screen without killing my VPS.

I think this portion of code from the image.admin.inc is what does it:

    // Check for changes.
    else if (isset($form_state['values']['image_sizes'][$key]) && isset($old_sizes[$key])) {
      // Did the operation, height or width change?
      foreach (array('operation', 'height', 'width') as $field) {
        $rebuild |= ($form_state['values']['image_sizes'][$key][$field] != $old_sizes[$key][$field]);
      }
    }
dman’s picture

dman commented

OK, if that's happening it must be a totally different approach from the DRUPAL-5 behaviour I'm used to.
Personally I thought it should go into cron :-)

yesct’s picture

yesct commented

could someone suggest a patch to change the 6.1 behaviour to let it go stale?
or should this be a feature request to add an option to choose between the two ways?

drewish’s picture

drewish commented
Status: Active » Closed (duplicate)

i think this is really a duplicate of this issue:
#177374: Move sizes settings into table, only rebuild changed sizes