Lightbox not showing up on uploaded images after update

(Gwil Noble) #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?

(Joshua Rosenfeld) #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.png1165x360 22.6 KB

(Glynhudson) #3

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

Screenshot_20171029-182743
Screenshot_20171029-182743.png1080x1920 215 KB

(Joshua Rosenfeld) #4

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

(Glynhudson) #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:

(Jeff Atwood) #6

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

(RaVoR) #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
(Joshua Rosenfeld) #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?

(RaVoR) #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;
    }
}
Our discourse Images are not lightboxed
(Joshua Rosenfeld) #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.

(RaVoR) #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…

(RaVoR) #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: