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.
J’exécute la version 2.5.0.beta6 et je rencontre le même problème. « Créer des miniatures » est actif, mais aucune boîte légère (lightbox) n’est générée, quelle que soit la taille de l’image.
J’ai une deuxième instance de Discourse, âgée de quelques mois, où la boîte légère fonctionne sur d’anciens messages, mais pas sur les nouveaux. Peut-être s’agit-il d’un problème lié à une mise à jour ?
Si je télécharge la même image sur try.discourse.org, la boîte légère fonctionne parfaitement.
Cela suggère qu’il y a un problème quelque part dans votre configuration. Pourriez-vous vérifier la console de votre navigateur pour détecter d’éventuelles erreurs ou partager un lien vers le site sur lequel vous rencontrez des difficultés ?
Je viens de créer un fil de test sur une nouvelle instance Discourse que j’ai configurée la semaine dernière.
L’image mesure 1920x1050, mais elle ne s’ouvre pas dans une fenêtre lightbox. https://dis.ctb.co.at/t/test-image-lightbox/44
Sur la deuxième installation, où la lightbox fonctionnait auparavant, le chemin était d’abord “/var/docker” et j’ai ensuite changé pour un autre emplacement.
Il se pourrait que le problème de la lightbox ait commencé lors de ce changement de chemin. — Je ne suis pas certain.
Est-ce que j’ai peut-être oublié un paramètre pour le nouveau chemin ?
Ces lignes ci-dessus étaient les seules que j’ai trouvées pointant vers le répertoire d’origine “/var/docker”.
Je viens d’essayer de le déplacer à nouveau vers “/var/discourse” pour confirmer que c’est le changement de chemin qui en est la cause, mais le même problème persiste avec le chemin d’origine.
Il fonctionne également derrière un proxy inverse nginx qui gère le chiffrement SSL, si cela a de l’importance, mais je n’ai rien modifié dans la configuration depuis que cela a cessé de fonctionner sur l’autre installation.
J’ai appliqué ces paramètres pour nginx dans le fichier .yml correspondant.
Si ce n’est pas le chemin, qu’est-ce qui d’autre pourrait causer ce problème de lightbox ?
Je l’ai replacé dans “/var/docker/dis.ctb.co.at”.
Voici ma configuration yml actuelle (seules les données personnelles ont été modifiées). Y a-t-il une erreur ici, ou s’agit-il d’un problème Discourse ?
## Ceci est le modèle de conteneur Docker Discourse tout-en-un, autonome
##
## Après avoir apporté des modifications à ce fichier, vous DEVEZ reconstruire
## /var/discourse/launcher rebuild app
##
## SOYEZ *TRÈS* PRUDENT EN ÉDITANT !
## LES FICHIERS YAML SONT SUPER SENSIBLES AUX ERREURS D'ESPACEMENT OU D'ALIGNEMENT !
## visitez http://www.yamllint.com/ pour valider ce fichier si nécessaire
templates:
- "templates/postgres.template.yml"
- "templates/redis.template.yml"
- "templates/web.template.yml"
- "templates/web.ratelimited.template.yml"
## Décommentez ces deux lignes si vous souhaitez ajouter Lets Encrypt (https)
# - "templates/web.ssl.template.yml"
# - "templates/web.letsencrypt.ssl.template.yml"
## Quels ports TCP/IP ce conteneur doit-il exposer ?
## Si vous souhaitez que Discourse partage un port avec un autre serveur web comme Apache ou nginx,
## consultez https://meta.discourse.org/t/17247 pour plus de détails
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"
## Définissez db_shared_buffers à un maximum de 25 % de la mémoire totale.
## sera défini automatiquement par bootstrap en fonction de la RAM détectée, ou vous pouvez le remplacer
db_shared_buffers: "4096MB"
## peut améliorer les performances de tri, mais ajoute l'utilisation de la mémoire par connexion
#db_work_mem: "40MB"
## Quelle révision Git ce conteneur doit-il utiliser ? (par défaut : tests-passed)
#version: tests-passed
env:
LANG: en_US.UTF-8
# DISCOURSE_DEFAULT_LOCALE: en
## Combien de requêtes web simultanées sont prises en charge ? Dépend de la mémoire et des cœurs CPU.
## sera défini automatiquement par bootstrap en fonction des CPU détectés, ou vous pouvez le remplacer
UNICORN_WORKERS: 8
## TODO : Le nom de domaine auquel cette instance Discourse répondra
## Requis. Discourse ne fonctionnera pas avec une adresse IP brute.
DISCOURSE_HOSTNAME: dis.ctb.co.at
## Décommentez si vous souhaitez que le conteneur soit démarré avec le même
## nom d'hôte (option -h) que spécifié ci-dessus (par défaut "$hostname-$config")
#DOCKER_USE_HOSTNAME: true
## TODO : Liste d'e-mails délimités par des virgules qui seront administrateurs et développeurs
## lors de l'inscription initiale, exemple 'user1@example.com,user2@example.com'
DISCOURSE_DEVELOPER_EMAILS: 'nothing@nothing.com'
## TODO : Le serveur de messagerie SMTP utilisé pour valider les nouveaux comptes et envoyer des notifications
# L'adresse, le nom d'utilisateur et le mot de passe SMTP sont requis
# ATTENTION : le caractère '#' dans le mot de passe SMTP peut causer des problèmes !
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 # (optionnel, par défaut true)
DISCOURSE_SMTP_OPENSSL_VERIFY_MODE: none
## Si vous avez ajouté le modèle Lets Encrypt, décommentez ci-dessous pour obtenir un certificat SSL gratuit
# LETSENCRYPT_ACCOUNT_EMAIL: me@example.com
## L'adresse CDN http ou https pour cette instance Discourse (configurée pour récupérer)
## consultez https://meta.discourse.org/t/14857 pour plus de détails
#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
## Le conteneur Docker est sans état ; toutes les données sont stockées dans /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
## Les plugins vont ici
## consultez https://meta.discourse.org/t/19157 pour plus de détails
hooks:
after_code:
- exec:
cd: $home/plugins
cmd:
- git clone https://github.com/discourse/docker_manager.git
## Toute commande personnalisée à exécuter après la construction
run:
- exec: echo "Début des commandes personnalisées"
## Si vous souhaitez définir l'adresse e-mail 'From' pour votre première inscription, décommentez et modifiez :
## Après avoir reçu le premier e-mail d'inscription, re-commentez la ligne. Elle ne doit être exécutée qu'une seule fois.
#- exec: rails r "SiteSetting.notification_email='info@unconfigured.discourse.org'"
- exec: echo "Fin des commandes personnalisées"
- 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 {
J’ai maintenant compris que cela ne se produit que si l’option « Forcer votre site à utiliser uniquement HTTPS » est activée au moment de la création du post contenant l’image.
J’avais cette option activée sur l’autre installation depuis le début, mais elle a soudainement cessé de fonctionner, peut-être à cause d’une mise à jour de nginx ou de Discourse.
Pour l’instant, nginx ne montre rien d’anormal à ma connaissance.
En général, cela est dû à une mauvaise configuration de schémas complexes de proxy inverse, selon mon expérience. L’ajout d’un sous-dossier ajoute une complexité supplémentaire (et donc des variables).
Je fais tourner deux installations Discourse distinctes via ce proxy nginx, ainsi qu’une instance Nextcloud. Sur la première installation Discourse, la lightbox fonctionnait auparavant, puis elle s’est soudainement arrêtée. En réalité, je n’ai rien modifié dans la configuration du proxy depuis qu’elle fonctionnait.
Ce qui est étrange, c’est qu’elle crée toujours certains fichiers et dossiers dans /var/discourse, même si j’ai configuré les volumes pour ne pas pointer vers ce répertoire.
Il ne s’est jamais produit que des fichiers soient créés dans /var/discourse, peut-être ai-je vu quelques anciens fichiers.
J’ai maintenant changé de nginx à traefik pour m’assurer que le problème ne vient pas de nginx, mais le problème persiste. Cela signifie pour moi qu’il y a probablement un problème du côté de Discourse et non du côté du proxy.
Même situation avec traefik : si « https forcé » est désactivé au moment où l’image est publiée, alors la lightbox fonctionne bien, même si j’active « https forcé » plus tard.
Que puis-je vérifier d’autre ?
Cela m’affiche une erreur dans le fichier de journal, indiquant qu’il ne peut pas accéder à /uploads/....
Impossible d'accéder à '/uploads/default/original/1X/fe2af548af4a22f4802ddaa54afa557ae557417c.png' pour obtenir ses dimensions.
Je peux accéder à l’image sans problème si j’entre l’URL dans un navigateur web : https://domain.com/uploads/default/original/1X/fe2af548af4a22f4802ddaa54afa557ae557417c.png
Terminé 200 OK en 23ms (Vues : 0.3ms | ActiveRecord : 0.0ms | Allocations : 3000)
Terminé 200 OK en 318ms (Vues : 1.2ms | ActiveRecord : 0.0ms | Allocations : 50347)
Impossible d'accéder à '/uploads/default/original/1X/fe2af548af4a22f4802ddaa54afa557ae557417c.png' pour obtenir ses dimensions.
Démarrage de GET "/posts/96" pour 84.115.50.36 le 2020-07-04 14:15:14 +0000
Traitement par PostsController#show en JSON
Paramètres : {"id" => "96"}
Aucune erreur n’apparaît lorsque https n’est pas forcé.
Terminé 200 OK en 18ms (Vues : 0.3ms | ActiveRecord : 0.0ms | Allocations : 3050)
Terminé 200 OK en 296ms (Vues : 0.5ms | ActiveRecord : 0.0ms | Allocations : 49562)
Démarrage de GET "/posts/97" pour 84.115.50.36 le 2020-07-04 14:17:43 +0000
Traitement par PostsController#show en JSON
Paramètres : {"id" => "97"}
Il semble que Discourse télécharge pour une raison quelconque l’image à nouveau depuis le serveur web pour effectuer certaines opérations de type lightbox.
Si je télécharge manuellement cette image dans le conteneur Docker de Discourse, il tente d’accéder directement à son serveur web via son adresse IP interne au lieu de passer par le proxy. Cela fonctionne via http, mais pas via https.
Le serveur web lui-même n’a que http disponible, mais il tente d’y accéder via https, ce qui échoue.
Je me demande pourquoi Discourse télécharge à nouveau l’image depuis son serveur web au lieu d’y accéder en interne sans utiliser http/https.
Édition : J’ai découvert que j’avais renommé app.yml en domain.name.yml, ce qui a poussé Docker à changer le nom DNS de domain.name pour son adresse IP interne. Je l’ai renommé en domain_name.yml et tout fonctionne désormais correctement.