Help!
Working on moving a site to a different server and now the site isn’t loading images.
I have tried everything I can think of!
Here is a link to the page on the new server:
http://ba11c581559503919.temporary.link
Screenshots of the panel:
Unfortunately, you don’t say what you have already tried…
- Did the images get copied to the media folder? Make sure the folder exists and is writable?
- Make sure you haven’t copied the media folder to the server, if you have done this, delete it, it should be recreated.
- Which Kirby 3 version are you using?
The server you linked seems to run nginx. While the old server also seems to be nginx, that server is a bit more complicated than your standard apache (moving the files in the webroot might not be enough).
Are you sure you configured the new server correctly?
Here’s a guide: Running Kirby on a Nginx web server | Kirby CMS
I’m thinking about configuration because the error page you’re getting for the images directly comes from nginx, while I’d expect either an image or at worst an error message from Kirby. It looks like requests to the media folder aren’t handled by the kirby “index.php”, while they really should, at least for non existing files.
I did delete the media folder and the new one it creates appears to not have images in it.
It is writeable.
Running Kirby 3.6.0
I have no experience with Nginx but will look into the link you provided.
I have had kirby sites on InMotion Hosting before and have never had issues.
But am struggling finding the solution to this problem.
Been looking into the link you had sent. But when logged into the server I can not find a Nginx folder like the article mentions for config.
Attached is a screenshot of the server.
Hm, what I can see from the outside (because indexing is not off) is that there are some subfolders for images created in the media/pages/ folder (but no images moved there), but not all pages, which is a bit weird.
However, the folder names which do exist in the media folder do not seem to belong to current image urls. Which makes me think: Do you have Kirby pages cache enabled?
The site public files are generated on my local machine. The media folder generates sub folders named with an ID.
That folder structure is uploaded to the server. The media files result in a 404 error because the server media sub folder ID is different from the local ID folders.
How do I get the ID folders on the server to be the same as the ones generated locally?
Not sure I understand.
You should never upload the media folder to a remote server. It will be created and filled automatically.
Make sure that also the /site/cache folder is empty if caching is enabled, so you are not calling old urls.
If the issue persists despite that, then you have to look into your server configuration as @rasteiner already wrote above. The server is definitely not properly configured if directory indexing is possible (e.g. Index of /content/2_cabins), this has nothing to do with your issue but is nevertheless very bad.
When I don’t upload media folder and cache folder (deleting all on the server prior,) the images aren’t generated on the server. All I see are .job folders. Thoughts?
I understand now if I upload the media folder that will result in the ID folders not matching. For your own understanding, here is an is an example of what I meant by ID folder:
/studio-cabin/b9ac5e17dc-1656096160/feature.jpg
Yes, these media hashes that are created from the modified file stamp and a hashed page id.
Ok, when the job files are created, that’s a good sign, because it means that the media folder is writable. And now the media hash that in the url is also the same that is created in the media folder. Remains the questions why the files are not copied over. You are not using thumbs, so we can rule out gd/imagemagick issues.
It might be worth looking into your server/php error logs to see if you can find any hints there.
Cpanel has no recent errors on the domain.
So I updated Kirby to the latest version too.
The hosting doesn’t give me access to the nginx config.
I have had other kirby sites on this hosting service that work fine.
So I deleted everything out of the public_html folder and the tested the kirby starter kit and it isn’t loading images either. so must be something with the server. Any thoughts before I spend a lot of time on the hosting chat?
Well I ended up closing my InMotion hosting account because they could not help me find the solution which is obviously a server issue. The site works flawlessly on my local development.
Any tips on a preferred hosting company?
Well I hope I don’t have to switch servers! Like the OP my site is working perfectly on localhost:8000. I am using Bigscoots hosting. When I upload my site (minus the cache and media folders) everything works except image and file access. The paths appear to be correct. In fact they are the same as the ones that work on local, with the domain changed.
In the Kirby Panel, some images display just fine. But images in content blocks are broken in the Panel as well.
What further information would be helpful to post here to get help with this problem?
It sounds like your hosting package might not have the GD lib extension or imagemagick on the server. Could you double check if GD lib is available to process the images?
It looks like both gd and imagick are available and active. Oh, and actually I can see that the media folder is recreated, and contains generated images in different sizes.
I did check the Kirby error log as well but did not see anything there.
I had added a plugin based on this documentation: File URLs | Kirby CMS to use “friendly” file urls rather than uuid-based urls. For some reason that works fine on my local environment, but not in production. (Even though the image and pdf file are where they are linked to in the html, so still mysterious to me.) Anyway removing that plugin solved the issue with “not found” images and pdfs. I used the solution here: Page links not working in text blocks to output friendlier file urls.
I’m glad you were able to find the issue with the plugin. That’s the kind of stuff that’s really hard to guess/debug from the outside.