Question épineuse. J’ai bien défini s3_bucket dans config/discourse.conf comme mentionné dans le post que tu as lié, ce qui a résolu cette erreur particulière, comme je l’ai noté là-bas.
Ce fichier se trouve à l’intérieur du conteneur (./launcher enter app). Notez que pour que cela survive à ./launcher rebuild app, vous devez également ajouter DISCOURSE_S3_BUCKET à la section env de votre fichier containers/app.yml.
Le fait que je l’aie corrigé explique pourquoi c’était un post de développement et non une demande d’assistance ; je demandais aux développeurs quelle était la bonne solution alors que je continue à bidouiller cela.
J’ai environ 100 Go de fichiers dans S3, donc j’avance très prudemment. J’ai mis en place une limite pour les publications à examiner, et je dois maintenant mettre en place une limite pour les publications à modifier. J’essaie une chose à la fois. Le fait que ce code semble rarement utilisé et que j’aie vu cette erreur à plusieurs reprises me préoccupe quant à la dégradation du code ; je ne veux pas soudainement défigurer l’ensemble de mon site à cause d’un bug, et cela semble être un bon moyen de faire cette erreur.
-
Pour les uploads
upload://(pour moi, cela signifie les uploads non vidéo), jusqu’à présent, cela semble fonctionner. Je procède un par un, puis j’examine la publication concernée pour m’assurer que tout fonctionne. -
Pour les uploads qui n’utilisent pas la syntaxe
upload://(pour moi, cela signifie les uploads vidéo, d’après ce que je comprends), où il y a une référence littérale à l’URL dans S3, cela déforme les URL. Ce n’est pas un bug difficile à corriger dès que je suis certain de savoir ce que je dois les changer en, mais je ne l’ai pas encore fait. Donc, c’est probablement l’un des PR que je publierai bientôt.
C’est un projet que je fais sur mon temps libre, donc pas de promesses concernant les délais.