Il est donc confirmé que le problème venait du fait que, il y a quelques années, lorsque j’ai d’abord essayé de configurer S3, j’avais défini enable_s3_uploads dans la base de données, ce qui empêche la restauration de fonctionner car elle essaie de télécharger vers S3 mais n’a pas assez d’informations. (Soupir. Mais la restauration de l’instance multisite/s3 échoue car certains fichiers « ne sont pas migrés vers S3 ».)
Je me demande s’il serait judicieux de masquer tous les paramètres de téléchargement S3. Je suis à peu près sûr que rien de bon ne peut sortir de leur définition dans l’interface utilisateur. Mais il peut être utile de définir les téléchargements S3 dans la base de données. . . . peut-être.
Celui restauré sur l’installation standard ne parvient pas à afficher les téléchargements car il fait ceci :
Started GET "/uploads/short-url/puhaSNHeEy1S2knGFQIAZ8lprRy.pdf" for 68.11.35.109 at 2022-01-25 19:48:06 +0000
Processing by UploadsController#show_short as PDF
Parameters: {"base62"=>"puhaSNHeEy1S2knGFQIAZ8lprRy", "extension"=>"pdf"}
Sent file /var/www/discourse/public/default/original/1X/b2a283b9381b837234e7d4830b.pdf (4.4ms)
Completed 500 Internal Server Error in 130ms (ActiveRecord: 0.0ms | Allocations: 10019)
ActionController::MissingFile (Cannot read file /var/www/discourse/public/default/original/1X/b2a283b9381b837234e7d4830.pdf)
Le chemin qu’il recherche est /var/www/discourse/public/default/original/1X/ au lieu de /var/www/discourse/public/uploads/default/original/1X/
… . .
Et c’est parce que j’ai fait un remappage en essayant de corriger les références du bucket S3 et que cela a cassé les chemins dans les URL locales.
Je pense que c’est peut-être trop technique pour être utile à qui que ce soit. Bien que je pense toujours que masquer les variables de téléchargement S3 de l’interface utilisateur est une bonne idée.