Changing an asset's focal point permanently 404s its images on statically cached pages (Glide cached mode)

Start by tracing Invalidate/DefaultInvalidator::getAssetUrls() and ClearAssetGlideCache::handleSaved(), then check ImageGenerator::applyDefaultManipulations() and GlideManager::getCachePathCallable(). Reproduce with the listed cached-mode and static-caching settings, changing an asset's focal point. Done means the affected cached page no longer references a deleted image and serves an image cropped to the new focal point.

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

1. Fresh Statamic 6 install.
2. config/statamic/assets.php:

   'image_manipulation' => [
       'cache' => true,
       'cache_path' => public_path('img'),
   ],
   'auto_crop' => true,
   

3. STATAMIC_STATIC_CACHING_STRATEGY=half. Leave invalidation.rules at the shipped default — no
   assets key. Do not use 'all'.
4. Page template: {{ glide:image width="800" height="500" }}.
5. Visit the page. The HTML is cached and the file lands at
   public/img/containers/assets/<folder>/<file>.jpg/<hash>/<file>.jpg.
6. Control Panel → open the asset → change the focal point (or just its zoom) → save.
7. 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: []