Could someone help me to get the image lightboxing working.
I uploaded a image. image resolution is 1772 x 2362.
But Images are without thumbnails and without lightboxes.
I checked create thumbnails option.
Settings part: File > create thumbnails
My Discourse is on private network. But we opened the firewall to connect from the outside.
Version is v2.0.0.beta5+12.
What is the problem?
Possibly related:
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.
I wish you luck in solving the problem!
thank you tshenry.
our discourse is not using proxy and https.
I still do not know the cause of the problem. 
Thank you. ^^
First thing first. If possible, upload that image to meta here. See if it works.
If it doesn’t work in meta, then it is much easier for the team to fix as there is their repo right here.
If it works in meta but not on your site, then there must be a setting conflict somewhere.
I can see that the image in your original post successfully lightboxes.
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.
Ich habe die Version 2.5.0.beta6 ausgeführt und erlebe dasselbe Problem. „Miniaturansichten erstellen
Hey und willkommen bei Meta @Michael_Uray 
Das deutet darauf hin, dass irgendwo in deiner Einrichtung ein Problem besteht. Könntest du bitte die Browserkonsole auf Fehler überprüfen oder einen Link zur Seite posten, bei der du Schwierigkeiten hast?
Ich habe gerade dort einen Test-Thread auf einer neuen Discourse-Instanz erstellt, die ich letzte Woche eingerichtet habe.
Das Bild hat eine Auflösung von 1920x1050, wird aber nicht in einer Lightbox geöffnet.
https://dis.ctb.co.at/t/test-image-lightbox/44
Danke für den Link, Michael 
Ich sehe auf dieser Seite keine JavaScript-Fehler. Könntest du bitte prüfen, ob es Probleme in Sidekiq gibt?
your.site.com/sidekiq
Insbesondere diese Registerkarten
Könntest du bitte auch bestätigen, dass du beim Einrichten deiner Seite den offiziellen Leitfaden befolgt hast?
Bisher sind mir keine Probleme aufgefallen.
Ich habe diesen Leitfaden tatsächlich befolgt, habe jedoch den Pfad geändert und diese Änderungen in der Datei app.yml angepasst.
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
Bei der zweiten Installation, bei der das Lightbox-Feature zuvor funktionierte, lag der Pfad zunächst bei „/var/docker
Ich habe gerade versucht, es zurück nach “/var/discourse” zu verschieben, um zu bestätigen, dass die Pfadänderung die Ursache war, aber das Problem tritt auch am ursprünglichen Pfad auf.
Es läuft zudem hinter einem Nginx-Reverse-Proxy, der die SSL-Verschlüsselung übernimmt, falls dies relevant ist. Ich habe jedoch seit dem Ausfall der anderen Installation keine Änderungen an der Konfiguration dort vorgenommen.
Ich habe diese Einstellungen für Nginx in der entsprechenden .yml-Datei vorgenommen.
- 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 {
Wenn es nicht der Pfad ist, was könnte sonst dieses Lightbox-Problem verursachen?
Ich habe es zurück nach “/var/docker/dis.ctb.co.at” verschoben.
Dies ist meine aktuelle YML-Konfiguration (nur persönliche Daten wurden geändert). Könnte dort etwas falsch sein, oder ist das ein Discourse-Problem?
## Dies ist die All-in-One, eigenständige Discourse Docker-Container-Vorlage
##
## Nach Änderungen an dieser Datei MUSST du neu aufbauen
## /var/discourse/launcher rebuild app
##
## SEHR VORSICHTIG BEIM BEARBEITEN!
## YAML-DATEIEN SIND SUPER SUPER EMPFINDLICH GEGENÜBER FEHLERN IN LEERZEICHEN ODER AUSRICHTUNG!
## Besuche http://www.yamllint.com/, um diese Datei bei Bedarf zu validieren
templates:
- "templates/postgres.template.yml"
- "templates/redis.template.yml"
- "templates/web.template.yml"
- "templates/web.ratelimited.template.yml"
## Kommentiere diese beiden Zeilen aus, wenn du Lets Encrypt (https) hinzufügen möchtest
# - "templates/web.ssl.template.yml"
# - "templates/web.letsencrypt.ssl.template.yml"
## Welche TCP/IP-Ports soll dieser Container freigeben?
## Wenn du möchtest, dass Discourse einen Port mit einem anderen Webserver wie Apache oder nginx teilt,
## siehe https://meta.discourse.org/t/17247 für 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"
## Setze db_shared_buffers auf maximal 25 % des gesamten Arbeitsspeichers.
## Wird automatisch durch Bootstrap basierend auf dem erkannten RAM gesetzt, oder du kannst es überschreiben
db_shared_buffers: "4096MB"
## Kann die Sortierleistung verbessern, erhöht aber den Speicherverbrauch pro Verbindung
#db_work_mem: "40MB"
## Welche Git-Revision soll dieser Container verwenden? (Standard: tests-passed)
#version: tests-passed
env:
LANG: en_US.UTF-8
# DISCOURSE_DEFAULT_LOCALE: en
## Wie viele gleichzeitige Webanfragen werden unterstützt? Hängt vom Arbeitsspeicher und den CPU-Kernen ab.
## Wird automatisch durch Bootstrap basierend auf den erkannten CPUs gesetzt, oder du kannst es überschreiben
UNICORN_WORKERS: 8
## TODO: Der Domainname, auf den diese Discourse-Instanz antwortet
## Erforderlich. Discourse funktioniert nicht mit einer reinen IP-Nummer.
DISCOURSE_HOSTNAME: dis.ctb.co.at
## Kommentiere aus, wenn du möchtest, dass der Container mit demselben
## Hostnamen (-h-Option) wie oben angegeben gestartet wird (Standard: "$hostname-$config")
#DOCKER_USE_HOSTNAME: true
## TODO: Liste der durch Komma getrennten E-Mail-Adressen, die bei der ersten Anmeldung als Admin und Entwickler eingerichtet werden
## Beispiel: 'user1@example.com,user2@example.com'
DISCOURSE_DEVELOPER_EMAILS: 'nothing@nothing.com'
## TODO: Der SMTP-Mailserver, der zur Validierung neuer Konten und zum Senden von Benachrichtigungen verwendet wird
# SMTP-Adresse, Benutzername und Passwort sind erforderlich
# WARNUNG: Das Zeichen '#' im SMTP-Passwort kann Probleme verursachen!
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, Standard: true)
DISCOURSE_SMTP_OPENSSL_VERIFY_MODE: none
## Wenn du die Lets Encrypt-Vorlage hinzugefügt hast, kommentiere unten aus, um ein kostenloses SSL-Zertifikat zu erhalten
# LETSENCRYPT_ACCOUNT_EMAIL: me@example.com
## Die http- oder https-CDN-Adresse für diese Discourse-Instanz (konfiguriert zum Abrufen)
## siehe https://meta.discourse.org/t/14857 für 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
## Der Docker-Container ist zustandslos; alle Daten werden in /shared gespeichert
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 gehen hier hinein
## siehe https://meta.discourse.org/t/19157 für Details
hooks:
after_code:
- exec:
cd: $home/plugins
cmd:
- git clone https://github.com/discourse/docker_manager.git
## Beliebige benutzerdefinierte Befehle, die nach dem Erstellen ausgeführt werden sollen
run:
- exec: echo "Beginn der benutzerdefinierten Befehle"
## Wenn du die 'From'-E-Mail-Adresse für deine erste Registrierung festlegen möchtest, kommentiere aus und ändere:
## Nach Erhalt der ersten Anmelde-E-Mail diesen Kommentar wieder entfernen. Es muss nur einmal ausgeführt werden.
#- exec: rails r "SiteSetting.notification_email='info@unconfigured.discourse.org'"
- exec: echo "Ende der benutzerdefinierten Befehle"
- 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 {
Ich habe jetzt herausgefunden, dass dies nur auftritt, wenn die Option „Deine Seite ausschließlich über HTTPS verwenden erzwingen
In der Regel liegt das meiner Erfahrung nach an einer fehlerhaften Konfiguration komplexer Reverse-Proxy-Schemata. Die Verwendung eines Unterordners erhöht die Komplexität (und damit die Anzahl der Variablen) zusätzlich.
Hmm, was könnte dann mit meiner nginx-Proxy-Konfiguration falsch sein?
version: '3'
services:
nginx:
image: jwilder/nginx-proxy:alpine
labels:
- "com.github.jrcs.letsencrypt_nginx_proxy_companion.nginx_proxy=true"
container_name: nginx
networks:
- nginx_nw
ports:
- 80:80
- 443:443
volumes:
- ./data/conf.d:/etc/nginx/conf.d:rw
- ./data/vhost.d:/etc/nginx/vhost.d:rw
- ./data/html:/usr/share/nginx/html:rw
- ./data/certs:/etc/nginx/certs:ro
- /etc/localtime:/etc/localtime:ro
- /var/run/docker.sock:/tmp/docker.sock:ro
restart: unless-stopped
letsencrypt:
image: jrcs/letsencrypt-nginx-proxy-companion
container_name: letsencrypt
depends_on:
- nginx
networks:
- nginx_nw
volumes:
- ./data/certs:/etc/nginx/certs:rw
- ./data/vhost.d:/etc/nginx/vhost.d:rw
- ./data/html:/usr/share/nginx/html:rw
- /etc/localtime:/etc/localtime:ro
- /var/run/docker.sock:/var/run/docker.sock:ro
restart: unless-stopped
networks:
nginx_nw:
external:
name: nginx-br
Ich betreibe zwei separate Discourse-Installationen über diesen nginx-Proxy sowie eine Nextcloud-Instanz. Bei der ersten Discourse-Installation funktionierte die Lightbox zuvor und hat dann plötzlich aufgehört zu funktionieren. Tatsächlich habe ich an der Proxy-Konfiguration seit der Funktionsfähigkeit nichts geändert.
Interessanterweise werden weiterhin einige Dateien und Ordner in /var/discourse erstellt, obwohl ich die Volumes nicht auf dieses Verzeichnis gesetzt habe.
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
Ich vermute also, dass es irgendwo ein Problem mit dem Speicherort des Ordners gibt.
root@dk1:/var/discourse# tree -d
.
└── shared
└── standalone
├── backups
├── log
│ ├── rails
│ └── var-log
│ ├── nginx
│ ├── postgres
│ └── redis
├── postgres_backup
├── postgres_data
│ ├── base
│ │ ├── 1
│ │ ├── 14049
│ │ ├── 14050
│ │ └── 16384
│ ├── global
│ ├── pg_commit_ts
│ ├── pg_dynshmem
│ ├── pg_logical
│ │ ├── mappings
│ │ └── snapshots
│ ├── pg_multixact
│ │ ├── members
│ │ └── offsets
│ ├── pg_notify
│ ├── pg_replslot
│ ├── pg_serial
│ ├── pg_snapshots
│ ├── pg_stat
│ ├── pg_stat_tmp
│ ├── pg_subtrans
│ ├── pg_tblspc
│ ├── pg_twophase
│ ├── pg_wal
│ │ └── archive_status
│ └── pg_xact
├── postgres_run
│ └── 12-main.pg_stat_tmp
├── redis_data
├── state
│ ├── anacron-spool
│ └── logrotate
├── tmp
│ ├── backups
│ └── restores
└── uploads
└── default
├── optimized
│ └── 1X
└── original
└── 1X
52 directories
Habe ich vielleicht eine Einstellung für den neuen Ordnerspeicherort übersehen?
Es ist noch nie vorgekommen, dass Dateien in /var/discourse erstellt wurden. Vielleicht habe ich einige alte Dateien gesehen.
Ich habe nun von nginx auf traefik umgestellt, um sicherzustellen, dass das Problem nicht von nginx stammt, aber das Problem besteht weiterhin. Das bedeutet für mich, dass das Problem wahrscheinlich auf der Discourse-Seite und nicht auf der Proxy-Seite liegt.
Bei traefik ist die Situation ähnlich: Wenn „HTTPS erzwingen
Es wird mir ein Fehler in der Protokolldatei angezeigt, dass auf /uploads/.... nicht zugegriffen werden kann.
Can't reach '/uploads/default/original/1X/fe2af548af4a22f4802ddaa54afa557ae557417c.png' to get its dimension.
Ich kann auf das Bild zugreifen, ohne Probleme, wenn ich die URL in einen Webbrowser eingebe:
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"}
Es wird mir kein Fehler angezeigt, wenn https nicht erzwungen wird.
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"}
Es sieht für mich so aus, als würde Discourse aus irgendeinem Grund das Bild erneut vom Webserver herunterladen, um damit Lightbox-Funktionen durchzuführen.
Wenn ich dieses Bild manuell innerhalb des Discourse Docker-Containers herunterlade, versucht es, direkt über seine interne IP-Adresse auf den Webserver zuzugreifen, anstatt über den Proxy. Dies funktioniert über http, aber nicht über https.
Der Webserver selbst bietet nur http an, versucht aber, über https darauf zuzugreifen, was dann fehlschlägt.
Ich frage mich, warum Discourse das Bild erneut vom Webserver herunterlädt, anstatt intern ohne http/https darauf zuzugreifen.
Edit: Ich habe herausgefunden, dass ich die app.yml in domain.name.yml umbenannt habe und dies dazu führte, dass Docker den DNS-Namen von domain.name in seine interne IP-Adresse änderte. Ich habe ihn in domain_name.yml umbenannt, und jetzt funktioniert alles einwandfrei.
Wenn die doppelten Punkte in der YML dafür verantwortlich sind, klingt das nach etwas, das im Launcher eine Warnung auslösen sollte?