No problem. I wish I could help you more, but unfortunately, I do not have enough knowledge on the subject. Hopefully someone that knows more will respond soon. I would also watch the topic that I linked to. It might eventually have a solution posted.
In the mean time, you might want to take a look at your logs and see if there are similarities to the logs posted in that topic. Iβm pretty sure the logs you would be interested in can be found by adding /logs to your forumβs base URL. So it would look something like https://example.com/logs The user in that topic also mentions a proxy. Are you using a proxy?
If you can provide this type of information, it should be helpful to someone that reads this topic and has a better understanding on the subject.
Weβd prefer if you could upload to try first (try.discourse.org), that way we donβt start getting image uploads all over the place. If the image fails to lightbox on try, then feel free to upload it here so the example doesnβt get deleted when try is reset each day. If the image lightboxes on try then the issue is specific to your configuration as @schungx stated.
I have the version 2.5.0.beta6 running and I experience the same issue.
βcreate thumbnailsβ is active, but it does not create a lightbox, independent of the size of the picture.
I have a second instance of discourse which is a couple month old and there I have old posts where the lightbox works, but not on the new posts.
Maybe an issue with an update?
If I upload the same picture to try.discourse.org, then it works there fine with the lightbox.
This suggests thereβs an issue in your setup somewhere. Can you please check your browser console for errors or post a link to the site youβre having trouble with?
I just created there a test thread on a new discourse instance which I did setup last week.
The image is 1920x1050, but it does not open in a lightbox. https://dis.ctb.co.at/t/test-image-lightbox/44
On the second installation on which the lightbox was working before was the path at first β/var/dockerβ and I changed it later to another location.
Could be that the lightbox problem started then by the path change. - Not sure about it.
Did I maybe miss any setting for the new path?
These lines above were the only lines I found which pointed to the original directory β/var/dockerβ.
I just tried to move it back to β/var/discourseβ to confirm it is the path change which caused it, but it is the same issue there with the original path.
It further runs behind a nginx reverse proxy which does the SSL encryption if this matters, but I have not changed anything in the configuration there since it stopped working on the other installation.
I have done these settings for nginx in the according .yml file.
If it is not the path, what else could cause this lightbox issue?
I moved it back to β/var/docker/dis.ctb.co.atβ.
This is my current yml configuration (only changed personal data). Could be something wrong there, or is this a Discourse issue?
## 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
##
## BE *VERY* CAREFUL WHEN EDITING!
## YAML FILES ARE SUPER SUPER SENSITIVE TO MISTAKES IN WHITESPACE OR ALIGNMENT!
## visit http://www.yamllint.com/ to validate this file as needed
templates:
- "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 https://meta.discourse.org/t/17247 for details
expose:
# - "80:80" # http
# - "443:443" # https
- "127.0.0.1:3041:80"
docker_args:
- "--network=nginx-br"
params:
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: "4096MB"
## 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
env:
LANG: en_US.UTF-8
# DISCOURSE_DEFAULT_LOCALE: en
## 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
UNICORN_WORKERS: 8
## TODO: The domain name this Discourse instance will respond to
## Required. Discourse will not work with a bare IP number.
DISCOURSE_HOSTNAME: dis.ctb.co.at
## Uncomment if you want the container to be started with the same
## hostname (-h option) as specified above (default "$hostname-$config")
#DOCKER_USE_HOSTNAME: true
## TODO: List of comma delimited emails that will be made admin and developer
## on initial signup example 'user1@example.com,user2@example.com'
DISCOURSE_DEVELOPER_EMAILS: 'nothing@nothing.com'
## 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_ADDRESS: mailserver.nothing.com
DISCOURSE_SMTP_PORT: 25
DISCOURSE_SMTP_USER_NAME: nothing@nothing.com
DISCOURSE_SMTP_PASSWORD: "secret"
DISCOURSE_SMTP_ENABLE_START_TLS: false # (optional, default true)
DISCOURSE_SMTP_OPENSSL_VERIFY_MODE: none
## If you added the Lets Encrypt template, uncomment below to get a free SSL certificate
# LETSENCRYPT_ACCOUNT_EMAIL: me@example.com
## The http or https CDN address for this Discourse instance (configured to pull)
## see https://meta.discourse.org/t/14857 for details
#DISCOURSE_CDN_URL: https://discourse-cdn.example.com
VIRTUAL_HOST: dis.ctb.co.at
VIRTUAL_PORT: 9002
LETSENCRYPT_HOST: dis.ctb.co.at
LETSENCRYPT_EMAIL: nothing@nothing.com
## The Docker container is stateless; all data is stored in /shared
volumes:
- volume:
host: /var/docker/dis.ctb.co.at/shared/standalone
guest: /shared
- volume:
host: /var/docker/dis.ctb.co.at/shared/standalone/log/var-log
guest: /var/log
## Plugins go here
## see https://meta.discourse.org/t/19157 for details
hooks:
after_code:
- exec:
cd: $home/plugins
cmd:
- git clone https://github.com/discourse/docker_manager.git
## Any custom commands to run after building
run:
- 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='info@unconfigured.discourse.org'"
- exec: echo "End of custom commands"
- replace:
filename: /etc/nginx/conf.d/discourse.conf
from: "types {"
to: |
set_real_ip_from 172.18.0.0/16;
real_ip_header X-Forwarded-For;
real_ip_recursive on;
types {
I fiured now out, that this only happens if Force your site to use HTTPS only is set active when the post with the image gets created.
I had that active on the other installation since the beginn, but it suddenly stopped working, maybe caused by an update of nginx or Discourse.
nginx does not show any strange things so far as I can see.
Usually this is due to misconfiguration of complex reverse proxy schemes in my experience. Subfolder adds additional complexity (and thus variables) as well.
I am running two seperate Discourse installations via this nginx proxy as well as a nextcloud instance. At the first Discourse installation the lightbox was working before and then it suddenly stopped. I actually did not change anything on the proxy configuration since it was working.
It interestingly still creates some files and folders in /var/discourse, even if I have set the volumes not to this directory.
It never happend that files were created in /var/discourse, maybe I have seen some old files.
I changed now from nginx to traefik to make sure that the problem comes not from nginx, but the issue is still present. Means to me that there is probably a problem on the Discourse side and not on the proxy side.
Same situation with traefik, if βhttps forcedβ is disabled when the image gets posted, then the lightbox works fine, even if I enable βhttps forcedβ later.
What else could I check?
It shows me an error in the log file, that it cannot access /uploads/....
Can't reach '/uploads/default/original/1X/fe2af548af4a22f4802ddaa54afa557ae557417c.png' to get its dimension.
I can access the image woithout problems if I enter the url into a webbrowser: https://domain.com/uploads/default/original/1X/fe2af548af4a22f4802ddaa54afa557ae557417c.png
Completed 200 OK in 23ms (Views: 0.3ms | ActiveRecord: 0.0ms | Allocations: 3000)
Completed 200 OK in 318ms (Views: 1.2ms | ActiveRecord: 0.0ms | Allocations: 50347)
Can't reach '/uploads/default/original/1X/fe2af548af4a22f4802ddaa54afa557ae557417c.png' to get its dimension.
Started GET "/posts/96" for 84.115.50.36 at 2020-07-04 14:15:14 +0000
Processing by PostsController#show as JSON
Parameters: {"id"=>"96"}
It shows me no error with https not forced.
Completed 200 OK in 18ms (Views: 0.3ms | ActiveRecord: 0.0ms | Allocations: 3050)
Completed 200 OK in 296ms (Views: 0.5ms | ActiveRecord: 0.0ms | Allocations: 49562)
Started GET "/posts/97" for 84.115.50.36 at 2020-07-04 14:17:43 +0000
Processing by PostsController#show as JSON
Parameters: {"id"=>"97"}
It looks to me as if Discourse downloads for some reason the image again from the webserver to do some lightbox stuff with it.
If i download this image manually within the Discourse Docker container, then it tries to access its webserver directly via its internal IP address instead if accessing it via the proxy. This works via http, but not via https.
The webserver itself has only http available, but it tries to access it via https what then fails.
I am wondering why does Discourse downloads the picture again from its webserver instead of accessing it internaly without http/https.
Edit: I found out, that I renamed the app.yml with domain.name.yml and this caused docker to change the DNS name of domain.name to its internal IP address. I renamed it to domain_name.yml and everything is working fine now.