-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Page Object media exception on filesystem image change #3846
Comments
Try deleting the contents of the cache/ folder and see if that helps. |
Sure this helps, as clearing the cache in the backend does ;) But our approach is to use filesystem only for content editors, setting their ftp homedir to /grav/user/pages/ and not giving them backend access. |
Looks like it might be an issue with a check when "auto metadata exif" is enabled. Are you relying on this? perhaps try to disabling until I can get a fix. |
Disabling "Auto metadata from Exif" did the trick for deleting/adding images, but the exception remains for renaming images.
|
What is the exception now? I cant' recreate this with that EXIF setting disabled. |
"Fix orientation automatically" enabled was the setting to blame. fixOrientation() calls the exif_imagetype() uh, now renaming ends in a fallback image (/images/f/a/l/l/b/fallback.jpg) |
This should fix that exif_imagetype() exception: 8c1b444 Regarding the fallback image, something is still holding on to the cached reference. I'm still not able to reproduce this. What are you doing with the image? |
Yeah, the exception is gone, thanks a lot for that. What I am doing in the code:
What I am doing on the filesystem: The results:
|
the problem is that the cache doesn't know to check for changed media files by default. First, you can change try a couple of options in for the cache check in system.yaml: cache:
check:
method: hash You can also try Also you can change the Twig a little to make it safer. So instead of a stright: {% set thumb = media.images|first %}
{% set thumb_url = thumb.exists ? thumb.cropZoom(200,200) : 'path/to/blank.png' %}
<img src="{{ url(thumb_url) }}" /> This way it only runs cropZoom if the thumb exist, and it can fall back to blank image in the worst case scenario rather than the error image. |
just a quick reply for the cache, this is my (not working) setting
to verify, this setting gives the same (not working) result
|
With all caches disabled I still get an exception when changing images on the filesystem
What I did was deleting 111-002-1.png and adding newimage.png via ftp.
After that my macro crashes
Seems the page object still holds 111-002-1.png somewhere, even with all Caches disabled.
Any hints on ths?
--> Grav 1.7.46 with PHP 8.1
The text was updated successfully, but these errors were encountered: