Force resized images to be regenerated when the source image changes#178
Force resized images to be regenerated when the source image changes#178LukeTowers merged 1 commit intowip/1.2from
Conversation
This should fix #177, but it will cause all existing installations to resize all of their already resized images. Another alternative could have been to include the hash of the source image; but it would have been at the expense of more work every time this function is called, which could potentially include generating hashes of multiple extremely large (10+ MB) images on every page load if the page includes such images that need to be resized since the filter needs to identify the configuration in order to identify the path to the resized image to check if it needs to return a resizer/ URL or a /resized one. Further improvements could potentially be made in the isResized()
|
@bennothommo did you have any ideas for a better experience for this:
|
|
@LukeTowers I personally don't see a problem with that. The resized images should be considered temporary and treated as a "cache" so to speak. |
|
@bennothommo fair enough, but if we treat it that way then we need to provide a way to clear the cache. Will wait to merge this until we can add a util command to purge the resized images cache. |
|
With that as well, should we provide a migration that clears that cache as a part of the update to avoid unnecessarily cluttering up people's storage directory with now-invalid images or is the added server load of regenerating all existing images not worth it (especially if they're caching the generated HTML which could include references to final files that would no longer exist). |
|
I would envisage that the server load would be staggered, as the resizing only happens on an "as-needed" basis, when people load up a particular page with the resized image(s), so I don't think that's too much of a concern. We definitely will need some form of command though to clear the cached resized images, if I'm not sure what we can do about people caching the generated HTML (and ostensibly, the resized image's direct URL). I would hope that doing a |
I think it would not be about clearing the actual Cache, it would also be about removing all the resized images. But perhaps that is what you meant anyway. |
|
This pull request will be closed and archived in 3 days, as there has been no activity in the last 60 days. |
|
This pull request will be closed and archived in 3 days, as there has been no activity in the last 60 days. |
|
This pull request will be closed and archived in 3 days, as there has been no activity in the last 60 days. |
|
This pull request will be closed and archived in 3 days, as there has been no activity in the last 60 days. |
This should fix #177, but it will cause all existing installations to resize all of their already resized images.
Another alternative could have been to include the hash of the source image; but it would have been at the expense of more work every time this function is called, which could potentially include generating hashes of multiple extremely large (10+ MB) images on every page load if the page includes such images that need to be resized since the filter needs to identify the configuration in order to identify the path to the resized image to check if it needs to return a resizer/ URL or a /resized one.
Further improvements could potentially be made in the isResized() / getPathToResized() methods to cache the results to avoid doing all the work involved with the getConfig() method while still allowing people to run a command to trigger a refresh.