What happens with images, generated and cached, when changed?

The fact that Grav can generate optimized images at specified sizes is great, but what happens to them once they are generated?

Lets say I want to give a new header image a try, so I load a new header image into pages template under a new name...but it doesn't work out too great. If I overwrite it with a new image of the same name, it doesn't regenerate.

Is there a way to empty all generated images on the site and have them regenerated as pages are visited? Or maybe even just the one header image?

You just need to delete the image it has generated. If you use firebug or inspect element feature you can easily track down where it is getting the header image from. It looks something like this: images/4/2/0/c/8/420c82349695366defba3f7f5ef1d584a8a6c509-
If you delete that file it will regenerate a new one based on your new image you have submitted.

The easiest and most reliable solution is to flush the Grav cache with bin/grav clear-cache command. This will clear all the generated images and force them all to be regenerated.

We use the Gregwar image library and it has it's own caching built-in. It caches based on file name + operations. It is not based on the fact that a file timestamp has changed. This ensures the maximum performance, but you an trip it up by replacing the existing image with the same filename. However, with the new file based cache mechanism that is currently sitting in develop, It seems that any file modification change triggers the cache flush. At least i've not had any trouble with changing the name of an image lately, but I certainly did experience this in prior versions. I guess I need to investigate it further :) Good question though!

Hi Andy,
I have experienced a recurring issue with images when I want to update them (e.g. to upload better compressed versions). I confirm that keeping the same file name doesn't flush the image cache (although I repeatedly deleted everything in the images directory).
Changing the image name causes errors (images not found under their previous names).
I wish I could go with a simple <code>bin/grav clear-cache</code> but so far I have not found the right directory to perform this. Alternatively maybe I should just manually recompile the css?

Every time you change something that is applied to the image, it should re-cache. For example, say you have:

{{ page.media['myimage.jpg'].quality(85) }}

Just changing one paramater:

{{ page.media['myimage.jpg'].quaility(95) }}

Is enough to regenerate the image. If your not changing the signature, then the best approach is to simply clear the image only:

$ bin/grav clear --images-only

This will clear out only the images/ folder where the images are cached, and not the page etc. Also note that bin/grav clear is a shortcut for bin/grav clear-cache.

You must run this at the root of your grav install. So the directory that contains CHANGELOG.md, LICENSE, README.md, composer.json, index.php, etc

Thanks a lot Andy, I am checking with my hosting provider to navigate to the root directory. That will clearly help me better administrate my grav instances)

Now I have changed the images several times during the past month and they did re-cache for a while but I guess the original one came back after a while (hours? days?). I checked this by testing my website on Google Pagespeed Insights (https://developers.google.com/speed/pagespeed/insights/) which is supposed not to cache the pages for more than 30sec. Either I'm missing something or there's a bug somewhere.

In case this points out something of an issue: I have repeatedly and manually cleared images from the cache without the newer version being taken into account.

1. I published blog posts (antimatter theme) with post illustrations that needed more compression
2. I then updated the post images (after further compression via tinypng.com)
3. After several - manual - tweaks there remains at least one image generated from the older version, a version that was replaced weeks ago in the post folder. Here is the currently cached image: (cropped to 900x300) http://reachcontent.com/images/e/4/6/5/9/e465939818b5aa7b60951d04e1e2bd8c01e0011a-strategie-contenu-transformation-digitale.png?946991d1
   (full height) http://reachcontent.com/images/e/8/9/4/7/e8947ac64415b0a8167ef85a617289232a71697e-strategie-contenu-transformation-digitale.png?946991d1
   As you can see the size is over 200kB whereas I uploaded a 68kB version

Manual tweaks include: deleting content of the /images directory several times, using the Cachebuster plugin (and thus clearing a dozen times) and setting cache expire in the .htaccess file:

ExpiresActive On
ExpiresByType image/jpg "access 1 week"
ExpiresByType image/jpeg "access 1 week"
ExpiresByType image/gif "access 1 year"
ExpiresByType image/png "access 1 week"
ExpiresByType text/css "access 1 month"
ExpiresByType text/html "access 1 week"
ExpiresByType application/pdf "access 1 month"
ExpiresByType text/x-javascript "access 1 month"
ExpiresByType image/x-icon "access 1 year"
ExpiresDefault "access 1 month"

Strange that these tweaks seem to have worked for all but one image.

I actually think you are getting the updated images. Grav doesn't have some magical place it puts these files, they are simply manipulated and stored in the images/ folder. If you remove these manually or clear the cache, you will see them being regenerated the next time you request a page with them on.

However, this image library we are using (Imagewar), is probably taking your hightly optimized image (68kb) and then performing its manipulations using PHP's GD library, creating a new file, and the resulting image is actually bigger (200kb) because it does not have all the sophisticated (and slow) optimizations that your optimization software/site is using.

This unfortunately is beyond our control. If you are really concerned about the size of your images, you will need to perform all manipulations yourself (size, color, etc), then optimize, then use the image without any media manipulations.

Ok, thanks a lot, that answers my question)