Broken images in popular browsers

For normal operation I use a non-standard browser called qutebrowser on Linux. qutebrowser shows image cards on my self-hosted docker-compose Ghost 5.31.0 service correctly. I have one Page that has a few images uploaded. However, every other browser I’ve tried shows broken images on this Page, but as far as I can tell the image addresses are the same for every browser. This Page is members-only, but has a Public Preview (all the images are above the Public Preview card). I’ve only been browsing as a public user (haven’t logged in as a member yet).

I’ve tried Google Chrome, Vivaldi, and Firefox on Linux, and they all show the broken images instead of the images attached to the Page. Firefox appears to show the correct dimensions of each image, but the picture inside the box is empty. Chrome and Vivaldi have the
broken image icon. Chrome on my Android phone also shows the broken image on this page.

For normal operation I use qutebrowser, a browser based on QtWebEngine (which has roots in Chromium). Up until recently qutebrowser worked just fine for, but this site now says it’s out of date (this site should let the user handle out of date browsers, and shouldn’t totally break if it detects something too old). But that is not my problem for this topic.

Are you maybe running into an http vs https problem for those images?

If you open developer tools (F12 in Chrome and some others) and look in the console for error messages and at the network tab for the requests that should get those images, what do you see?

Can you share a URL? Most likely, the modern browsers take a strict approach to misconfiguration, e.g., cross-site, mixed URLs etc.

Unfortunately the page I’m trying to post to contains PII, I’m not ready to publicly share it yet. But as Cathy suggested, I loaded developer tools in each browser, and in the broken browsers the images are getting 404 response codes, sure enough. I’m at a loss to explain why.

Also in developer tools, I copied the URL for each browser, and as far as I can tell the URLs for each image are identical:


So, it doesn’t appear to be an http versus https problem. If it’s not obvious, I replaced the actual domain name with, and the redacted.jpg is hiding the individual’s name (these are portraits of my organization’s officers).

For the broken browsers, can you try incognito to make sure there are no caches or extensions interfering with the page functionality?

I think I figured it out. I had actually broken it through my docker-compose service. I was trying to find the editable config.production.json, and originally it wasn’t exposed in the Docker host volume. Originally the host volume for /data/nginx/www/ had the container path of /var/lib/ghost/content. Since config.production.json isn’t available in the host directory that way, I copied everything in /var/lib/ghost within the container, to /data/nginx/www/ That seemed to be working, but I ran into a problem upgrading to Ghost 5.32.0 (the latest version on Docker Hub).

Previous to this move, all I had to do was update the version of Ghost in my .env, and a docker-compose up -d would download and rebuild my containers with the latest version. After this move this upgrade didn’t work for the service, so I put things back the way they were supposed to be.

Once I returned to a supported configuration, the images at least in Vivaldi started working, no more 404s. I checked in Chromium, Chrome, and Firefox, and all is well.

So weird that it didn’t break it in qutebrowser, but I’ll take it!

EDIT: I discovered how I can set up config.production.json for my docker-compose service, just recreate the JSON structure in YAML variables:

mail__transport:  "SMTP"
mail__options__service:  "Google"
mail__options__host:  ${GMAIL_HOST}
mail__options__port:  ${GMAIL_PORT}
mail__options__auth__user:  ${GMAIL_USER}
mail__options__auth__pass:  ${GMAIL_PASS}

In case anyone tries to do what I tried.