This is the backlog of ideas and feature requests from the last two years. Use our new feedback platform to post your new ideas or vote on existing ideas.
I can see that 3.4.0 brought the content.salt option. However, I think it would be more useful to have control over the whole hash.
Problem
We have a site that is hosted on Amazon and uses Elastic Beanstalk. It starts multiple instances and we have a load balancer that distributes the traffic. The problem is that once instance handles the request for the HTML of a page, another one handles the request for the actual media image, and the hashes differ. That happens because the modified date of the original image in the content folder is part of the hash and that timestamp differs between instances since there's a slight delay.
Something like this happens:
User requests the page
Instance A responds with media hash {{ token }}-1595314510936 in the HTML
Instance B later handles the image request, but its hash for this image is {{ token }}-1595314601719
There's also another problem - instance A handles the HTML request and creates the job file for the thumbnail, but instance B is expected to generate it, which fails because instance B has no job file. This means you get broken images until you've refreshed enough times that each instance is handled both a request for HTML (to create a job file) and a request for the image itself (to generate the thumbnail). But even after that - the hashes differ and Kirby redirects when the hash is "outdated." Then, that response is cashed by the CDN... It becomes messy.
Our current solution is to hack in the Kirby core and change this from:
Also, to avoid having to wait for instances to generate thumbnails themselves, we generate them locally and add them to the bundle we upload to Amazon. We also use content.salt and set it to a constant like false because the default salt is the root of the file, and that differs between our local machines and the Amazon instances.
So basically, the media hash is constant - just the hashed file ID. But that works because all instances use the same hashes, we can generate the thumbnails locally, upload them, and they just work.
Proposal
It would be great to have a content.hash option that gives you control over the entire hash since, for our use case, the salt is not enough. If we had this option, we could do our setup like this:
I can see that 3.4.0 brought the
content.salt
option. However, I think it would be more useful to have control over the whole hash.Problem
We have a site that is hosted on Amazon and uses Elastic Beanstalk. It starts multiple instances and we have a load balancer that distributes the traffic. The problem is that once instance handles the request for the HTML of a page, another one handles the request for the actual media image, and the hashes differ. That happens because the modified date of the original image in the content folder is part of the hash and that timestamp differs between instances since there's a slight delay.
Something like this happens:
{{ token }}-1595314510936
in the HTML{{ token }}-1595314601719
There's also another problem - instance A handles the HTML request and creates the job file for the thumbnail, but instance B is expected to generate it, which fails because instance B has no job file. This means you get broken images until you've refreshed enough times that each instance is handled both a request for HTML (to create a job file) and a request for the image itself (to generate the thumbnail). But even after that - the hashes differ and Kirby redirects when the hash is "outdated." Then, that response is cashed by the CDN... It becomes messy.
Our current solution is to hack in the Kirby core and change this from:
...to:
Also, to avoid having to wait for instances to generate thumbnails themselves, we generate them locally and add them to the bundle we upload to Amazon. We also use
content.salt
and set it to a constant likefalse
because the default salt is the root of the file, and that differs between our local machines and the Amazon instances.So basically, the media hash is constant - just the hashed file ID. But that works because all instances use the same hashes, we can generate the thumbnails locally, upload them, and they just work.
Proposal
It would be great to have a
content.hash
option that gives you control over the entire hash since, for our use case, the salt is not enough. If we had this option, we could do our setup like this: