Filament & Spatie Media Library not Showing Img on edit.
I have a resource that works perfectly in development with spatie media library img upload. On a dev server I can upload images and process them, but when i go back to edit the record i get the img file name on top but i cant see the img. If i drill down to the html i find the URL for the correct img. If i click on the link o go to the img.
I have scratched my head over this and i cant seem to find why its not displaying within the resource Edit page but the url is there and accessible.
5 Replies
Did you check your DevTools? Might be a CORS issue
Long shot - I had the same issue as you. Turned out to be that I was using site.dev instead of www.site.dev.
Thank you, but I already ran down that road and its not CORS. Also The same server stores the filament application and images.
.env url is set to https://ip is correct as well as .htacces
No console errors?
It does not have one… I have not solved it but I think I figured out what might be going on. After screwing around and throwing darts in the dark I managed to cause an error. Your recommendation on CORS gave me an idea to generate that error and see if the output might lead me somewhere. The problem seems to be chrome based. It does not trust the self signed cert and it blocks the content. But when I change the headers avoid cors errors then the error goes away, the link is there but it does not present the content on screen. So if I go into the HTML I can click the link and see the img but chrome is not rendering. I’ll get back to it tomorrow and as soon as I have a clear idea of what’s going on and why I’ll post it
Ok: from what i have been able to gather.
1. When correctly configured this problem does not generate an error.
2. I intentionally created a CORS error by setting a difference between a http request and an https request. Where the app_url would point to one and i would access from the other (apache2 sites-available / enabled).
This returned this error:
"To mitigate these risks, Chrome deprecates requests to non-public subresources when initiated from non-secure
contexts. See the feature status . To fix this issue, migrate the website that needs to access local
resources to HTTPS. If the target resource is not served on localhost, it must also be served on HTTPS
to avoid mixed-content issues.
Administrators can make use of the InsecurePrivateNetworkRequestsAllowed and
InsecurePrivateNetworkRequestsAllowedForUrls enterprise policies to temporarily disable this restriction
on all or certain websites.
2 requests
Request Status Resource Address Initiator Address Initiator Context
01HZNDH7DMABJAE022G86GZCK2-300_160.webp blocked Private Public insecure
01HZNDH7DMABJAE022G86GZCK2-300_160.webp blocked Public insecure"
3. Part of the problem might come from routing. I am forwarding from public ip non standard port to ports 80 and 443.
4. Created new server from the ground up. Assigned it one IP and routed ports 80 and 443 from public ip to the apache server. This worked when visiting from within the network on the private IP. Not from the public IP still no error.
Probable conclusions: explorers are not accepting self signed certificates on IP based navigation. Not a Filament problem.
Would still need to test with FQDN and self signed cert.
Will work with FQDN + authority certificate