Imgix / CDN + Kirby Media fingerprints → exploding origin url count

The CMS Questions
1

Hi all,

I’m looking for guidance on the correct strategy when using Kirby together with Imgix (or similar CDNs that bill/count by unique origin URLs).

Context

We’re using Kirby 4 together with the diesdasdigital/kirby-imgix plugin.
The plugin uses $file->mediaUrl() as the Imgix origin. Imgix is setup with a web folder source.

After some time in production, we noticed that Imgix reports a very high number of “origin images” (we’ve exceeded our plan limit). When looking at Imgix analytics, we see many entries like:

/media/pages/artists/the-artist/a6a6c320a9-1760044320/image.jpg

/media/pages/artists/the-artist/658fa9bcbd-1760044320/image.jpg

/media/pages/artists/the-artist/4b3660e994-1760044320/image.jpg

These are the same image file, but with different media folder hashes. In many cases the same image appears 7–8 times with different fingerprints.

From Imgix’ point of view, each of these counts as a new origin image, even though the binary image didn’t change.

What seems to trigger new fingerprints

From testing and observation, it looks like a new media hash unexpectedly is generated when things like:

  • a page’s status changes (draft ↔ unlisted ↔ listed)
  • a page’s sorting order changes

In addition, these changes cascade: when an editor changes the status or sorting of a parent page, the media fingerprints for all child pages seem to change as well.

As a result, a single editorial action can trigger a large increase in unique /media/.../<hash>/... URLs, which is problematic when using a CDN that treats each URL as a distinct origin image.

(We have large “collection” parents containing lots of child pages. A recent temporary status change to one of these parent pages totally blew our Imgix origin image budget)

My questions

  1. Which actions officially cause Kirby to generate a new media fingerprint?
    Is it expected that page status and sorting changes regenerate media hashes even if the image itself is unchanged?
  2. Is there a recommended strategy for this scenario?
    • Accept media fingerprinting and live with inflated CDN origin counts?
    • Somehow use a custom route / stable origin URL (UUID-based or similar)?
    • Something else I’m missing?
  3. From a Kirby perspective:
    Is this considered “working as intended”, or are there patterns/plugins the community recommends for CDN integrations that require stable origin URLs?

I’m trying to decide whether this is something worth engineering around, or if the correct answer is simply “that’s how Kirby media works; plan CDN usage accordingly”.

Any insight from the core team or others running Kirby + Imgix/Cloudinary/etc. in production would be hugely appreciated. :folded_hands:

Thanks!

2

Please take a look at the content.salt config setting: content | Kirby CMS

I can’t pretend I fully understand what exactly it does without actually testing it…

Ok, after clarifying with the team:

In K5, we changed from using the model root to using the model id, so that changing the page status or position will no longer change.

In K4 setting the content.salt to something of your liking should have the same effect.

3

Sounds promising. In the docs the salt section has a ”since Kirby 5” mark, but maybe that is just for the last example? I will try it out soon.

Thanks for looking into this!

4

The since tag refers to the paragraph that follows

1 Like
5

This does seem to work for me! thanks again.