When you crop a image, the croped image replaces the old one, so, when you see the page for th first time, you will see the old image, as it is client side cached.

This patch solves the issue renaming the new croped image, so the url will be diferent and the browser will no cache it.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

akalam’s picture

Status: Active » Needs review
FileSize
880 bytes
boshtian’s picture

Confirming the solution, but the patch is not working on latest dev version of 1.x branch.

Adding a new patch with same solution, just different line numbers.

Please test and if it's ok you can add this to 1.x dev version.

joe_carvajal’s picture

Hi!

I had the same problem, but in my case I had two image field for the content type, one with the cropped image and other with the full image.
When you upload the same image twice (first one to crop and another one for preserve the full image), the browser caches the full image and won't load the cropped image properly until refresh the page.

I added a timestamp in the filename before save, just to avoid browser to cache the exact image.
I create the patch using the stable version (1.1) because it's the version we used in the project. Should I reroll it to the dev version?

Thank you for the patch, guys!

Edit: the "trailing spaces" were removed by my IDE, sorry about it :S Just noticed it after the file upload.

Les Lim’s picture

Title: Original image displayed when the node is viewed for the first time. (1.x port) » Replacement crops are not showing because of external file caching
Priority: Minor » Normal
FileSize
6.26 KB

Re-titling for clarity.

We had the same problem, but each of the above solutions ended up creating new, duplicate crop derivatives every time the parent entity form was saved, even if the crop settings hadn't been touched.

We also determined that we needed the filename of the cropped image to change in order to bypass external caching like CDN, Varnish, or browser-based cache. This patch alters the crop filename by appending the scale/crop parameters used to generate the crop. This should eliminate the possibility of many duplicates of the exact same crop. Meanwhile, the original image file is saved with its original filename.

The patch also prevents the crop from being regenerated if the crop settings have not actually changed.

altrugon’s picture

The solution proposed by Les Lim #4 worked for me although I wasn't able to apply the patch and I had to do it manually.

I'm attaching my patch against 7.x-1.x (commit 69343ad0d548c7cbc98db2a2078d3c4e6fb987c8).

Les Lim’s picture

This strategy is still mostly working for us after a couple months, except for one thing - trying to upload a file when the same filename already exists in the destination causes a PDOException. Drupal core deals with this by appending a counter to the filename to ensure unique filenames, but we forgot to do that here.

Here's a new patch off of 7.x-1.x-dev that runs the destination filepaths for both the original and derivative images through `file_destination()`.

jascote’s picture

The patch in #6 causes an image file rename for the cropped image that's different from the value in the file_managed table. This causes the cropped image to not be used. Changing the call to the _imagefield_crop_resize function to use FILE_EXISTS_REPLACE instead of FILE_EXISTS_RENAME fixes this.

Here's a patch that includes that update.

jenlampton’s picture

Status: Needs review » Needs work

Looks like this patch needs a re-roll against the latest -dev.

mrinalini9’s picture

Status: Needs work » Needs review
FileSize
6.24 KB

Rerolled patch #7 for 7.x-1.x branch, please review it.