Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
  • Is something wrong?
#15,432 3 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
52/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
laravel, php
Domain
backend

Research direction

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.

Written by the indexing model from the issue text.

Description

assets caching
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: []
Dominant language
PHP
Stars
4.9k
Forks
647
Avg merge
1d 7h
Merged PRs (30d)
103

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from statamic/cms

All issues in statamic/cms

Similar issues

More PHP issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.