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?

OpenEnergyMonitor 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]

저도 동일한 문제를 겪고 있습니다.

Can't reach '/uploads/default/original/1X/fe2af548af4a22f4802ddaa54afa557ae557417c.png' to get its dimension.

외부에서는 해당 이미지를 접근할 수 있지만, 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
Resolving dis.domain.com (dis.domain.com)... 172.20.0.6
Connecting to dis.domain.com (dis.domain.com)|172.20.0.6|:443... failed: Connection refused.

Docker 이미지 내부의 DNS는 도메인이 실제로 설정되어 있는 외부 공개 IP 주소가 아니라 Docker 네트워크의 내부 IP 주소인 172.20.0.6으로 가리키고 있습니다.

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

Non-authoritative answer:
Name:   dis.domain.com
Address: 172.20.0.6

이것이 정상적인 동작 방식인가요?
정규적인 공개 IP 주소로 해석되도록 변경하려면 어떻게 해야 하나요?

[Michael_Uray]

app.yml 파일을 domain.name.yml로 이름 변경했더니, Docker가 domain.name의 DNS 이름을 내부 IP 주소로 변경하는 문제가 발생했음을 발견했습니다. 이제 파일 이름을 domain_name.yml로 다시 변경했는데, 모든 것이 정상적으로 작동하고 있습니다.

[Daisyliu6]

파일 설정을 확인해 보세요. 이미지 관련 설정이 몇 가지 있습니다. 게시글 내 이미지 섬네일의 최대 너비와 높이를 확인해 보세요. 이미지가 해당 크기 설정보다 작으면, 게시글에서 사용자가 클릭할 수 없습니다.