Closed (works as designed)
Project:
Drupal core
Version:
7.x-dev
Component:
user.module
Priority:
Minor
Category:
Feature request
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
19 Nov 2005 at 05:27 UTC
Updated:
15 Nov 2014 at 05:50 UTC
Jump to comment: Most recent
Comments
Comment #1
killes@www.drop.org commentedMakes sense to me. But won't there be problems if people upload a new image? Will the browser continue to display the old image even for them?
Comment #2
Wesley Tanaka commentedA cache length of a few minutes or a few hours would help prevent the images reloading when hitting the back button through already viewed pages. I don't care too much about the new upload case -- other users browsers will check eventually and I think people are used to hitting reload to see if something's changed if they care (like they got a message saying "check out my new picture" or something).
What I did on my site before switching to drupal was making the image displayed in the "edit user profile" page load with a "cache=no" argument, which turned off caching completely for that page load. When the user uploaded a new image, their own profile reflected the change immediately, but perhaps it would take a while to show up in their public profile for people that had looked at it before.
Comment #3
ricabrantes commentedAny activity???
Comment #4
Wesley Tanaka commentedStill exists in Drupal 6
Comment #5
scoutbaker commentedFeature requests go to the latest dev version. Moving to 7.x-dev.
Comment #6
dave reidMarking #360143: Implement cache-busting query for user pictures as a duplicate to be solved with this issue.
Comment #7
quicksketchThis seems like a very minor improvement. You are aware that this only applies to sites that are using the "Private Downloads" functionality? If using public downloads, files are never run through hook_file_download.
Comment #8
Wesley Tanaka commentedI am aware that "Private" file transfer offers the advantages of being able to do access control and header modifications.
I would agree with you that this change does not affect anyone who is not using that Drupal feature.
Comment #9
netw3rker commentedI think this has been largely resolved with how the core Image module handles the style processing of images before shipping them off to the requester.
as I see it, there are 3 issues being discussed here:
1) what happens when the old file is replaced?
answer) in #668058: Resubmitting a user picture does show the first uploaded picture a fix was introduced that adjusts the file name to be unique every time it is uploaded, ensuring that the system will pick up the change
2) what about @dave_reids cache buster problem?
answer) that was addressed in the image module. see and note the end of the url here:
https://www.drupal.org/files/styles/drupalorg_user_picture/public/user-p...
with each cache purge the indicator changes, and a new file is pulled and rendered.
3) what about private filesystems:
answer: for private files the image module should work the same way & respect the cache breaker and supply the same cache headers as other file assets. At a minimum if this is not the case, the performance concern of the OP is largely mitigated. Even if images are re-requested each time, they are not being re-computed anymore (as i'm pretty sure was the case in d4/5/6) and are now actually filesystem cached in rendered form. the bootstrap/delivery process would be light in this situation.
FWIW, Drupal has put a big onus on external cache systems for fully rendered page objects; leveraging things like cdn's and varnish. I know in the OP's case something like this is probably akin to using a cannon to kill a mosquito, but using varnish to cache the /system/files/pictures/xxx pattern would solve this problem specifically.
I'm marking this as Closed because I'm pretty sure that this (using the core Image module) resolves the issue. If anyone wants to do further testing to refute the image module resolving this issue in 7.x and higher please re-open the issue.