Image lightbox not working in subfolder install


(Dave Sparks) #1

I see that some images on this forum have an image lightbox where you can click on an image thumbnail and view the original image. Is there an admin setting to enable this as it does not appear to be working on our forum? I couldn’t anything relevant when searching the settings or this forum.

See Getting Tag-Informations from BuildChangeset does not work - VSoft Technologies Forums. The first image is 1307x207 and the markup (which was automatically generated when pasting the image into the editor) is ![image|690x120](upload://dOXrmMRj5KCpDAg2GftoG5fZrMa.png). The original image is available If I right-click and open the image in a new tab but there is no light box available when I click on the image.

(Simon Cossar) #2

The setting is called ‘create thumbnails’. It is enabled by default. When enabled, it will create thumbnails and lightbox images that are too large to fit in a post.

(Dave Sparks) #3

The ‘create thumbnails’ setting is enabled. It appears to be creating thumbnails but not linking to a light box. We are running the latest version 2.2.0.beta4 +238

(Jeff Atwood) #4

This implies your Discourse is not set up correctly, primarily because the background sidekick tasks necessary to do the background image work are not running.

(Vincent) #5

I guess this could be related to our subfolder install :roll_eyes: (which is otherwise working very well).

If I navigate to /forums/sidekiq I just get forbidden.

This is our app,yml with the recommended mods for subfolder installation :

## this is the all-in-one, standalone Discourse Docker container template
## After making changes to this file, you MUST rebuild
## /var/discourse/launcher rebuild app
## visit to validate this file as needed

  - "templates/postgres.template.yml"
  - "templates/redis.template.yml"
  - "templates/web.template.yml"
  - "templates/web.ratelimited.template.yml"
## Uncomment these two lines if you wish to add Lets Encrypt (https)
##  - "templates/web.ssl.template.yml"
##  - "templates/web.letsencrypt.ssl.template.yml"

## which TCP/IP ports should this container expose?
## If you want Discourse to share a port with another webserver like Apache or nginx,
## see for details
  - "80:80"   # http
  - "443:443" # https
  - "5432:5432" #postgres

  db_default_text_search_config: "pg_catalog.english"

  ## Set db_shared_buffers to a max of 25% of the total memory.
  ## will be set automatically by bootstrap based on detected RAM, or you can override
  db_shared_buffers: "128MB"

  upload_size: 20m
  ## can improve sorting performance, but adds memory usage per-connection
  #db_work_mem: "40MB"

  ## Which Git revision should this container use? (default: tests-passed)
  #version: tests-passed

  LANG: en_US.UTF-8

  ## How many concurrent web requests are supported? Depends on memory and CPU cores.
  ## will be set automatically by bootstrap based on detected CPUs, or you can override

  ## TODO: The domain name this Discourse instance will respond to
  ## Required. Discourse will not work with a bare IP number.

  ## Uncomment if you want the container to be started with the same
  ## hostname (-h option) as specified above (default "$hostname-$config")

  ## TODO: List of comma delimited emails that will be made admin and developer
  ## on initial signup example ','

  ## TODO: The SMTP mail server used to validate new accounts and send notifications
  # SMTP ADDRESS, username, and password are required
  # WARNING the char '#' in SMTP password can cause problems!
  DISCOURSE_SMTP_ENABLE_START_TLS: true           # (optional, default true)

  ## If you added the Lets Encrypt template, uncomment below to get a free SSL certificate

  ## The CDN address for this Discourse instance (configured to pull)
  ## see for details

## The Docker container is stateless; all data is stored in /shared
  - volume:
      host: /var/discourse/shared/standalone
      guest: /shared
  - volume:
      host: /var/discourse/shared/standalone/log/var-log
      guest: /var/log

## Plugins go here
## see for details
    - exec:
        cd: $home/plugins
          - git clone
          - git clone
          - git clone

## Any custom commands to run after building
  - exec: echo "Beginning of custom commands"
  ## If you want to set the 'From' email address for your first registration, uncomment and change:
  ## After getting the first signup email, re-comment the line. It only needs to run once.
  #- exec: rails r "SiteSetting.notification_email=''"
  - exec:
      cd: $home
        - mkdir -p public/forums
        - cd public/forums && ln -s ../uploads && ln -s ../backups
  - replace:
      global: true
      filename: /etc/nginx/conf.d/discourse.conf
      from: proxy_pass http://discourse;
      to: |
        rewrite ^/(.*)$ /forums/$1 break;
        proxy_pass http://discourse;
  - replace:
      filename: /etc/nginx/conf.d/discourse.conf
      from: etag off;
      to: |
        etag off;
        location /forums {
            rewrite ^/forums/?(.*)$ /$1;
  - replace:
      filename: /etc/nginx/conf.d/discourse.conf
      from: $proxy_add_x_forwarded_for
      to: $http_x_real_ip
      global: true

  - exec: echo "End of custom commands"

(Joshua Rosenfeld) #6

Subfolder installs are notoriously difficult to configure. Hence the warning in the subfolder guide:

Best guess, something is not configured correctly with your proxy.

(Vincent) #7

Yes, yes, subfolder… I know (I spent a day getting it working). Surely if you are so against subfolders you would remove the guide and say absolutely not supported? It seems like it’s mostly there, so why wouldn’t you help resolve the issues as they are found and update the guide? In the end there would less topics like this, and more people using discourse.

I can navigate to /forums/logs ok, so I guessing something needs to change in the routing for sidekiq web?

Seeing this occurring a lot :

Job exception: Failed to open TCP connection to localhost:8080 (Cannot assign requested address - connect(2) for "localhost" port 8080)

I can confirm that sidekiq is running (and scheduled backups are still working).

(Stephen) #8

You’re talking about the fundamental difference between sharing information and offering best-effort support. One doesn’t mandate the other.

The choice to share information to get you started with something doesn’t create any onus or responsibility to support it. We’ve suggested several times that you’re choosing to walk an unnecessarily painful path, this is another of those pain points - it almost certainly won’t be the last.

In 2018 there’s no good reason to run subfolder, which you’ve heard from us previously, it’s not deterring anyone from deploying the software.

(Vincent) #9

@Stephen It just seems odd that each topic that has any info about subfolders get’s the standard “subfolders, world of hurt” type reply, when really there is usually something to be learned from the topic.

I also get that this is open source/free etc and we’re ‘on our own’ since we’re hosting it ourselves.

My recommendation would be to remove all references to subfolder installs, then no one will be enticed by a guide that looks doable at first glance.

(Stephen) #10

As @jomaxro already quoted, the support statement is right there in the #howto for #subfolder. I don’t think it needs to be hidden, it’s there for any hosted enterprise customers or sites willing to accept the likelihood for complications, which you did when you read the document and continued down that path with your install.

All your experience has really done is prove that point. The team are very honest about what Discourse can and can’t do, all of the recommendations are there to give would-be administrators and developers a chance to enjoy and succeed with the product.

For those who choose to go off the beaten track the odd ‘thar be dragons’ sign is erected. The thing about dragons is that for the right price someone is usually willing to assume the time and risk to come kill them.

(Dave Sparks) #11

Whatever you do don’t mention the subfolder! YouTube :slight_smile:

(Jay Pfaffman) #12

I won’t promise to have looked carefully at all of this, but Discourse should be on a non-standard port so that your external web server can do the reverse proxying. So I’m confused how it’s working at all. Can you really access other stuff on the server at, say

My suggestion was going to be to try to curl http://localhost:PORT/sidekiq to see if you could access sidekiq.

(Vincent) #13

@pfaffman Pretty much everything else is working, you can see it here at - website, forums etc all accessible. /forums is reverse proxied via IIS - you can see my config in this topic - Subfolder install - external links get changed/redirected to site relative links

If I access http://localhost/sidekiq in the container I get the standard this page is private or doesn’t exist response. If I try I just get ‘Forbiddden’. Not sure about the non standard port, haven’t seen that mentioned anywhere with regards to subfolder installs. I get the feeling this is an issue with the proxy not passing enough info for sidekiq to authenticate.

I’m going to have a go at setting up a dev environment over the next few days and see if I can figure out what is going on, but not being a ruby dev (mostly c# and typescript) I’m not sure how far I will get.

(Jay Pfaffman) #14

Are you logged in as admin?

(Vincent) #15

Yes, logged in as admin.

(Vincent) #16

I’m seeing something which may or may not be related.

As mentioned, this is a subfolder install,using SSO (which goes to the main site).

After logging in I see these cookies

  • _t path="/"
  • _forum_session path="/forums"

if I the navigate (logged in as an admin) to “/forums/sidekiq” (returns the text Forbidden and a 403 result)

I get extra cookies :

  • _forum_session path="/"
  • rack.session path="/"

Looking at the code, _forum_session cookie creation does take the relative path into account

So how am I ended up with another session with the root path? Anyway, putting this up here in case it proves useful info for someone. Still trying to figure out why I can’t access the sidekiq web interface (the intention being to see if there was any info on why the lightbox stuff isn’t working).

List of cookies used by Discourse
(Vincent) #17

Ok, got past the Sidekiq issue, I found this in the unicorn.stderr.log

WARN -- : attack prevented by Rack::Protection::IPSpoofing

which lead me to look at the IPSpoofing source code and figured out the problem was the HTTP_X_REAL_IP header I was forwarding… removed it and now I an access sidekiq.

Sidekiq appears to be running normally, but lightbox is still not working. Any other suggestions on where to look?

Edit (since I can’t post more than 3 consecutive replies!) :

Problem solved. I found the same error as this case

in our production logs, and he mentioned dns. DNS appeared to be working, however I had it as, on the host, I changed that around to,, and rebooted the host (restarting the container didn’t seem to help).

I have no idea why this change worked, as I could curl the image url in the container just fine, and dns appeared to be working.

(Dave Sparks) #18