Lightbox not showing up on uploaded images after update

支持 安装
1

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?

1 个赞
2

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.

image
image.png1165×360 22.6 KB

3

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

Screenshot_20171029-182743
Screenshot_20171029-182743.png1080×1920 215 KB

4

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

2 个赞
5

Thanks, job done :+1:

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 :smiley:

6 个赞
6

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

6 个赞
7

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
8

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?

9

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;
    }
}
10

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.

11

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…

12

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? :blush:

1 个赞
13

我遇到了同样的问题。

无法访问 '/uploads/default/original/1X/fe2af548af4a22f4802ddaa54afa557ae557417c.png' 以获取其尺寸。

我可以从外部访问该图片，但在 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
正在解析 dis.domain.com (dis.domain.com)... 172.20.0.6
正在连接 dis.domain.com (dis.domain.com)|172.20.0.6|:443... 失败：连接被拒绝。

Docker 镜像内部的 DNS 指向了 Docker 网络中的内部 IP 地址 172.20.0.6，而不是该域名实际设置的对外公网 IP 地址。

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

非权威应答：
Name:   dis.domain.com
Address: 172.20.0.6

这是否是预期的行为？
我该怎么做才能将其更改为解析为其常规的公网 IP 地址？

14

我发现我将 app.yml 重命名为 domain.name.yml，这导致 Docker 将 domain.name 的 DNS 名称更改为其内部 IP 地址。我现在已将其重命名为 domain_name.yml，一切运行正常。

2 个赞
15

或许可以检查一下文件的相关设置。图片也有相应的配置项。请检查帖子中图片缩略图的最大宽度和高度设置。如果图片尺寸小于该设置值，则用户在帖子中无法点击该图片。

1 个赞