Lightbox not showing up on uploaded images after update

[SlyRemarks (Gwil OpenEnergyMonitor)]

After the latest update (1.9.0.beta13), our Discourse isn’t displaying images with the lightbox feature (as detailed here); there is no black bar appearing beneath when highlighted. Older images are still showing the lightbox, but newer uploads, either dragged-and-dropped or via the upload menu, are not showing it.

I noticed in the recent update there was a commit called - FIX: images aren’t lightboxed anymore (partially reverts 646c6eb). I’m not sure if this is related to what we’re seeing.

Does anyone know anything about this or has seen anything similar happen?

[jomaxro (Joshua Rosenfeld)]

It depends on the exact version you’re on. If you updated to beta13 shortly after its release, you’re likely affected by the bug, and don’t have the fix. Try visiting /admin/upgrade manually and see what commit you’re on. Click the commit number on the left, and see if the fix is in the list of commits shown. If it is, you need to update to get the fix.

[glynhudson]

Thanks, yes we’re on 69920b7. Shall I update to latest version?

Community

[jomaxro (Joshua Rosenfeld)]

Yes, the fix is 3 commits newer than the one you’re on. You’ll need to upgrade to get the fix.

[glynhudson]

Thanks, job done

I wasn’t able to update via the interface, button was grayed out so I did a manual update:

cd /var/discourse
git pull
sudo ./launcher rebuild app

Thanks a lot for your help. Is there any way to donate a contribution to Discourse? You guys do such amazing work. We have really enjoyed using Discourse

[codinghorror (Jeff Atwood)]

Hey thanks!! The best way to give back is to help us spread the word about Discourse!

[ravor-org (RaVoR)]

I do have the same problem in my internal discourse instance (running on our own virtualized photonOS+Docker). Any hints you could give to locate the fault? Lightbox is not appearing no matter how I get the picture/image into the post. System was updated today to latest revision although lightbox did never really work.

I’m running the following plugins:

- git clone https://github.com/discourse/docker_manager.git
- git clone https://github.com/discourse/discourse-tagging.git
- git clone https://github.com/discourse/discourse-push-notifications.git
- git clone https://github.com/angusmcleod/discourse-question-answer.git
- git clone https://github.com/discourse/discourse-spoiler-alert.git
- git clone https://github.com/angusmcleod/discourse-events.git
- git clone https://github.com/discourse/discourse-tooltips.git
- git clone https://github.com/discourse/discourse-voting.git
- git clone https://github.com/cpradio/discourse-plugin-checklist.git
- git clone https://github.com/davidtaylorhq/discourse-whos-online.git

[jomaxro (Joshua Rosenfeld)]

If you’re already up to date, my first suggestion would be to try Safe Mode. Do lightboxes work if you disable all CSS and plugins.

Next, is access to your site through a proxy, or do you have an out NGINX or Apache system?

[ravor-org (RaVoR)]

Thanks for the suggestion. Safe-mode did not work out, Lightbox is still not working.

We indeed have a outer nginx-proxy that is forwarding HTTPS-traffic to the nginx located within the discourse-container (also configured for https). Could that be an issue? If yes, what could be the deal?

server {
    listen 443 ssl http2;
    server_name ###mydomain####;

    client_header_timeout 5;
    #client_body_timeout 15;
    client_max_body_size 300m;

    include /opt/nginx/conf/ssl.params;

    proxy_http_version 1.1;
    #proxy_connect_timeout 20;
    proxy_read_timeout 360;
    proxy_pass_header Date;
    proxy_pass_header Server;
    proxy_pass_header Authorization;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For  $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto https;
    proxy_pass_request_headers on;
    proxy_set_header Accept-Encoding "";
    proxy_buffering off;
    proxy_set_header Connection "Keep-Alive";

    location / {
            proxy_pass https://##internalip###;
            proxy_redirect off;
    }
}

[jomaxro (Joshua Rosenfeld)]

I’m not an NGINX expert so I can’t suggest what’s wrong, but I’d assume with pretty high certainty that the proxy has something to do with the issue.

[ravor-org (RaVoR)]

I’ve found this while having eye on the logs:

Can't reach '/uploads/default/original/1X/858595dc6bfc7699863bfbc35222524c211399c5.png' to get its dimension.
Can't reach '/uploads/default/original/1X/810915fdc059422dfc5337934d2c6b1a9ceef6e0.png' to get its dimension.

So I guess there’s something wrong with uploading the images?

Edit: For sake of completeness: Images are accessible if i just append the path to my domain-name and I do get the full image…

[ravor-org (RaVoR)]

I’ve just moved my docker image from a dedicated server to the outer proxy. The outer nginx is now connecting through sockets instead of forwarding https. Problem still persists. I’m still receiving errors like this (which seem to be issue):

Can't reach '/uploads/default/original/1X/988629194890bf9b48b914c8fe910e15c4ac1d27.jpg' to get its dimension.

The images are valid and accessible, so whats creating the issue here?

EDIT: I’ve dug a little deeper and added some debugging to get_size within the lib/cooked_post_processor.rb and found that this method is acquiring the images by http(s) instead of grabbing it directly from the filesystem. There was an DNS-misconfiguration within our DMZ-setup, so the FastImage lib could not access the files.

Could you extend lib/cooked_post_processor.rb to use the filesystem instead of http(s) if no external location (such as Amazon S3) is used? For my understanding it doesn’t make sense to download the image if it’s already stored on the server already?

[Michael_Uray]

Sto riscontrando lo stesso problema.

Impossibile raggiungere '/uploads/default/original/1X/fe2af548af4a22f4802ddaa54afa557ae557417c.png' per ottenere le sue dimensioni.

Posso accedere all’immagine dall’esterno, ma non all’interno dell’immagine Docker.

root@dk1-dis:/shared/log/rails# wget https://dis.domain.com/uploads/default/original/1X/b2ef855c010c044aee13177269baaa36453c6193.png
--2020-07-04 14:53:33--  https://dis.domain.com/uploads/default/original/1X/b2ef855c010c044aee13177269baaa36453c6193.png
Risoluzione di dis.domain.com (dis.domain.com)... 172.20.0.6
Connessione a dis.domain.com (dis.domain.com)|172.20.0.6|:443... fallita: Connessione rifiutata.

Il DNS all’interno dell’immagine Docker punta al suo indirizzo IP interno 172.20.0.6 della rete Docker e non al suo indirizzo IP pubblico esterno per cui il dominio è effettivamente configurato.

root@dk1-dis:/shared/log/rails# nslookup dis.domain.com
Server:         127.0.0.11
Address:        127.0.0.11#53

Risposta non autorevole:
Name:   dis.domain.com
Address: 172.20.0.6

È questo il comportamento previsto?
Cosa posso fare per modificarlo in modo che venga risolto con il suo regolare indirizzo IP pubblico?

[Michael_Uray]

Ho scoperto di aver rinominato app.yml in domain.name.yml, il che ha causato a Docker di modificare il nome DNS di domain.name nel suo indirizzo IP interno. Ora l’ho rinominato in domain_name.yml e tutto funziona correttamente.

[Daisyliu6]

Forse controlla le impostazioni per i file. Ci sono alcune impostazioni per le immagini. Verifica la larghezza e l’altezza massime delle miniature delle immagini in un post. Se le immagini sono più piccole di quelle impostazioni, nell’post l’utente non potrà cliccarci sopra.