@ben I have run into a problem where the CMS is not displaying images when deployed on the server. This is only happening for some images, and others, like in the blog, are working just fine. The big difference is that the blog images are remote, and the missing ones are in resources.
This all works perfectly in preview, just not in the real world. I have checked the paths to the image files, and they are all correct. I did try moving one of them to be remote to see if that made a difference, but it did not seem to.
Here is a link to the page where this is happening.
Don’t go switching to remote images just yet… it really sounds like the path you’re entering is incorrect… I looked at that page and most of the resources don’t resolve correctly and look like they are warehoused URL’s with missing images:
All the other data is being extracted, no problems. In preview, the ones in the resources work fine, but not on the server. The remote ones, only a couple of them show up. Very weird indeed.
NOTE: only the first section of dimensions are remote, all of the others are in resources.
Okay, I’ve tried to link to the resource that should be in your project and it doesn’t appear to be on the server. It’s late here, so I may be getting this wrong, but…
Do you have this resource in your project? /fin-thumbs/q2-thumbs/QB2-425-twin.webp like this:
I’ll go ahead and remove the “type” from the images. I see one problem here: some image titles have different cases than the front matter. I can now get the image that you are looking at to display. But I still can’t get some of the others in the first block to display.
@dan I think I have figured out what is going on here. It appears that you have image resources and they have all lowercase names, and you then use them in the front matter with mixed case. They will work fine in PREVIEW, but they won’t work on the server, of course.
Does this make sense? I went through and fixed some of them to have the cases all match, and now they show up.
@dan It seems that in Preview, they should also fail if the case does not match perfectly. I would never have known there was a problem until I was able to finally publish the page, as it always worked perfectly in Preview.
I regularly review all of this on the server, and that was how I figured it out.
@dan Does Elements automatically convert file names to lowercase when they are uploaded to the server?
I went back and reviewed my source images for all of these files that were creating problems, as I was not convinced I had made them with all lowercase. Sure enough, that is exactly what the problem was. All the files I initially placed in the resources were in mixed case, which is why the names were formatted that way in my front matter. But then when they got uploaded, they got converted to all lowercase, which of course broke things.
I conducted some tests by placing my mixed case files in the resources and then uploading them, and of course, they showed up on the server as all lowercase.
I thought I was losing my mind because I didn’t create these files with all lowercase, since the product names are uppercase, and I made them to match.
I did a final test with a whole folder of these thumbnails using my original images, which are mixed case. When they were uploaded, they all showed up as lowercase.
Why and how is that possible?
Is there a setting somewhere I’m missing?
Surely this should not happen, as the file name is critical and shouldn’t be changed out from underneath you.
Elements will lowercase resource filenames and do a bit of sanitisation on them if you’re using non-web safe characters. This is to ensure everything “just works” in the app.
However, now you are manually linking to resources you’ll need to spend a little more time ensuring they are correct.
I’ll get something added to the manual to let users know this is the case.
Wow, that is a bummer, never realized it did this. This means I’m going to have to switch to using remote resources everywhere I don’t want the filenames changed. I have already done with the files that have been causing the problems. Fortunately, I mirror the resources in my local storage, so I could easily get things back the way I want them.
I understand this is annoying for you, but I would recommend switching all your resource files to be lowercase.
Many web servers (Linux/Unix based) treat File.jpg and file.jpg as two different files. However, on Windows or macOS (i.e. Elements), the filesystem often isn’t case-sensitive, so it looks fine locally, but when uploaded, it can cause broken links and 404 errors (as we found out).
By using lowercase files, you’ll ensure they will ALWAYS work on different environments (Windows, Linux, macOS), this could be important if you ever move hosting companies.
@dan I hear what you are saying, but that is easier said than done. Some of these file names are significant in their naming conventions, and it will be excruciating to have to switch them. I already follow all lowercase with resources like icons and logos. But for these product files, it will be hard to justify.
For now, I’m going to stick with handling them remotely as I can easily deal with getting them onto my server.
This is compounded with the introduction of the CMS, because I copy the file names from the resources to use in the MD files, but now I can’t rely on that approach, as the file name in resources could be different from what is on the server.
