Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
The file_entity module has a hook_file_update which flushes the image style cache every time a file entity is saved.
This will some times be overkill, so it should be possible to disable this behaviour.
Comment | File | Size | Author |
---|---|---|---|
#14 | 1974630-14-file_entity-image_flush.patch | 974 bytes | geoffreyr |
| |||
#10 | 1974630-10-file_entity-image_flush.patch | 1.65 KB | szantog |
#8 | 1974630-file_entity-image_flush-7.patch | 1.65 KB | hefox |
#6 | 1974630-file_entity-image_flush-6.patch | 1.65 KB | hefox |
#1 | file_entity-allow_disabling_on_image_flush_on_update-1974630-1.patch | 436 bytes | esbenvb |
Comments
Comment #1
esbenvb CreditAttribution: esbenvb commentedThis patch allows you to se a variable, file_entity_update_disable_flush, when set to 1 the image style cache will not be flushed.
Important: when porting the patch, remember to to the correct attribution according to http://drupal.org/user/989064
Comment #2
Devin Carlson CreditAttribution: Devin Carlson commentedimage_path_flush()
clears any cached versions of a specific file in all image styles. It doesn't flush cached media for an entire style likeimage_style_flush()
, so it actually provides a sort of performance benefit (since you don't have to flush an entire style cache/the entire image cache to see any changes).Disabling this would cause confusion to users if they used the "file replace" functionality to replace an existing image with a new image but the old image continued to be displayed throughout the website. A similar issue has already been brought up over browser caching of images #1701924: Add a cache-busting string to images.
Do you have a use case for disabling per-file image style cache flushing? :)
Comment #3
esbenvb CreditAttribution: esbenvb commentedThe problem is that all styled images for a particular file ID are deleted EVERY TIME i just add a tag or change the description of the image file...
Since we use remote storage, the causes operations to be much slower than they should - and we use the manualcrop module for cropping the images, which will delete the styled images when a new crop is made, so we don't really need file_entity to clear it as well...
I know that a lot of users will benefit from the default behavior of file_entity and that's why I added an option to toggle it instead of removing it.
Comment #4
Dave ReidMaybe we should more intelligently perform image_path_flush if $file->filesize != $file->original->filesize, which means the file *actually* changed.
Comment #5
Dave ReidActually might be nice to have a utility function to use here:
file_entity_has_file_changed($file, $original) {
return $file->filesize != $original->filesize || $file->uri != $original->uri;
}
Comment #6
hefox CreditAttribution: hefox commentedComment #8
hefox CreditAttribution: hefox commentedsyntax error, sigh
This saves 4 seconds on save with amazons3 module :)
Comment #9
hefox CreditAttribution: hefox commentedComment #10
szantog CreditAttribution: szantog as a volunteer commentedJust rerolled the patch for testing.
Comment #11
szantog CreditAttribution: szantog as a volunteer commentedComment #12
szantog CreditAttribution: szantog as a volunteer commentedAs I just rerolled the patch, I set it RTBC. Btw it works well.
This issue is major/critical if remote stream wrapper is used.
In our case when saving a node with 10-15 uploaded image. On the node form thumbnail image style is generated, then click on save, the generated images are flushed, however the only change of file is status to 1 at this point. Which means 20-30 api calls to amazons3.
Profiler said the 90% of runtime is file_entity_file_update. It's easy to run out of resources.
Comment #13
Dave ReidI think we could skip this entirely if we check if empty($file->is_new))= in file_entity_has_file_changed().
Comment #14
geoffreyr CreditAttribution: geoffreyr commentedThis patch is excellent, really saved my neck when I was working with RESTWS requests and finding that a simple PUT request to a file would take longer than five minutes to finish up. Reiterating @szantog's statement about it being essential when used with remote_stream_wrapper.
I've rerolled it against the latest DEV, with @Dave Reid's suggested change. I kept the check against
$file->file_entity_skip_image_flush
so one of our custom modules could fiddle it under the right circumstances.Comment #17
joseph.olstadLooks like a good change, thanks for the re-roll and reporting.
Comment #18
joseph.olstad