Server-side image resizing and cropping on the fly with caching of generated image-files using PHP.
The first image is also okey now (I recreated it using
&nc).
There are things appearing in the cache directoy
so it's writeable ok
https://salfordandcheethaminfocus.co.uk/cimage/webroot/imgp.php?src=POMC06608B.jpg&nc (works, recreates the cached image)
https://salfordandcheethaminfocus.co.uk/cimage/webroot/imgp.php?src=POMC06608B.jpg (does not work...)
https://salfordandcheethaminfocus.co.uk/cimage/webroot/imgp.php?src=POMC06608B.jpg (does not work...)
ok, done
I think that might have nailed it
Hm, maybe not
I guess I can just use &nc
would imagine serverside caching would deal with speed anyway
popped result into private message.
Thanks for your help. If you have a brainwave about the caching let me know but am happy :-)
Perhaps disable postprocessing (if you have enabled it), as a step in troubleshooting.
Still just guessing...
Ah, perhaps an issue with you (nginx) cache?
https://salfordandcheethaminfocus.co.uk/cimage/webroot/imgp.php?src=POMC06608B.jpg&1 (works, which might indicate caching issues related to the url since
https://salfordandcheethaminfocus.co.uk/cimage/webroot/imgp.php?src=POMC06608B.jpg (fails, for some reason, perhaps cached by nginx or other frontend cache)
https://salfordandcheethaminfocus.co.uk/cimage/webroot/imgp.php?src=POMC06608B.jpg&1 (works, which might indicate caching issues related to the url since
&1 is completely irrelevant for cimage)https://salfordandcheethaminfocus.co.uk/cimage/webroot/imgp.php?src=POMC06608B.jpg (fails, for some reason, perhaps cached by nginx or other frontend cache)
If it is only some images that fails, check each image, add
This somehow relates to what you said "it works if I change the order of the querystring arguments". That is irrelevant to cimage, but might indicate general http caching issues.
&1, if it works, suspect general http caching (nginx or other).This somehow relates to what you said "it works if I change the order of the querystring arguments". That is irrelevant to cimage, but might indicate general http caching issues.
This for instance works:
But this doesn’t (gives my “not found” image): https://cdn2.swcollectionsexplorer.org.uk/sizer/webroot/img.php?crop-to-fit&width=510&src=ramm/images/673-1997-8.JPG
It’s because my client uploads both to their cdn
Well, by definition image.jpg and image.JPG would be two different files (on linux filesystem). As long as you are consistent in naming files, and accessing them, you would get the "correct" file.
Image files on Windows might commonly be named
There is currently no such "convenience setting" to allow cimage to look at
You could "educate" your customer, thats is one option.
One might consider such a feature you are talking about, maybe, maybe not (not since it conflicts with how the filesystem works).
One could also consider to deal with this in the upload phase, if thats an option.
Image files on Windows might commonly be named
.JPG and accessing them as .JPG works.There is currently no such "convenience setting" to allow cimage to look at
.jpg and .JPG as the same image.You could "educate" your customer, thats is one option.
One might consider such a feature you are talking about, maybe, maybe not (not since it conflicts with how the filesystem works).
One could also consider to deal with this in the upload phase, if thats an option.
So, I have no real proposal on how to tolve it.
So for instance
and
…”resolve” to the same file
I guess I was hoping I could set up cImage to do the same. I don’t think client education is possible for all sorts of boring museum related reasons :-)
Thanks for letting me know.