Bug description
With statamic.assets.image_manipulation.cache = true (Glide "cached" mode, images served as plain
files out of public/img) and static caching enabled, changing an asset's focal point deletes every
generated image for that asset but leaves the statically cached HTML that references them untouched.
Cached mode registers no /img route, so the stale paths in that HTML have no PHP fallback. They are
plain 404s and nothing regenerates them. The page stays visibly broken until its HTML happens to be
invalidated by something else, or an editor clears the static cache by hand.
Reproduced on two Statamic 6 instances. Opening this as a new issue at @duncanmcclean's request —
this is the same report as #8856, which was closed as not reproducible.
Two config values decide whether this is visible, and the repro attempt in #8856 had both set to the
values that hide it:
1. image_manipulation.cache. With the default cache = false, a stale URL still reaches
GlideController, which regenerates on demand. The worst case is an out-of-date crop for one
request, which looks cosmetic and self-heals. With cache = true there is nothing to fall back to —
php artisan route:list --path=img comes back empty.
2. 'rules' => 'all'. That short-circuits in DefaultInvalidator::invalidate():
if ($this->rules === 'all') {
$this->refreshing
? $this->cacher->refreshUrls($this->cacher->getUrls()->all())
: $this->cacher->flush();
return;
}It flushes before ever reaching getItemUrls(), so every asset save nukes the whole static cache and
the problem is invisible. Anything other than 'all' — including the shipped default, which is an
empty 'rules' => [] — lands in getAssetUrls() instead:
protected function getAssetUrls($asset)
{
$rules = collect(Arr::get($this->rules, "assets.{$asset->container()->handle()}.urls", []));
...
}That reads rules.assets.{container}.urls and returns [] when the key is absent. Neither the
shipped default nor either of my sites has an assets key — one site defines only collections
rules, the other only globals rules. So Invalidate is wired up (AssetSaved => refreshAsset),
fires correctly, and invalidates nothing. A silent no-op.
Why the focal point in particular
ImageGenerator::applyDefaultManipulations() adds fit = crop-{focus} when auto_crop is on, and
GlideManager::getCachePathCallable() hashes the whole parameter set into the filename:
md5($sourcePath.'?'.http_build_query($params))
So a new focal point (including a change to just the zoom value) produces a different filename.
Meanwhile ClearAssetGlideCache::handleSaved() calls Glide::clearAsset(), which deletes the
asset's entire cache directory and forgets every manipulation key from the manifest.
PresetGenerator::generate() then regenerates only configured presets — nothing at all when
image_manipulation.presets is empty, which is the default.
Net result: the old file is gone, the new one lives at a different path, and the cached HTML still
points at the old one. Regenerating cannot fix it, because the URL in the HTML no longer corresponds
to anything that will ever be generated. Only invalidating that HTML can.
Queue ordering
Worth noting even for sites that do configure an assets rule: Invalidate and
ClearAssetGlideCache are both ShouldQueue and both land on the same queue. If Invalidate runs
first and traffic re-renders the page before ClearAssetGlideCache gets to it, the freshly cached
HTML captures the about-to-be-deleted path and breaks a second later. Both of my instances run
QUEUE_CONNECTION=redis, so these genuinely run concurrently.
How to reproduce
- Fresh Statamic 6 install.
config/statamic/assets.php:
'image_manipulation' => [
'cache' => true,
'cache_path' => public_path('img'),
],
'auto_crop' => true,STATAMIC_STATIC_CACHING_STRATEGY=half. Leave invalidation.rules at the shipped default — no
assets key. Do not use 'all'.- Page template:
{{ glide:image width="800" height="500" }}.
- Visit the page. The HTML is cached and the file lands at
public/img/containers/assets/<folder>/<file>.jpg/<hash>/<file>.jpg.
- Control Panel → open the asset → change the focal point (or just its zoom) → save.
- Reload the page.
Expected: the page renders a new Glide URL cropped to the new focal point.
Actual: the cached HTML serves the old path, the file behind it is gone, and the image 404s. It
stays broken until that page's HTML is invalidated by something unrelated, or an editor clears the
static cache by hand.
Related
#8856 (same symptom, closed unreproduced), #6308 (auto-crop URL doesn't change in dynamic mode — same
root cause, benign variant), #8632 (presets deleted on focal point change, none regenerated), #15199
(regenerates when the cached file is missing, which covers the sibling case where files are wiped but
the cache entry survives — not this one, since here the manifest keys are correctly forgotten and the
path genuinely changes).
Logs
No response.
Environment
Statamic: v6.18.1 Pro and v6.31.0 Pro
Laravel: v13.9.0
PHP: 8.4.23
league/glide: 3.2.0
Static caching: half
Queue: redis
statamic.assets.image_manipulation.cache: true
statamic.assets.auto_crop: true
statamic.assets.image_manipulation.presets: []
Bug description
With
statamic.assets.image_manipulation.cache = true(Glide "cached" mode, images served as plainfiles out of
public/img) and static caching enabled, changing an asset's focal point deletes everygenerated image for that asset but leaves the statically cached HTML that references them untouched.
Cached mode registers no
/imgroute, so the stale paths in that HTML have no PHP fallback. They areplain 404s and nothing regenerates them. The page stays visibly broken until its HTML happens to be
invalidated by something else, or an editor clears the static cache by hand.
Reproduced on two Statamic 6 instances. Opening this as a new issue at @duncanmcclean's request —
this is the same report as #8856, which was closed as not reproducible.
Two config values decide whether this is visible, and the repro attempt in #8856 had both set to the
values that hide it:
1.
image_manipulation.cache. With the defaultcache = false, a stale URL still reachesGlideController, which regenerates on demand. The worst case is an out-of-date crop for onerequest, which looks cosmetic and self-heals. With
cache = truethere is nothing to fall back to —php artisan route:list --path=imgcomes back empty.2.
'rules' => 'all'. That short-circuits inDefaultInvalidator::invalidate():It flushes before ever reaching
getItemUrls(), so every asset save nukes the whole static cache andthe problem is invisible. Anything other than
'all'— including the shipped default, which is anempty
'rules' => []— lands ingetAssetUrls()instead:That reads
rules.assets.{container}.urlsand returns[]when the key is absent. Neither theshipped default nor either of my sites has an
assetskey — one site defines onlycollectionsrules, the other only
globalsrules. SoInvalidateis wired up (AssetSaved => refreshAsset),fires correctly, and invalidates nothing. A silent no-op.
Why the focal point in particular
ImageGenerator::applyDefaultManipulations()addsfit = crop-{focus}whenauto_cropis on, andGlideManager::getCachePathCallable()hashes the whole parameter set into the filename:So a new focal point (including a change to just the zoom value) produces a different filename.
Meanwhile
ClearAssetGlideCache::handleSaved()callsGlide::clearAsset(), which deletes theasset's entire cache directory and forgets every manipulation key from the manifest.
PresetGenerator::generate()then regenerates only configured presets — nothing at all whenimage_manipulation.presetsis empty, which is the default.Net result: the old file is gone, the new one lives at a different path, and the cached HTML still
points at the old one. Regenerating cannot fix it, because the URL in the HTML no longer corresponds
to anything that will ever be generated. Only invalidating that HTML can.
Queue ordering
Worth noting even for sites that do configure an
assetsrule:InvalidateandClearAssetGlideCacheare bothShouldQueueand both land on the same queue. IfInvalidaterunsfirst and traffic re-renders the page before
ClearAssetGlideCachegets to it, the freshly cachedHTML captures the about-to-be-deleted path and breaks a second later. Both of my instances run
QUEUE_CONNECTION=redis, so these genuinely run concurrently.How to reproduce
config/statamic/assets.php:STATAMIC_STATIC_CACHING_STRATEGY=half. Leaveinvalidation.rulesat the shipped default — noassetskey. Do not use'all'.{{ glide:image width="800" height="500" }}.public/img/containers/assets/<folder>/<file>.jpg/<hash>/<file>.jpg.Expected: the page renders a new Glide URL cropped to the new focal point.
Actual: the cached HTML serves the old path, the file behind it is gone, and the image 404s. It
stays broken until that page's HTML is invalidated by something unrelated, or an editor clears the
static cache by hand.
Related
#8856 (same symptom, closed unreproduced), #6308 (auto-crop URL doesn't change in dynamic mode — same
root cause, benign variant), #8632 (presets deleted on focal point change, none regenerated), #15199
(regenerates when the cached file is missing, which covers the sibling case where files are wiped but
the cache entry survives — not this one, since here the manifest keys are correctly forgotten and the
path genuinely changes).
Logs
No response.
Environment